Die Zugriffskontrolle für KI-Agenten lässt sich aufteilen: In einem von AWS beschriebenen Muster prüft das AgentCore Gateway die delegierte Identität, Cedar regelt den Zugriff auf Werkzeuge und der MCP-Server kontrolliert die Berechtigungen des Nutzers. Das ist wichtig, weil ein erlaubter Werkzeugaufruf allein nicht beantwortet, welche Informationen sich aus mehreren erlaubten Ergebnissen zusammensetzen lassen.
Prüfe nicht nur einzelne Aufrufe, sondern auch, welche Information mehrere erlaubte Ergebnisse gemeinsam preisgeben können.
Wer prüft den Zugriff auf ein Werkzeug?
Okta stellt dem Agenten einen ID-JAG aus, einen Identitätsnachweis für delegierten Zugriff. Der Agent leitet ihn an sein AgentCore Gateway weiter. Dort werden Aussteller, Zielgruppe, zugelassener Client und Berechtigungsbereiche geprüft. Anschließend löst das Gateway den Nachweis für das jeweilige Ziel ein. AWS beschreibt diesen Ablauf in seinem Tutorial zu Okta Cross App Access und Amazon Bedrock AgentCore.
Danach entscheidet Cedar, ob der Agent ein Werkzeug auflisten oder aufrufen darf und ob der delegierte Berechtigungsumfang dazu passt. Im Beispiel müssen die für ein Ziel eingerichteten Bereiche mit denen des ID-JAG übereinstimmen. Die Richtlinien arbeiten nach dem Prinzip „standardmäßig verweigern“: Ohne passende Erlaubnis wird kein Zugriff gewährt.
Der MCP-Server führt eine eigene Prüfung durch. Er kontrolliert die Gruppenmitgliedschaft und den Berechtigungsumfang des Nutzers. Die Cedar-Regel prüft also den Agenten und das Werkzeug; die Prüfung am Server betrifft den Nutzer, in dessen Auftrag der Agent handelt. In AWS’ beschriebenem Aufbau hat jeder Agent ein eigenes Gateway und einen eigenen Anbieter für Zugangsdaten.
XAA und OAuth-Zustimmung regeln den Zugriff unterschiedlich
Cross App Access (XAA) kommt in AWS’ Beispiel zum Einsatz, wenn der Autorisierungsserver des Ziels ID-JAGs akzeptiert. Bei Zielen mit eigenem Autorisierungsserver, etwa im GitHub-Beispiel, beschreibt AWS stattdessen eine individuelle OAuth-Zustimmung.
| Zugriffsmodell | Wer autorisiert? | Zustimmung des Nutzers | Verhalten im AWS-Test bei Sperre oder Widerruf |
| XAA | Ein Okta-Administrator legt fest, welcher Agent für welche Nutzer handeln darf; Okta prüft die Richtlinie bei jeder Token-Anfrage. | Keine Zustimmungsabfrage für den Nutzer. | Okta-Steuerungen verhindern die nächste Ausstellung eines ID-JAG. Bereits ausgestellte ID-JAGs laufen laut AWS nach etwa fünf Minuten ab. |
| Individuelle OAuth-Zustimmung | Der einzelne Nutzer stimmt dem Zugriff auf das Ziel zu. | Der Nutzer muss die Verbindung freigeben. | Im Test machte die Sperrung von Alice ein zuvor ausgestelltes, eine Stunde gültiges Token und die gespeicherte Zustimmung nicht ungültig. Eine neue Anmeldung wurde abgewiesen. Nach Aufhebung der Sperre funktionierte der Zugriff wieder, ohne dass Alice erneut zustimmen musste. Das Trennen der Zustimmung beendete die Verbindung. |
Die Abläufe sind deshalb nicht austauschbar: Welche Variante passt, hängt davon ab, ob der Autorisierungsserver des jeweiligen Ziels ID-JAGs akzeptiert oder eine eigene Nutzerzustimmung verlangt.
Was AWS in seinem Test beobachtete
AWS berichtet, dass Agent A sechs Werkzeuge auflistete. Alice und Carol konnten damit keine Aufgabe erstellen, Bob dagegen schon. Agent B listete vier Werkzeuge, weil Cedar dessen Schreibwerkzeuge ausblendete. Bob konnte über Agent B daher keine Schreibaktion ausführen.
Für Gateway A wertete AWS Spans aus, also Zeitmessungen einzelner Schritte, die über 24 Stunden in CloudWatch Omni erfasst wurden. Die Tabelle zeigt den Median (p50) und den Wert, unter dem 90 Prozent der Messungen lagen (p90).
| Messschritt | p50 | p90 |
Gateway.InboundAuth | 34 ms | 69 ms |
Identity.Authorize | 25 ms | 60 ms |
Identity.GetWorkloadAccessToken | 48 ms | 94 ms |
Identity.GetResourceOauth2Token | 70 ms | 439 ms |
Policy.AuthorizeAction pro Aufruf | 47 ms | 56 ms |
Policy.PartiallyAuthorizeActions pro Werkzeugliste | 65 ms | 75 ms |
Gateway.TargetInvocation | 5.565 ms | 6.273 ms |
AWS beziffert die mittlere Dauer der Identitäts- und Richtlinienprüfungen zusammen auf etwa 0,2 Sekunden. Der Span für authz.check am MCP-Server dauerte in diesem Test weniger als eine Millisekunde. Die Messung für Gateway.TargetInvocation umfasst den Aufruf des Ziels und ist davon getrennt. Diese Werte stammen aus AWS’ 24-Stunden-Test mit Gateway A.
Technische Stolperstellen im Aufbau
AWS berichtet, dass Richtlinien, die konkrete Werkzeugnamen voraussetzen, in seinen Tests nicht an Ziele mit dynamisch aufgelisteten Werkzeugen angefügt werden konnten. Außerdem paginiert das Gateway die Antwort auf tools/list nach Ziel. Clients müssen daher dem Cursor folgen, um weitere Werkzeuge zu erhalten. Die Richtlinien müssen den Status ACTIVE haben, bevor die Richtlinien-Engine angefügt wird.
Für den beschriebenen Amazon-EKS-Auto-Mode-Knotenpool empfiehlt AWS Images für mehrere Prozessorarchitekturen, weil der allgemeine Pool auf amd64 läuft. In der Container-Konfiguration des Python-SDK muss außerdem DOCKER_CONTAINER=true gesetzt sein. Für die Übertragung von Spans kann botocore nötig sein; AWS weist zudem darauf hin, dass die HTTP-Client-Instrumentierung in der ADOT-Agent-Konfiguration erhalten bleiben muss, damit der Trace-Kontext den Agenten erreicht.
AWS bezeichnet die Codebeispiele als konzeptionell und nicht als vollständige, direkt einsetzbare Lösung. Der Beispielcode ist für den Nicht-Produktivbetrieb vorgesehen.
Was einzeln erlaubte Ergebnisse gemeinsam verraten können
Ein Entwickler skizzierte in einer Diskussion über den Zugriff von KI-Agenten auf Unternehmensdaten einen hypothetischen Fall: Ein erlaubtes Werkzeug gibt die Gehaltssumme pro Team aus, ein zweites die Teamgröße. Besteht ein Team aus einer Person, könnten sich beide Ergebnisse zusammenführen lassen, um auf deren Gehalt zu schließen. Das ist ein Gedankenbeispiel, kein von AWS beobachteter Vorfall oder Messwert.
Der Fall wirft eine zusätzliche Gestaltungsfrage auf: Eine Richtlinie kann jeden Aufruf einzeln prüfen und trotzdem übersehen, welche vertrauliche Information sich aus mehreren erlaubten Antworten ableiten lässt. Der Entwickler schlug vor, solche kombinierten Abfragen innerhalb eines kontrollierten Werkzeugs zu prüfen oder die Ergebnisse voneinander zu trennen.
