Toegangsbeheer voor AI-agenten bepaalt welke agent namens welke gebruiker een tool mag aanroepen. In een technische uitwerking die AWS op 6 november 2026 publiceerde, controleert Okta de gedelegeerde toegang, toetst AgentCore Gateway het token, beoordeelt Cedar de rechten voor tools en scopes en controleert de MCP-server de rechten van de gebruiker. Zo krijgt elke laag een eigen taak. Dat begrenst afzonderlijke acties, maar een agent kan soms alsnog gevoelige informatie afleiden door toegestane resultaten te combineren. AWS’ technische uitwerking van de architectuur
Controleer niet alleen welke afzonderlijke acties zijn toegestaan, maar ook welke gevoelige informatie een agent uit meerdere antwoorden kan afleiden.
Welke laag controleert wat?
Okta geeft de agent een gedelegeerd token, een Identity Assertion JWT Authorization Grant (ID-JAG). De agent stuurt dat token naar zijn eigen Amazon Bedrock AgentCore Gateway. De Gateway controleert of de uitgever, doelgroep, toegestane client en scopes overeenkomen met de ingestelde autorisatie. Daarna wisselt de Gateway het token in voor toegang tot de doelapplicatie.
Cedar beoordeelt vervolgens of de agent de gevraagde tool mag zien of aanroepen, en of de gedelegeerde scope daarbij past. Een beleid met alleen expliciete toestemmingen houdt de standaard op weigeren: zonder passende toestemming wordt de actie niet toegestaan. De MCP-server, die tools via het Model Context Protocol aanbiedt, doet daarna nog een eigen controle op de gebruikersgroepen en scope. Cedar bepaalt dus wat de agent met een tool mag doen; de server controleert wat de gebruiker zelf mag.
AWS’ voorbeeld gebruikt de scopes xaa:read en xaa:write; de scopes voor de doelapplicatie moeten overeenkomen met die in het ID-JAG. In dit ontwerp heeft elke agent een eigen Gateway en credential provider. Een tweede agent op Amazon EKS krijgt bijvoorbeeld alleen xaa:read voor zijn doelverbinding.
De inrichting van tools speelt ook mee. AWS meldt dat Cedar-beleid dat specifieke tools noemt in zijn tests niet kon worden gekoppeld aan doelen die hun tools dynamisch aanbieden. Bovendien verdeelt de Gateway tools/list over pagina’s per doel: een client moet de paginering volgen om alle tools te ontvangen.
XAA en OAuth-toestemming werken anders bij intrekken
Cross App Access (XAA) past volgens AWS bij doelapplicaties waarvan de autorisatieserver ID-JAG-tokens accepteert. Een Okta-beheerder bepaalt welke agent namens welke gebruikers mag handelen; gebruikers krijgen in deze route geen toestemmingsprompt. Een app met een eigen autorisatieserver, zoals GitHub in AWS’ voorbeeld, gebruikt in plaats daarvan OAuth-toestemming per gebruiker.
| Toegangsmodel | Wie verleent toegang? | Gedrag bij intrekken in AWS’ test |
| XAA | Een Okta-beheerder stelt in voor welke gebruikers een agent mag handelen. | Okta-beleid voorkomt een volgende uitgifte van een ID-JAG; uitgegeven XAA-tokens verlopen volgens AWS binnen ongeveer vijf minuten. |
| OAuth-toestemming per gebruiker | Iedere gebruiker geeft toestemming aan de doelapplicatie. | Het schorsen van Alice maakte haar bestaande token van één uur en opgeslagen toestemming niet ongeldig; een nieuwe aanmelding werd geweigerd. Na het opheffen van de schorsing werkte toegang weer zonder nieuwe toestemming. Het loskoppelen van de toestemming stopte de toegang. |
De uitkomst hangt in dit voorbeeld dus af van het autorisatiemodel van de doelapplicatie. De test beschrijft gedrag van de specifieke XAA- en GitHub-routes die AWS gebruikte.
Wat AWS over de tests en metingen rapporteerde
In AWS’ test zag Agent A zes tools. De agent kon een taak voor Bob aanmaken, maar niet voor Alice of Carol. Agent B zag vier tools doordat Cedar de schrijffuncties verborg; ook voor Bob was daar geen schrijftool beschikbaar. Dat zijn uitkomsten van AWS’ eigen testopstelling.
AWS rapporteerde voor 24 uur aan Gateway A-traces de mediaan (p50) en het 90e percentiel (p90). De span voor inkomende autorisatie bedroeg 34 en 69 milliseconden. De mediaan van de gecombineerde identiteits- en beleidsstappen was volgens AWS ongeveer 0,2 seconde. Voor Gateway.TargetInvocation rapporteerde AWS 5.565 ms p50 en 6.273 ms p90. Dit zijn waarnemingen uit die specifieke proefopstelling.
Voor controle achteraf koppelde AWS OpenTelemetry-traces van AgentCore aan Okta System Log-gebeurtenissen in CloudWatch. In de test kwamen de Okta-gebeurtenissen ongeveer één seconde na publicatie binnen.
Afzonderlijk toegestane resultaten kunnen samen iets prijsgeven
Een deelnemer aan r/LLMDevs schetste een hypothetisch voorbeeld: een tool geeft toegestane salaris totalen per team terug en een andere tool het aantal teamleden. Als één team uit één persoon bestaat, kan de combinatie het individuele salaris onthullen. Beide antwoorden kunnen afzonderlijk zijn toegestaan, terwijl de combinatie gevoelige informatie blootlegt.
De deelnemer stelde voor om de gecombineerde vraag binnen één tool met beleidscontrole te beoordelen, of te voorkomen dat de uitkomsten worden samengevoegd. Dat is een ontwerpidee, geen gerapporteerd incident of testresultaat. AWS’ beschreven controles beoordelen toolvermeldingen en afzonderlijke toolaanroepen; de gerapporteerde test behandelt dit scenario met gecombineerde resultaten niet.
AWS noemt de codevoorbeelden conceptueel en niet compleet als implementeerbare oplossing; de voorbeeldcode is bedoeld voor niet-productiegebruik.
