AWS’ voorbeeld koppelt de Cognito-identiteit van een externe gebruiker aan een IAM-rol. De tijdelijke inloggegevens van die rol bepalen welke gegevens de gebruiker via Athena en AWS Lake Formation kan opvragen. Zo wordt tenanttoegang afgedwongen in het querypad, niet alleen door instructies aan de AI-agent. AWS beschrijft de architectuur en de voorbeeldconfiguratie in een tutorial die op 5 november 2026 verscheen.
Van Cognito-aanmelding naar een afgebakende query
Een externe gebruiker meldt zich aan via Amazon Cognito en krijgt een ID-token met de claim custom:team. Die claim geeft aan bij welk team de gebruiker hoort. Cognito Identity Pool-regels koppelen de claimwaarde aan een IAM-rol; de gekozen rol bepaalt vervolgens de tijdelijke inloggegevens voor de dataquery.
AgentCore Gateway controleert het access token met een JWT-authorizer en stuurt het ID-token via de header X-ID-Token door naar de Lambda-doelfunctie. Lambda gebruikt Amazon Cognito Identity om voor de gebruiker tijdelijke inloggegevens op te halen. Athena voert de query met die gegevens uit. AWS Lake Formation past daarbij de machtigingen van de rol en de bijbehorende filters toe.
Voor externe gebruikers beschrijft AWS deze route met Cognito User Pools en Identity Pools. Voor werknemersidentiteiten noemt de tutorial IAM Identity Center met Trusted Identity Propagation.
Lambda wisselt tokens om, maar bevraagt de data niet
In de voorbeeldconfiguratie heeft de uitvoeringsrol van Lambda twee genoemde acties: cognito-identity:GetId en cognito-identity:GetCredentialsForIdentity. AWS kent die rol geen datamachtigingen toe voor Athena, S3 of Glue. Lambda fungeert dus als tussenstap voor het ophalen van inloggegevens; de aan de gebruiker gekoppelde rol levert de machtigingen waarmee de query toegang krijgt tot data.
Dat onderscheid bepaalt waar je de tenantgrens moet beoordelen: bij de roltoewijzing én bij de machtigingen die gelden wanneer Athena de query uitvoert.
De teamregels filteren tabellen en rijen
AWS gebruikt in het voorbeeld de LF-Tag-waarden TeamA, TeamB en shared. De tabel venue is gekoppeld aan Team A, category aan Team B en users aan de gedeelde tag. Voor sales_extended gebruikt de configuratie een rijfilter per team. De claimwaarden Team A en Team B zijn daarbij de invoer voor rolregels; de bijbehorende rolwaarden staan als TeamA en TeamB.
De getoonde regel voor sales_extended gebruikt de rijvoorwaarde team = 'Team A'. Bij kolomtoegang staat Access to all columns: deze regel filtert dus rijen, terwijl alle kolommen toegankelijk blijven. De concrete configuratie demonstreert tabeltoegang en rijfiltering.
De claim custom:team is in de voorbeeldcode veranderbaar en stuurt de rolkeuze aan. Daaruit volgt dat het beheer van wijzigingen aan die claim onderdeel is van de autorisatiegrens. Een implementatie moet daarom zorgvuldig bepalen wie de teamclaim kan toekennen of aanpassen.
Behandel wijzigingen aan custom:team als wijzigingen aan de toegang zelf: die claim bepaalt welke datarol een gebruiker krijgt.
Welke controles beschrijft AWS?
AWS’ walkthrough laat operators aanmelden als Team A en Team B en vervolgens de zichtbare tabellen en de teamgebonden rijen in sales_extended vergelijken. Daarna wijzigen ze een tabeltag en het rijfilter voor Team A om de gewijzigde toegang te controleren. AWS waarschuwt dat veranderingen in Lake Formation-machtigingen enkele minuten nodig kunnen hebben om door te werken.
