Skalierung der Governance für KI-Agenten mit AWS Bedrock AgentCore und Okta

Amazon Web Services hat den zweiten Teil eines technischen Leitfadens veröffentlicht, der beschreibt, wie sichere KI-Agenten-Operationen skaliert werden können. Der am 6. November 2026 veröffentlichte Artikel erklärt, wie direkte Verbindungen zwischen Agenten und Tools durch eine zentralisierte Gateway-Architektur ersetzt werden können. Dieser Ansatz nutzt Amazon Bedrock AgentCore, Okta Cross App Access und Cedar-Policy-Engines, um Berechtigungen über Hunderte von Agenten und Tools hinweg zu verwalten.

Was ist passiert

Im ersten Teil dieser Serie haben Ingenieure einen einzelnen Aufgaben-Agenten entwickelt, der im Namen angemeldeter Benutzer agiert. Diese ursprüngliche Konfiguration basierte auf einer kleinen Topologie, in der der Agent Laufzeitadressen für Model Context Protocol (MCP)-Server hielt und Token-Austauschvorgänge direkt durchführte. Obwohl diese Methode für Proof-of-Concept-Szenarien funktional war, führt sie bei wachsenden Systemen zu einer komplexen Verdrahtungsmatrix. Jedes neue Tool erfordert Aktualisierungen aller Agenten, die darauf zugreifen müssen, und jeder Agent muss Zugangsdaten für jede Ressource bereithalten, auf die er möglicherweise zugreifen könnte.

Der neue Leitfaden behebt diese Skalierungsbeschränkungen, indem er das Amazon Bedrock AgentCore Gateway als zentrale Einstiegspforte einführt. Anstatt dass Agenten Tools direkt aufrufen, leiten sie Anfragen über das Gateway weiter. Diese Komponente übernimmt die Identitätsüberprüfung und erzwingt Zugriffsrichtlinien, bevor ein Tool aufgerufen wird. Das Update führt zudem einen zweiten Agenten ein, der auf Amazon Elastic Kubernetes Service (Amazon EKS) läuft, um zu demonstrieren, dass das Governance-Modell unabhängig vom Hosting-Standort des Agenten funktioniert. Dieser Wandel verschiebt die Sicherheitslogik von individuellen Servern zu einer zentralisierten Policy-Engine und reduziert Code-Duplizierung sowie die Komplexität von Audits.

Wie es funktioniert

Die Architektur konzentriert sich auf das AgentCore Gateway, das einen Identity Assertion JWT Authorization Grant (ID-JAG) vom Agenten entgegennimmt. Dieses Token beweist, dass der Benutzer den Agenten zum Handeln autorisiert hat. Der Inbound-Autorisator des Gateway validiert, dass das Token speziell für diesen Agenten von Okta ausgestellt wurde. Nach der Validierung konsultiert das Gateway eine von Cedar betriebene Policy-Engine. Diese Richtlinien definieren genau, welche Tools ein Agent basierend auf seiner Identität und den vom Benutzer gewährten Scopes verwenden darf. Wenn die Richtlinie die Aktion zulässt, tauscht das Gateway unter Verwendung von AgentCore Identity den ID-JAG gegen ein Scoped Access Token von Okta.

Dieser Prozess stellt sicher, dass Agenten niemals geheime Zugangsdaten handhaben oder Token-Austauschvorgänge selbst durchführen. Die Ausführungsrolle des Agenten benötigt keine Berechtigungen mehr für den Token-Austausch oder das Lesen von Secrets. Stattdessen hält das Gateway diese Privilegien vor. Die MCP-Server führen weiterhin endgültige Prüfungen der Benutzergruppen durch, aber die primäre Autorisierungsentscheidung erfolgt am Gateway. Diese Trennung ermöglicht es Organisationen, Zugriffsregeln an einem einzigen Ort zu aktualisieren, anstatt Code auf Tausenden von Servern zu ändern. Alle Entscheidungen werden als OpenTelemetry-Spans protokolliert, was einen vollständigen Audit-Trail bereitstellt.

Wichtige Details

• Zentralisiertes Gateway: Agenten verbinden sich mit einem einzelnen Gateway-Endpunkt, anstatt direkte Verbindungen zu mehreren MCP-Servern zu verwalten, was die Netzwerk-Topologie vereinfacht.
• Cedar Policy Engine: Die Zugriffskontrolle wird mittels Cedar-Richtlinien definiert, die spezifische Tools an Agenten und Scopes binden und einen Default-Deny-Ansatz erzwingen.
• Auslagerung des Token-Austauschs: Das Gateway löst Okta-Gewährungen in Access Tokens ein, wodurch die Notwendigkeit entfällt, dass Agenten Berechtigungen für Zugangsdaten oder Secrets halten.
• Unterstützung für mehrere Umgebungen: Die Lösung unterstützt Agenten, die sowohl auf der Bedrock AgentCore-Laufzeitumgebung als auch auf Amazon EKS laufen, und verwendet konsistente Methoden zur Identitätsverifizierung.
• Einheitliche Observability: AgentCore Observability sammelt Traces von den Komponenten Gateway, Policy und Identity, die in Amazon CloudWatch mit Okta System Logs verknüpft werden können.
• Statische Tool-Schemas: Targets müssen statische Tool-Schemas verwenden, um sicherzustellen, dass Policy-Referenzen stabil bleiben, da dynamische Auflistungen die Durchsetzung von Richtlinien erschweren können.

Warum das wichtig ist

Für Softwareteams, die Enterprise-KI-Anwendungen entwickeln, ist die Skalierbarkeit der Sicherheit ein erheblicher Engpass. Das Verwalten von Berechtigungen für Dutzende von Agenten und Hunderte von Tools wird schnell unüberschaubar, wenn jeder Agent seine eigene Verbindungslogik pflegt. Durch die Zentralisierung der Autorisierung können Organisationen das Risiko von Konfigurationsdrifts reduzieren. Sicherheitsteams können Richtlinien an einem einzigen Ort prüfen und aktualisieren, um sicherzustellen, dass Änderungen konsistent über alle Agenten hinweg angewendet werden. Dieses Modell minimiert zudem die Angriffsfläche, da Agenten keine sensiblen Zugangsdaten mehr speichern und keine weitreichenden Berechtigungen für den Token-Austausch besitzen.

Die Integration mit Observability-Tools bietet kritische Einblicke in das Verhalten von Agenten. In regulierten Branchen ist es unerlässlich nachzuweisen, wer eine Aktion wann autorisiert hat. Die Möglichkeit, Okta-Ereignisse für Gewährungsvorgänge mit detaillierten Ausführungstraces in CloudWatch zu verknüpfen, ermöglicht es Ingenieuren, den vollständigen Kontext jeder Agentenaktion zu rekonstruieren. Diese Transparenz hilft Teams dabei, Berechtigungsprobleme zu debuggen und Compliance-Anforderungen zu erfüllen, ohne eine benutzerdefinierte Logging-Infrastruktur von Grund auf neu zu erstellen.

Was Sie tun können

• Beispielcode prüfen: Untersuchen Sie das AWS-Beispiel 08-okta-xaa-delegation-chain auf GitHub, um die Basisarchitektur zu verstehen, bevor Sie Gateway-Komponenten hinzufügen.
• Gateway implementieren: Konfigurieren Sie ein AgentCore Gateway mit einem Inbound-Autorisator, der ID-JAGs von Ihrem Okta-Autorisierungsserver validiert.
• Cedar-Richtlinien definieren: Schreiben Sie Permit-only-Richtlinien, die Agent-Client-IDs und Scopes spezifischen Tool-Aktionen zuordnen, um eine Default-Deny-Haltung sicherzustellen.
• Observability einrichten: Aktivieren Sie die CloudWatch Transaction Search und konfigurieren Sie das Okta Log Streaming zu EventBridge, um eine einheitliche Audit-Ansicht zu erstellen.
• Agenten in mehreren Umgebungen testen: Stellen Sie einen sekundären Agenten auf Amazon EKS bereit, um zu überprüfen, ob das Gateway Identitäten korrekt verarbeitet, die außerhalb der Bedrock-Laufzeitumgebung stammen.
• Token-Scopes validieren: Stellen Sie sicher, dass die vom Gateway angeforderten Scopes mit denen im ID-JAG übereinstimmen, um Fehler beim Token-Austausch zu verhindern.