Agentische Systeme sind Anwendungen, in denen autonome Agenten über mehrere Dienste hinweg planen, argumentieren und handeln. Diese Anwendungen sind so konzipiert, dass sie über einfache Anfrage/Antwort-Interaktionen hinausgehen.
Im Gegensatz zu traditionellen API-gesteuerten Microservices, die vom Request-Payload-Schema abhängen und Requests syntaktisch interpretieren, verwenden agentische Anwendungen Large Language Models (LLMs), um Requests semantisch zu interpretieren. Dies ermöglicht es ihnen, mehrstufige Aufgaben zu planen, Aktionen miteinander zu verketten und mehrere Services autonom im Namen eines Users aufzurufen.
Mit zunehmender Reife ähneln diese Systeme zunehmend verteilten Anwendungen, die aus lose gekoppelten Agenten, Diensten und externen APIs bestehen, die zusammenarbeiten. Mit dieser zusätzlichen Flexibilität gehen eine größere Komplexität und die Notwendigkeit eines konsistenten, sicheren Ansatzes für die Identität einher.
Sicherheitsprobleme durch agentische Systeme
Eine zentrale Herausforderung in diesen Umgebungen ist die Identitätspropagierung, die sicherstellt, dass die Identität und Absicht eines Benutzers sicher über Agenten, Dienste und Tools hinweg übertragen werden kann. Ohne eine starke Authentifizierung und Autorisierung könnte ein Agent einen Dienst ohne den richtigen Kontext aufrufen, seine Berechtigungen überschreiten oder Unternehmensrichtlinien umgehen.
Okta Cross-App Access bietet eine standardbasierte Möglichkeit zum Austausch von Identitätstoken zwischen Anwendungen. In Kombination mit dem Model Context Protocol (MCP), das Agenten eine einheitliche Möglichkeit bietet, Tools zu entdecken und aufzurufen, schaffen diese Funktionen ein vertrauenswürdiges Gefüge, das Benutzer, Agenten und Dienste miteinander verbindet.
Die folgenden Abschnitte veranschaulichen eine Beispielarchitektur für die Integration von Okta Cross-App Access mit KI-Agenten, die auf serverlosen Amazon Web Services (AWS)-Diensten wie AWS Lambda oder Amazon Elastic Container Service laufen, um diese Herausforderungen zu bewältigen. Sie erfahren, wie sich ein Benutzer bei Okta authentifiziert, wie seine Identität über Token-Exchange an Agenten weitergegeben wird und wie Downstream-Dienste den Zugriff validieren und erzwingen.
Durch die Kombination der Okta Enterprise Identity Plattform mit den Serverless- und Container-Services von AWS können Unternehmen eine sichere Agent-to-Agent- und Agent-to-Service-Zusammenarbeit in großem Umfang ermöglichen.
Lösungsarchitektur
Dieser Abschnitt umreißt ein beispielhaftes End-to-End-Design, das die Okta-Identität mit Agent-to-Service-Aufrufen auf AWS verbindet, wobei MCP ein konsistentes Protokoll für Agenten bereitstellt, um Tools zu entdecken und aufzurufen. Sie sehen die Hauptkomponenten, den Token-Fluss und wie die Identität an jeder Station weitergegeben und durchgesetzt wird.
Authentifizierungs- und Autorisierungsabläufe
Die Beispielarchitektur beginnt damit, dass ein Benutzer mit einer agentenbasierten Client-Anwendung interagiert, z. B. einer Web- oder Desktop-Oberfläche. Der Client integriert sich mit Okta unter Verwendung von OpenID Connect (OIDC), um die Authentifizierung abzuwickeln. Nach der Anmeldung erhält der Client ein ID-Token, das die Identität des Benutzers repräsentiert. Anstatt dieses Token direkt für nachgelagerte Aufrufe zu verwenden, nutzt der Client das Cross-App Access (XAA) SDK, um es gegen einen Identity Assertion Grant (ID-JAG) einzutauschen, der an eine bestimmte nachgelagerte Zielgruppe gebunden ist. Dies bildet die Grundlage für eine sichere Identitätsübertragung über Anwendungen hinweg.
Der ID-JAG wird dann einem Autorisierungsdienst präsentiert, der auf AWS läuft, wie im vorherigen Diagramm dargestellt. Dieser Dienst verifiziert die Assertion und gibt ein kurzlebiges, publikumsbeschränktes Zugriffstoken aus. Dieses Token ist speziell für die Ressource bestimmt, die der Agent aufrufen muss. Durch die Einführung dieses Schritts können Sie klare Vertrauensgrenzen durchsetzen und einen Least-Privilege-Zugriff auf nachgelagerte Dienste gewährleisten.
Mit dem Zugriffstoken in der Hand kann der Agent Tools und Ressourcen aufrufen, die auf MCP-Servern gehostet werden. Jeder MCP-Server validiert das eingehende Token, bevor er eine Aktion ausführt. Diese Tools und Ressourcen können wiederum nachgeschaltete geschützte Ressourcen wie Service-APIs aufrufen. Falls diese Dienste auf AWS ausgeführt werden, können sie ihre eigenen Richtlinien durchsetzen, indem sie sich auf IAM-Rollen verlassen und Token-Ansprüche wie Benutzeridentität, Bereich und Mandant validieren. Diese schichtweise Durchsetzung stellt sicher, dass Identität, Absicht und Autorisierung konsistent vom Benutzer bis zu den Backend-Systemen übertragen werden.
Überlegungen und Best Practices
Beim Aufbau sicherer agentenbasierter Anwendungen sollten Engineering-Teams strenge Sicherheitskontrollen und bewährte Best Practices anwenden. Die folgenden Prinzipien bieten eine solide Grundlage für den sicheren Aufbau von agentenbasierten Systemen und MCP-Servern.
Identitätsvalidierung
Validieren Sie die Identität an jeder Grenze. Jeder KI-Agent und MCP-Server muss Zugriffstoken unabhängig überprüfen und Aussteller, Zielgruppe, Bereich, Signatur und Ablauf überprüfen. Verlassen Sie sich niemals ausschließlich auf die Upstream-Validierung. Dadurch wird sichergestellt, dass Agents die Durchsetzung nicht durch das Verketten von Aufrufen umgehen können.
Token-Verwaltung
Verwenden Sie kurzlebige, bereichsbezogene Token. Befolgen Sie stets das Prinzip der geringsten Privilegien und beschränken Sie den Umfang der Token auf die minimal erforderlichen Berechtigungen. Zugriffstoken, die für Agents ausgestellt werden, sollten nur für einen kurzen Zeitraum (Minuten, nicht Stunden) gültig sein und an bestimmte MCP-Tools gebunden sein (z. B. documents.read vs. documents.write). Wenn ein Agent ein anderes Tool aufrufen muss, führen Sie einen Token-Austausch durch, um ein neues Token mit einem engeren Umfang auszustellen.
Kontextübertragung
Benutzerkontext sicher weitergeben. Verwenden Sie Okta Cross‑App Access, um die Identity über verschiedene Dienste hinweg zu übertragen. Wenn Agents MCP-Server aufrufen, schließen Sie Claims wie Subject, Endbenutzer (sub), autorisierte Partei (azp), Audience (aud) und Act ein, um die On-Behalf-Of-Ausführung zu verfolgen. Dies stellt sicher, dass nachgeschaltete Dienste Richtlinien durchsetzen können, da sie sowohl wissen, wer die Anfrage initiiert hat, als auch warum sie gestellt wurde.
Observability und Auditing
Audit und Nachverfolgung von Agent-Ketten von Ende zu Ende. Protokollieren Sie strukturierte Ereignisse und Autorisierungsentscheidungen in jedem Segment und zeigen Sie die vollständige Akteurverfolgung (z. B. Benutzer → Agent → MCP-Tool), die verwendeten Bereiche und die getroffenen Entscheidungen an. Verwenden Sie Observability Services wie Amazon CloudWatch und AWS X-Ray, um Anfragen über mehrere Agents und Tools hinweg zu verfolgen, um Fragen zu beantworten wie: „Wer hat den Agenten aufgefordert, zu handeln?“ Welches Tool wurde aufgerufen? Auf welche Daten wurde zugegriffen?
AWS-spezifische Best Practices
- IAM-Rollen: Verwenden Sie die minimal erforderlichen Berechtigungen für Lambda-Funktionsausführungsrollen. Vermeiden Sie die Wiederverwendung von Ausführungsrollen über mehrere Funktionen hinweg.
- API-Gateway: Verwenden Sie Lambda-Authorizer, um Ihre APIs zu schützen. Aktivieren Sie CORS, Ratenbegrenzung und WAF. Erwägen Sie mTLS bei der Kommunikation zwischen Systemkomponenten.
- CloudWatch: Wird für die zentrale Protokollierung mit Aufbewahrungsrichtlinien, Betriebs- und Geschäftsmetriken sowie End-to-End-Tracing verwendet.
- VPC-Konfiguration: Erwägen Sie die Verwendung von VPC für zusätzliche Netzwerktrennung, falls erforderlich.
Agentic Applications öffnen die Tür zu neuen Möglichkeiten der Automatisierung von Aufgaben und der Verbindung von Diensten, führen aber auch neue Sicherheitsaspekte ein. Jeder Agent und MCP-Server muss mit dem richtigen Benutzerkontext arbeiten, Least Privilege erzwingen und eine klare Audit-Historie hinterlassen. Ohne eine solide Grundlage in Authentifizierung, Autorisierung und Identitätspropagierung können diese Systeme schnell unübersichtlich oder unsicher werden.
Durch die Kombination von Okta's Cross-App Access und Identity-Lösungen mit den Serverless- und Container-Services von AWS können Unternehmen agentische Systeme aufbauen, die sicher skalieren. Der in diesem Beitrag beschriebene Ansatz zeigt, wie Benutzer authentifiziert, ihre Identität über Agenten verbreitet, bereichsbezogene Token für MCP-Tools ausgestellt und Richtlinien an jeder Grenze durchgesetzt werden.
Die Bereitstellung Ihrer KI-Agenten mithilfe der serverlosen Technologien von AWS bietet mehrere Vorteile:
- Skalierbarkeit und Zuverlässigkeit: Ihre Workloads werden automatisch auf mehrere Verfügbarkeitszonen verteilt und skalieren autonom auf Basis der Verkehrsmuster.
- Kostenoptimierung: Pay-per-Use-Preismodell; Sie zahlen nur für das, was Sie nutzen.
- Verwaltete Infrastruktur: AWS übernimmt die gesamte Infrastrukturverwaltung für Sie, einschliesslich Betrieb, Sicherheit und Ausfallsicherheit.
- Integration: Native Integrationen mit einer Vielzahl von AWS-Services.
- Integrierte Observability: Umfassende Überwachung mit CloudWatch und X-Ray.
Um mehr zu erfahren, erkunden Sie die Dokumentation zu Okta Cross-App Access und die AWS serverless -Dienste.
Ressourcen
- Okta Cross-App Access
- MCP-Spezifikation
- AWS Lambda-Dokumentation
- AWS SAM Dokumentation
- API Gateway-Dokumentation
