Govern AI agent access mit Okta Cross App Access und Amazon Bedrock AgentCore – Teil 2

In Teil 1, haben Sie einen Task-Agent gebaut auf Amazon Bedrock AgentCore, einer Plattform zum Erstellen, Verbinden und Optimieren von Agents in großem Maßstab, mit beliebigem Framework oder Modell. Der Agent läuft auf Amazon Bedrock AgentCore runtime, einer Funktion von Amazon Bedrock AgentCore, und handelt für angemeldete Benutzer über Okta Cross App Access (XAA). Okta entschied, welcher Agent für welchen Benutzer handeln darf, und Amazon Bedrock AgentCore Identity, eine Funktion von Amazon Bedrock AgentCore, löste Oktas Grant innerhalb des Agents ein. Das beweist den Governance-Mechanismus, und er läuft auf einer bewusst kleinen Topologie: ein Agent, zwei Model Context Protocol (MCP)-Server und die Autorisierungsprüfung, die in jeden Server geschrieben ist.

Der Mechanismus skaliert. Die Topologie nicht. Drei Dinge, die für einen Agent und zwei Tools in Ordnung sind, werden zur Hauptarbeit in einem Unternehmen mit hunderten Agents und tausenden Tools:

In diesem Beitrag vollziehen Sie diese Änderung an der Teil-1-Lösung nach. Amazon Bedrock AgentCore Gateway, eine Funktion von Amazon Bedrock AgentCore, wird die einzige Eingangstür und löst Oktas Grant für jedes Ziel ein. Policy in Amazon Bedrock AgentCore wertet Cedar-Policies aus, die jedes Tool an den Agent und den von Okta delegierten Scope binden. Ein zweiter Agent auf Amazon Elastic Kubernetes Service (Amazon EKS) kommt unter seiner eigenen Okta-Identität hinzu, um zu zeigen, dass der Eingang nicht darauf achtet, wo ein Agent läuft. Und Amazon Bedrock AgentCore Observability, eine Funktion von Amazon Bedrock AgentCore, mit Amazon CloudWatch gibt Ihnen einen Ort, um jede Entscheidung zu lesen, einschließlich der von Okta. Wir vergleichen außerdem XAA mit per-User-OAuth-Consent für Anwendungen, die Oktas Grant nicht akzeptieren können.

Was sich gegenüber Teil 1 ändert

Die Okta-Konfiguration, der AgentCore Identity credential provider und die MCP-Server aus Teil 1 bleiben unverändert. Abbildung 1 zeigt die Architektur mit den Erweiterungen.

Abbildung 1: Die Teil-1-Lösung mit AgentCore Gateway, Policy und Observability, einem zweiten Agent auf Amazon EKS und dem Audit-Pfad, mit Nummern entsprechend den folgenden Schritten

1. Der Benutzer meldet sich an, und das Backend for Frontend (BFF) tauscht das ID-Token gegen ein Identity Assertion JWT Authorization Grant (ID-JAG) ein, das für den Task-Agent, Agent A, ausgestellt ist, wie in Teil 1.
2. Das BFF ruft Agent A auf AgentCore runtime mit dem ID-JAG auf.
3. Agent A leitet das ID-JAG an sein Gateway als Bearer-Token seiner MCP-Sitzung weiter. Der eingehende Authorizer des Gateways akzeptiert nur die ID-JAGs von Agent A.
4. Policy in AgentCore wertet Cedar-Policies für jedes Tool-Listing und jeden Tool-Aufruf aus, bevor das Gateway ein Ziel aufruft.
5. Für Aufrufe, die Cedar erlaubt, lässt das Gateway AgentCore Identity das ID-JAG für jedes Ziel an Oktas benutzerdefiniertem Autorisierungsserver über den credential provider aus Teil 1 einlösen. Ein Aufruf, den Cedar ablehnt, löst das ID-JAG nicht ein.
6. Der MCP-Server prüft die Gruppen und den Scope des Benutzers, wie in Teil 1, und zeichnet jede Entscheidung als authz.check span.
7. Jeder Hop emittiert OpenTelemetry Spans an AgentCore Observability, die CloudWatch Transaction Search sammelt, und Okta streamt sein System Log über Amazon EventBridge an CloudWatch.

Der Berichts-Agent, Agent B, läuft auf Amazon EKS und folgt denselben Weg über sein eigenes Gateway.

Voraussetzungen

Zusätzlich zur Lösung aus Teil 1 benötigen Sie Folgendes:

Die Erweiterungen dauern etwa 90 Minuten. Die EKS-Kontrollebene kostet $0.10 pro Stunde, zuzüglich Nodes und der Verwaltungsgebühr für Amazon EKS Auto Mode, und die AgentCore-Features berechnen das, was Sie nutzen. Siehe Amazon EKS pricing und Amazon Bedrock AgentCore pricing.

Wie in Teil 1 ist die Grundlage dieser Lösung das AWS-Beispiel 08-okta-xaa-delegation-chain auf GitHub, und Sie können die Erweiterungen aus Teil 2 darauf aufbauen. Über dieses Beispiel hinaus zeigen die Codeausschnitte und Konfigurationen in diesem Beitrag das Muster konzeptionell. Sie sind keine vollständige, einsatzfähige Lösung. Der Code ist Beispielcode für die Nutzung außerhalb der Produktion, arbeiten Sie daher mit Ihren Sicherheits- und Rechtsteams zusammen, um die Sicherheits-, regulatorischen und Compliance-Anforderungen Ihrer Organisation zu erfüllen, bevor Sie ihn einsetzen.

Erstellen Sie ein Gateway, das das ID-JAG akzeptiert

Der eingehende Authorizer des Gateways funktioniert wie der Laufzeit-Authorizer aus Teil 1. Sein Issuer ist der org authorization server von Okta, seine Audience ist der custom authorization server, und allowedClients pinnt ihn an einen Agenten:

authorizer = {"customJWTAuthorizer": {
    "discoveryUrl": f"{OKTA_ORG}/.well-known/openid-configuration",  # the ID-JAG's issuer
    "allowedAudience": [f"{OKTA_ORG}/oauth2/{CUSTOM_AS_ID}"],         # the resource's authorization server
    "allowedClients": [AGENT_CLIENT_ID],                               # only this agent's ID-JAGs
    "allowedScopes": ["xaa:read", "xaa:write"],
}}

Abbildung 2 zeigt den daraus resultierenden eingehenden Authorizer.

Abbildung 2: Das Gateway akzeptiert nur ID-JAGs, die Okta dem Agenten für den authorization server der Ressource ausgestellt hat

Jeder MCP-Server wird ein Gateway-Target, dessen ausgehende Autorisierung TOKEN_EXCHANGE über den Credential Provider aus Teil 1 verwendet, sodass das Gateway den zweiten Austausch durchführt:

"credentialProviderConfigurations": [{
    "credentialProviderType": "OAUTH",
    "credentialProvider": {"oauthCredentialProvider": {
        "providerArn": provider_arn,          # the JWT_AUTHORIZATION_GRANT provider from Part 1
        "scopes": ["xaa:read", "xaa:write"],  # must equal the ID-JAG's scopes
        "grantType": "TOKEN_EXCHANGE",
    }},
}]

Abbildung 3 zeigt ein auf diese Weise konfiguriertes Target.

Abbildung 3: Das task manager-Target löst das ID-JAG über den Credential Provider aus Teil 1 ein

Drei Details sind hier wichtig. Erstens müssen, wie in Teil 1, die Scopes des Targets denen des ID-JAG entsprechen. Zweitens geben Sie jedem Target ein statisches Tool-Schema (listingMode gesetzt auf DEFAULT mit einem Inline- mcpToolSchema), damit die Tool-Namen, auf die Ihre Cedar-Policies verweisen, beim Schreiben festgelegt sind. In unseren Tests konnten Policies, die Tools namentlich erwähnen, auch nicht an dynamisch aufgelistete Targets angehängt werden. Drittens paginiert das Gateway tools/list pro Target, sodass Ihr Client dem Pagination-Cursor folgen muss, sonst verschwinden Tools aus späteren Targets. AgentCore Identity bewahrt das Token aus dem Austausch des Gateways auf, sodass ein einziges einmal verwendbares ID-JAG jeden Tool-Aufruf in einer Session bedient. In unseren Tests öffnete es damit auch eine zweite Session innerhalb seiner Lebensdauer von 5 Minuten.

Da sich ein Credential Provider als ein Okta-Agent authentifiziert, geben Sie jedem Agenten sein eigenes Gateway und seinen eigenen Provider. Das Beispiel 08-okta-xaa-delegation-chain geht einen anderen Weg, bei dem ein Gateway-Interceptor beide Austausche selbst durchführt.

Tools mit Cedar an Agenten binden

Hängen Sie eine Policy in der AgentCore-Engine an das Gateway im ENFORCE Modus an und schreiben Sie Nur-Erlaubnis-Policies. Cedar stellt JWT-Claims als Tags bereit. Eine Policy, die ein fehlendes Tag liest, erzeugt einen Fehler und wird übersprungen. Eine übersprungene permit gewährt nichts, sodass Default-Deny gilt, aber eine übersprungene forbid blockiert nichts. Sichern Sie jedes Tag mit hasTag:

permit(
  principal is AgentCore::OAuthUser,
  action in [AgentCore::Action::"taskmanager___create_task",
             AgentCore::Action::"taskmanager___update_task_status"],
  resource == AgentCore::Gateway::"<gateway-arn>"
) when {
  principal.hasTag("client_id") && principal.getTag("client_id") == "<agent-client-id>" &&
  principal.hasTag("scope") &&
  (principal.getTag("scope") == "xaa:write" ||
   principal.getTag("scope") like "xaa:write *" ||
   principal.getTag("scope") like "* xaa:write" ||
   principal.getTag("scope") like "* xaa:write *")
};

Das Scope-Tag enthält den durch Leerzeichen getrennten scope -Claim der ID-JAG, sodass die vier Bedingungen xaa:write nur als ganzen Eintrag matchen. Ein Scope wie xaa:write-admin matcht nicht. Eine passende Policy, auf dieselbe Weise geschrieben, erlaubt die Read-Tools mit xaa:read. Prüfen Sie, dass jede Policy ACTIVE ist, bevor Sie die Engine anhängen: eine Engine, deren Policies nicht erstellt wurden, lässt das Gateway jeden Aufruf verweigern. Cedar bindet Tools an den Agenten und dessen delegierten Scope, und der MCP-Server entscheidet weiterhin anhand des groups -Claims über die Berechtigung jedes Benutzers, wie in Teil 1.

Richten Sie den Agenten auf das Gateway

Agent A leitet nun sein eingehendes ID-JAG an das Gateway weiter, statt AgentCore Identity selbst aufzurufen:

id_jag = context.request_headers["Authorization"].removeprefix("Bearer ")  # allowlisted header
tools = make_client(GATEWAY_URL, id_jag)  # the Gateway redeems the ID-JAG for each target

Entfernen Sie die AgentCore-Identity-Anweisungen aus Teil 1 aus der Ausführungsrolle des Agenten. Das ist die einzige Änderung an der Rolle, die nun keine Token-Austausch- oder Secret-Berechtigungen mehr enthält, da die Rolle des Gateways die Berechtigung zum Austausch von Tokens besitzt. Behalten Sie allowedClients auf dem Authorizer der Runtime bei.

Betreiben Sie einen zweiten Agenten auf Amazon EKS

Unser zweiter Agent, ein Reporting-Agent, führt denselben Code auf Amazon EKS mit einer eigenen Okta-Registrierung aus. Seine Resource Connection erlaubt nur xaa:read, und er besitzt sein eigenes Gateway und seinen eigenen Credential Provider. EKS Pod Identity gibt dem Pod eine IAM-Rolle, die Modelle aufrufen sowie seine eigenen Logs und Traces schreiben kann, und nichts weiter. Das AWS Distro for OpenTelemetry (ADOT) SDK exportiert seine Traces. Das agents-on-eks-Beispiel zeigt das Pod-Identity-Setup.

Außerhalb der AgentCore Runtime sitzt kein Authorizer vor dem Pod, daher validiert der Agent die ID-JAG vor einem Modellaufruf. Er prüft die Signatur, den Issuer, die Audience, den Tokentyp oauth-id-jag+jwt, die Ablaufzeit und ob client_id ihm selbst gehört. Wenn Sie die Agent-Prüfung aus Teil 1 in den MCP-Servern beibehalten haben, fügen Sie die Client-ID von Agent B zu REGISTERED_AGENTShinzu. Zwei Einstellungen haben uns ausgebremst. Der allgemeine Node-Pool von EKS Auto Mode läuft nur auf amd64, also bauen Sie Multi-Architektur-Images. Und das AgentCore Python SDK, eine Funktion von Amazon Bedrock AgentCore, bindet an localhost außer Sie setzen DOCKER_CONTAINER=true.

Verfolgen Sie jede Entscheidung mit AgentCore Observability

Die Spans in diesem Abschnitt stammen von AgentCore Observability, der Komponente in Abbildung 1, die zwischen den Agents und CloudWatch sitzt. Runtime, Gateway, Identity und Policy geben für jeden Hop OpenTelemetry-Spans aus, ohne Codeänderungen, nachdem Sie Transaction Search und die Trace-Zustellung aktiviert haben. Ihre eigenen Dienste fügen ihre Spans mit dem AWS Distro for OpenTelemetry (ADOT) hinzu. CloudWatch Transaction Search sammelt sie, die AgentCore-Konsole liest sie als Agent-Traces, und Amazon CloudWatch Omni liest dieselben Spans als traces.default, was es einer einzigen Abfrage ermöglicht, sie neben Okta’s Ereignissen zu platzieren.

Ein Tool-Aufruf erzeugt daher diese Kette von Spans, wobei jeder die Kontrolle benennt, die eine Entscheidung getroffen hat:

Okta’s System Log ist der eine Datensatz, den AWS nicht ausgeben kann, daher müssen Sie ihn selbst einbringen. Abbildung 4 zeigt beide Pfade, die sich in Omni treffen.

Abbildung 4: Der Audit-Pfad, bei dem Spans und Okta’s System Log CloudWatch erreichen und eine einzige Omni-Abfrage sie verbindet

So richten Sie es ein:

1. Aktivieren Sie CloudWatch Transaction Search, aktivieren Sie die Trace-Zustellung für jedes Gateway (siehe dieses Beispielskript) und fügen Sie ADOT zum BFF und den MCP-Servern hinzu. Der Task-Manager schreibt jede Entscheidung, den Benutzer und den Agent in einen authz.check span.
2. Erstellen Sie in Okta einen Log Stream für Amazon EventBridge. Okta liefert jedes Ereignis an einen Partner-Event-Bus in Ihrem Konto, und eine Regel schreibt es in eine CloudWatch Logs-Loggruppe. In unseren Tests trafen die Ereignisse etwa 1 Sekunde nach ihrer Veröffentlichung durch Okta ein. Jedes ID-JAG-Grant-Ereignis nennt den Agenten als Akteur, den Benutzer als Ziel sowie die gewährten Scopes und die Ressourcenverbindung.
3. Richten Sie einen Omni-Bereich im Konto und in der AWS-Region ein, fügen Sie die Okta-Loggruppe zur CloudWatch-Dataset-Integration hinzu und speichern Sie eine View, view.xaa_authz_decisionsüber die authz.check spans.

Eine einzige Abfrage verknüpft dann jedes ID-JAG-Grant mit den Entscheidungen, zu denen es geführt hat:

SELECT o.okta_time, o.agent, o.user_email, o.granted, a.decision_time, a.decision, a.reason
FROM (SELECT `@timestamp` AS okta_time, detail['actor']['id'] AS agent_id,
             detail['actor']['displayName'] AS agent,
             array_element(regexp_match(`@message`, '"type"\s*:\s*"User"\s*,\s*"alternateId"\s*:\s*"([^"]+)"'), 1) AS user_email,
             detail['debugContext']['debugData']['grantedScopes'] AS granted
      FROM "logs.default"
      WHERE `@timestamp` BETWEEN NOW() - INTERVAL '1' HOUR AND NOW()
        AND detail['eventType'] = 'app.oauth2.token.grant.id_jag') o
JOIN (SELECT `@timestamp` AS decision_time, user_id, agent_client_id, decision, reason
      FROM "view.xaa_authz_decisions"
      WHERE `@timestamp` BETWEEN NOW() - INTERVAL '1' HOUR AND NOW()) a
  ON a.user_id = o.user_email AND a.agent_client_id = o.agent_id
 AND a.decision_time BETWEEN o.okta_time AND o.okta_time + INTERVAL '5' MINUTE

Für Alice zeigt das Ergebnis, dass Okta dem Task-Agenten die Aufgabe gewährt, xaa:read xaa:write für sie, dann der MCP-Server sie ablehnt, create_task 16.7 Sekunden später und danach erlaubt, list_tasks wie Abbildung 5 zeigt.

Abbildung 5: Die Omni-Abfrage verknüpft Alices ID-JAG-Gewährung im System Log von Okta mit den beiden Entscheidungen, zu denen sie führte

Jede Anfrage ist auch ein Trace, vom BFF über den Agenten, die Identitäts- und Richtlinienprüfungen des Gateway bis zur Entscheidung des MCP-Servers, wie Abbildung 6 zeigt. Omni markiert den Trace als Fehler, weil der create_task -Aufruf des Agenten die Ablehnung zurückgab.

Abbildung 6: Ein Trace für Alices Anfrage, vom Tool-Aufruf des Agenten über die Identitäts- und Cedar-Prüfungen des Gateway bis zum Deny des MCP-Servers

Zwei Instrumentierungsdetails sind wichtig. ADOT ermittelt die Region und signiert seine Exporte über botocore, daher fügen Sie botocore zu Diensten hinzu, denen es fehlt. Bis wir das taten, exportierten unsere MCP-Server keine Spans. Und der Agent-Modus von ADOT deaktiviert die Instrumentierung für HTTP-Client-Bibliotheken wie requests und urllib3 standardmäßig, setzen Sie daher OTEL_PYTHON_DISABLED_INSTRUMENTATIONS in Ihrem BFF, um diesen Standard mit einer Liste zu überschreiben, die den HTTP-Client des BFF (requestsbei uns) auslässt, andernfalls erreicht sein Trace-Kontext nicht den Agenten.

Ergebnisse validieren

Wir haben jede Prüfung über beide Gateways mit den Benutzern aus Teil 1 ausgeführt. Jede Sitzung listete die Tools auf, rief dann list_tasks, create_taskauf und eine Mitarbeiterabfrage:

Über die bereitgestellten Agenten stimmten die Ergebnisse überein: Agent A verweigerte Alice und Carol den Zugriff und erstellte Bobs Aufgabe, und Agent B teilte Bob mit, dass es kein Werkzeug zum Erstellen von Aufgaben habe. Derselbe Benutzer erhielt über verschiedene Agenten unterschiedliche Berechtigungen, und Okta entschied darüber.

Diese Anfragen stoppten an der Haustür:

Das Gateway liefert denselben generischen Fehler sowohl für einen falschen Agenten als auch für den falschen Tokentyp, daher prüfen Sie Ihre Konfiguration anhand der client_id und aud des Tokens, wenn Sie ihn sehen.

Die Identitäts- und Politikarbeit des Gateways ist gering im Vergleich zum Tool selbst. Mediane und 90. Perzentile aus 24 Stunden von Gateway-A-Spans in Omni:

Die Identitäts- und Politik-Spans für einen Tool-Aufruf ergeben bei ihren Medianen zusammen etwa 0.2 Sekunden, und der eigene authz.check -Span des MCP-Servers dauerte unter 1 Millisekunde. Gateway B zeigte dasselbe Muster, mit GetResourceOauth2Token bei 408 Millisekunden im Median.

Cross App Access oder benutzerbezogene Zustimmung

XAA gilt, wenn der Autorisierungsserver der Zielanwendung ein ID-JAG akzeptiert. Dort entscheidet Ihr Okta-Administrator, welcher Agent für welche Benutzer handeln darf, die Benutzer sehen keine Zustimmungsaufforderung, und Okta bewertet die Richtlinie bei jeder Tokenanforderung. Anwendungen mit eigenen Autorisierungsservern, wie GitHub, verlassen sich stattdessen auf die jeweilige OAuth-Zustimmung jedes Benutzers. Abbildung 7 vergleicht die beiden Varianten, so wie wir sie gemessen haben.

Abbildung 7: Cross App Access verglichen mit benutzerbezogener OAuth-Zustimmung, mit dem von uns gemessenen Widerrufsverhalten

Wir haben die AWS-Beispielanwendung bereitgestellt 07-consent-portal-auth-code-flow-targets neben unserem Stack, wobei Okta Benutzer bei einem AgentCore Identity-Zustimmungsportal und ein GitHub-Ziel an seinem eigenen Gateway anmeldete. Alice verband über das Portal ein GitHub-Testkonto, und Bob hat nie eines verbunden. Der Beitrag Verwaltung der OAuth-Zustimmung von Endbenutzern für KI-Agenten mit Amazon Bedrock AgentCore beschreibt diesen Ablauf vollständig. Dies haben wir beobachtet:

Die beiden Abläufe widerrufen unterschiedlich. Bei XAA stoppen Oktas Kontrollen die nächste ID-JAG-Ausstellung, und ausgestellte Token laufen nach etwa 5 Minuten ab. Im Zustimmungsablauf kontrolliert Okta nur die Anmeldung: Die gespeicherte Berechtigung überdauerte die Sperrung und blieb bestehen, bis wir sie trennten. Wählen Sie je nach Zielanwendung, nicht einmalig für das gesamte Unternehmen.

Für welche Bereiche dieses Muster gilt

In Medien und Unterhaltung kommt die Flotte schnell an. Ein Studio-, Streaming- oder Spieleunternehmen hat Agenten für Produktionsverfolgung, Titel- und Asset-Metadaten, Rechte und Lokalisierung sowie Zuschauer- oder Spielersupport, wobei jeder vor einem anderen System mit seinem eigenen Autorisierungsmodell und seinen eigenen Auditoren sitzt. Die Frage ist nicht, ob ein einzelner Agent regiert werden kann. Es geht darum, ob der hundertste auf dieselbe Weise regiert wird und ob ein Administrator noch beantworten kann, welche Agenten für welche Benutzer auf welche Systeme zugreifen.

Nichts davon ist spezifisch für diese Branche. Der Agent ist eine Identität in Ihrem IdP, das Ziel ist ein OAuth 2.0-Autorisierungsserver, und das Gateway ist der Ort, an dem Autorisierung entschieden wird. Teams im Finanzwesen, im Gesundheitswesen und im öffentlichen Sektor stellen unterschiedliche Ressourcen hinter dieselbe Tür und erhalten denselben Audit-Pfad.

Ausblick: Observability und Evaluierungen

Dieser Beitrag nutzt AgentCore Observability für einen einzigen Zweck: um zu beweisen, dass jede Erlaubnis und jede Ablehnung auf eine Kontrolle zurückverfolgt werden kann. Darin steckt mehr als das, und es ist ein eigenes Arbeitsgebiet. Die Spans tragen bereits die Modell- und Tool-Latenz hinter jeder Governance-Entscheidung, Transaction Search kann bei einer Spitze von Ablehnungen Alarm schlagen, und AgentCore evaluations können das Verhalten eines Agenten anhand Ihrer eigenen Kriterien bewerten, online für Live-Traffic oder auf Anforderung über einen ausgewählten Satz von Spans. Ein späterer Beitrag widmet sich dem: was man an einem regierten Agenten messen sollte, welche Evaluatoren einen Agenten aufspüren, der Erfolg meldet, nachdem ein Tool-Aufruf abgelehnt wurde, und wie man beides betreibt, ohne dass Ihre Traces zu Ihrer größten Rechnung werden.

Aufräumen

Um laufende Kosten zu vermeiden, löschen Sie die Ressourcen aus Teil 2 und folgen Sie dann den Bereinigungsschritten in Part 1:

1. Löschen Sie den Amazon EKS-Cluster (eksctl delete cluster) und sein Amazon Elastic Container Registry (Amazon ECR)-Repository.
2. Löschen Sie die Gateways und ihre Ziele, dann die Policy in den AgentCore-Engines und anschließend den Credential Provider von Agent B.
3. Löschen Sie den CloudWatch-Omni-Space und die Domain, die Dataset-Integration, die Amazon-EventBridge-Regel und den Partner-Event-Bus sowie die CloudWatch-Log-Gruppen.
4. Wenn Sie Beispiel 07 bereitgestellt haben, folgen Sie dessen Bereinigungsschritten.
5. Löschen Sie die von Ihnen erstellten IAM-Rollen und -Policies.
6. Löschen Sie in Okta den Log-Stream und deaktivieren Sie Agent B sowie die verknüpfte App und löschen Sie diese.

Fazit

In diesem Beitrag haben Sie die Part 1 -Lösung von einer Topologie, die für wenige Agenten und Tools geeignet ist, zu einer weiterentwickelt, die vielen standhält. Das Gateway wurde zur einzigen Eingangstür und machte Okta’s Grant nutzbar, sodass die Agenten keine Tool-Credentials hielten. Cedar-Richtlinien, die von Policy in AgentCore ausgewertet wurden, ersetzten die Prüfung, die in jeden Server kopiert worden war. Ein zweiter Agent auf Amazon EKS trat unter seiner eigenen Okta-Identität bei. Und AgentCore Observability, neben Okta’s System Log in CloudWatch Omni, verfolgte jede Erlaubnis und jede Ablehnung zurück zum Agenten, zum Nutzer und zur Kontrolle, die sie entschieden hatte. Der Governance-Mechanismus änderte sich nicht – und das ist der Punkt: Nur die Topologie um ihn herum tat es.

Um loszulegen, erkunden Sie die AgentCore samples und Okta’s Cross App Access documentation. Für einen einfachen Token-Austausch über ein Gateway lesen Sie Implementierung des On-Behalf-Of-Token-Austauschs für Multi-Tenant-Agenten mit Amazon Bedrock AgentCore Gateway.

Über die Autoren