Was ist Agent Gateway?
Agent Gateway ist eine Laufzeit-Ebene zur Identitätsdurchsetzung innerhalb von Okta for AI Agents. Es validiert jede Agent-zu-Tool-Anfrage anhand von Identitätsrichtlinien mittels Token-Austausch nach RFC 8693. Im Gegensatz zu herkömmlichen Gateways, die auf gemeinsam genutzten Dienstschlüsseln basieren, erfordert das Agent Gateway Anmeldedaten, die sowohl den handelnden KI-Agenten als auch die menschlichen Nutzer:innen benennen. Dies verhindert Confused-Deputy-Angriffe und die unbefugte Vererbung von Berechtigungen.
Wenn ein KI-Agent in Ihrer Umgebung genau jetzt außer Kontrolle geraten würde, könnten Sie dann sagen, in wessen Auftrag er handelte, worauf er zugegriffen hat und wann? Viele Security-Teams können das nicht.
KI-Agenten werden schneller bereitgestellt als die Kontrollen, die sie regulieren sollen. Gateways können Agenten mit Tools verbinden. Allerdings können Ihnen nicht viele sagen, in wessen Auftrag ein Agent handelt. Das ist eine Lücke, die Angreifer:innen ausnutzen können, und sie wird erst sichtbar, wenn bereits etwas schiefgelaufen ist.
Gateways werden als Kontrollmechanismus verkauft, aber die meisten können nicht überprüfen, wer tatsächlich hinter einer Anfrage steckt. Ohne dies kontrollieren sie nichts – sie leiten lediglich Aufrufe weiter und protokollieren, was passiert ist, wobei sie die Berechtigungen nutzen, die ihnen erteilt wurden. Ohne Identität als Grundlage ist ein Gateway ein Kontrollpunkt ohne durchsetzbare Regeln, ohne zuordenbaren Akteur und ohne anwendbare Governance.
Oktas Agent Gateway schließt diese Lücke. Es ist die Runtime-Enforcement-Ebene in Okta for AI Agents. Überall dort, wo ein KI-Agent so konfiguriert werden kann, dass er ein externes Model Context Protocol (MCP) aufruft, validiert das Agent Gateway jeden Agent-zu-Tool-Aufruf anhand der Richtlinie, isoliert Anmeldedaten im Moment der Ausführung und erstellt einen einheitlichen Audit-Trail.
Okta for AI Agents ergänzt die Identity- und Governance-Grundlage rund um das Agent Gateway: Erkennung von Agenten, Registrierung als vollwertige Identitäten, Zugriffs-Workflows, Zertifizierungskampagnen und systemübergreifende Audit-Korrelation. Agent Gateway ist ab heute als Teil von Okta for AI Agents allgemein verfügbar. Dies beantwortet die dritte Frage aus dem Konzept für den sicheren Einsatz von Agenten in Unternehmen: „Was machen meine Agenten?“
In diesem Blog erfahren Sie mehr über eines der Hauptprobleme der meisten Agent-Gateways: Sie können einen Agenten mit einem Tool verbinden, aber sie können nicht verifizieren, in wessen Auftrag ein Agent handelt. Und Sie werden sehen, wie sich das Agent Gateway von Okta unterscheidet: Es verarbeitet einen Aufruf nur dann, wenn der Berechtigungsnachweis sowohl die Benutzer:in als auch den dahinterstehenden Agenten benennt, was dabei hilft, sicherzustellen, dass Berechtigungen nicht versehentlich geliehen, geteilt oder vererbt werden.
Warum können herkömmliche MCP-Gateways KI-Agenten nicht absichern?
Herkömmliche MCP-Gateways können Agentenanfragen an Tools weiterleiten, aber oft fehlt ihnen eine entscheidende Schutzfunktion: Sie können nicht überprüfen, in wessen Auftrag ein Agent handelt.
Die Confused-Deputy-Schwachstelle erklärt
Beginnen wir mit einem Beispielszenario, in dem Ihre Agenten über kein Gateway verfügen:
- Umfassende Provisionierung von Anmeldedaten: Ihr Team entwickelt einen HR-Assistenten zur Beantwortung von Fragen zu Mitarbeiterdaten. Damit es für alle funktioniert, die danach fragen, weist jemand ihm einen Service-Account mit Lesezugriff auf alle zu.
- Nicht autorisierte Benutzeranfrage: Katie ist Auftragnehmerin. Sie fragt den Agenten nach der Vergütung des CEOs.
- Umgehung der Richtlinie: Der Agent gibt es ihr und nutzt dabei den Zugriff, über den er rechtmäßig verfügt.
- Audit-Fehler: Die Anfrage sieht im Audit-Log komplett sauber aus.
Es wurde nichts gehackt. Das Einzige, was zwischen Katie und diesen Daten stand, war das eigene Urteilsvermögen des Agenten.
Das ist das Confused-Deputy-Problem: die Anfrage enthält die Abfrage der Nutzer:innen, aber nicht deren Autorisierung. Der Agent handelt auf Basis dessen, worauf er zugreifen kann, und nicht danach, was die anfragende Person tatsächlich wissen darf. Es ist eine jahrzehntealte Schwachstelle in der Funktionsweise von Berechtigungen, und genau das zeigt sich, wenn Sie einem Agenten weitreichenden Zugriff gewähren und darauf vertrauen, dass er sich selbst verwaltet.
Einschränkungen herkömmlicher MCP-Architekturen
Alles-oder-nichts-Widerruf
Der Widerruf gemeinsam genutzter Gateway-Anmeldedaten unterbricht den Zugriff für alle verbundenen Agenten, was Administratoren dazu veranlasst, zu weitreichende Anmeldedaten dauerhaft aktiv zu belassen:
- Der:die Administrator:in konfiguriert ein Gateway, das über eine gemeinsame Anmeldeinformation mit einem GitHub-MCP-Server verbunden ist.
- Jeder Agent, der sich über dieses Gateway verbindet, erbt denselben weitreichenden Zugriff
- Der Widerruf der Anmeldeinformation unterbricht den Zugriff für alle Agenten, die dahinter operieren
- Das Ergebnis: Niemand widerruft es
Bearer-Token für Einzelidentitäten
MCP wurde mit Blick auf das Confused-Deputy-Problem entwickelt. Aber es gibt eine grundlegende Einschränkung: MCP arbeitet mit OAuth 2.1-Bearer-Tokens, die nur eine Identität benennen. Ein Gateway kann das Token des Agenten nicht durchreichen – es muss ein neues ausstellen. Selbst wenn ein Gateway GitHub also mitteilen möchte: „Dies ist Katies Coding-Agent, der für Katie agiert“, kann es das nicht. Welche Identität es auch auswählt, sie wird zur einzigen, die GitHub sieht.
Schutzmaßnahmen für Prompt-Engineering versagen
Sie könnten versuchen, dies im Prompt zu beheben, indem Sie dem Agenten vorgeben, niemals auf Vergütungsdaten zuzugreifen. Wahrscheinlich wird er es auch nicht tun. Da die Zugangsdaten jedoch weiterhin Zugriff auf alles gewähren, besteht die einzige wirksame Schutzmaßnahme darin, dass der Agent von sich aus entscheidet, nicht hinzusehen – was genau das ursprüngliche Problem war.
Oktas Agent Gateway: Eine identitätsnative Laufzeitdurchsetzung für KI-Agenten, die eine Verbindung zu Unternehmenstools herstellen
Agent Gateway, eine neue Funktion von Okta for AI Agents, ist der Laufzeit-Kontrollpunkt, der bei jeder Aktion durchsetzt, womit sich ein Agent verbinden kann und was er tun darf. Aufrufe werden nur verarbeitet, wenn der Aufrufende Anmeldedaten vorweist, die beide Parteien benennen: die Person, welche die Aktion anfordert, und den Agenten, der die Anfrage ausführt. Diese Anforderung zur Durchsetzung von Identitäten unterscheidet Agent Gateway von einem einfachen Gateway, das den Datenverkehr lediglich weiterleitet.
Konfigurieren eines Agent Gateways.
Ein typisches Gateway kann authentifizieren, dass etwas eine Verbindung herstellen darf. Das Agent Gateway überprüft, für welche:n Benutzer:in die Anfrage bestimmt ist, welcher KI-Agent agiert und ob dieser Agent autorisiert wurde, im Namen dieser:dieses Benutzer:in zu handeln– und setzt dann die Richtlinie in dem Moment durch, in dem der Tool-Aufruf erfolgt.
Jeder Tool-Aufruf wird einer verwalteten Agentenidentität, einem/einer Endbenutzer:in, einem Tool und einem Ergebnis zugeordnet.
Nehmen wir an, Katie ist eine Mitarbeiterin und ein Agent ist im Begriff, in ihrem Namen einen Anruf zu tätigen. Einige Gateways authentifizieren den Aufrufer mit einem Plattformschlüssel und nehmen den:die Benutzer:in als Parameter entgegen:
POST /mcp HTTP/1.1
Authorization: Bearer <Plattform-API-Schlüssel><platform api key>
{ „user_id“: „Katie“, „tool“: „read_file“, ... }
Ein so aufgebautes Gateway kann den Schlüssel verifizieren, aber es kann Katie nicht verifizieren. Ihr Name ist lediglich Text in der Anfrage, eingegeben von der Person, die den Aufruf getätigt hat, sodass sich jede Person, die diesen Schlüssel besitzt, als eine beliebige Person ausgeben kann.
Agent Gateway akzeptiert diese Art von Anmeldeinformationen überhaupt nicht. Stattdessen implementiert Agent Gateway die RFC 8693-Delegierung, wodurch jeder Tool-Aufruf einen von Ihrem Identity-Anbieter ausgestellten Berechtigungsnachweis vorlegen muss, der zwei unterschiedliche Identity-Claims enthält:
- Das Subjekt (
sub): Der:die authentifizierte Endbenutzer:in, der:die die Aktion anfordert - Der Akteur (
act): Der registrierte KI-Agent, der die Anfrage ausführt
Folgendes erwartet das Agent Gateway bei jedem Aufruf:
{
„sub“: „00uKatie456“,
„aud“: „https://acme.gateway.okta.com/mcp/servers/eng-tools“,
„act“: {
„sub“: „0oafxqCAJWWGELFTYASJ“,
„sub_profile“: „ai_agent web_app“
}
}
Der Aufruf gilt für sub, und act gibt an, wer ihn durchführt. sub_profile gibt an, dass der Aufrufer eine Anwendung und ein Agent ist.
Nichts wird vererbt, daher kann das Agent Gateway keine Benutzer:innen erfinden. Der sub in diesem Berechtigungsnachweis ist der:die einzige Benutzer:in, in dessen:deren Namen das Agent Gateway bei diesem Aufruf handeln darf. Wenn Agent Gateway einen Berechtigungsnachweis für den MCP-Server benötigt, tauscht es den Berechtigungsnachweis des Agenten mit Okta aus und erhält einen, der an dieselbe Person gebunden ist, was der in RFC 8693 definierten On-Behalf-Of-Semantik entspricht. Okta kann diese Anmeldeinformation nur zurückgeben, weil die Person zuvor auf dem MCP-Server über eine von Administrator:innen registrierte Verbindung zugestimmt hat.
So kann ein Agent das Agent Gateway nicht dazu bringen, für jemand anderen zu handeln. Katie kann immer noch fragen. Allerdings handelt das Agent Gateway nun mit einem an sie gebundenen Berechtigungsnachweis in ihrem Namen, wodurch sichergestellt wird, dass der Agent nur das tun kann, was Katie selbst tun könnte.
Matrix der Funktionen zur Identitätsdurchsetzung
Im Allgemeinen kann ein Gateway nur auf das reagieren, was bereits in den empfangenen Anmeldeinformationen enthalten ist. Ob diese Anmeldeinformation die tatsächliche Benutzer:innen- und Agentenidentität enthält oder gar keine, wird in dem Moment entschieden, in dem sie erstellt wird.
| Art der Anmeldeinformation, die von einem Gateway empfangen wird | Benutzerkontext erfasst | Agentenkontext erfasst | Agentenkontext erfasst |
|---|---|---|---|
| Gemeinsam genutzter Service-Schlüssel | – | – | Niedrig: keine Governance oder Zuordnung möglich |
| Nur-Benutzer-Token | Nur Benutzer:innen | Keine; jeder Agent sieht gleich aus | Mittel: Kann nicht zwischen Agentenaktivitäten und Benutzeraktivitäten unterscheiden |
| Delegiertes Token (RFC 8693) | Verifizierte:r Benutzer:in | Verifizierter Agent | Hoch: Vollständige Durchsetzung von Laufzeit-Richtlinien und Zuordnung |
Das Agent Gateway von Okta arbeitet nur in der dritten Reihe. Aufrufe werden nur verarbeitet, wenn es sich bei den Zugangsdaten um ein verifiziertes, delegiertes Token handelt, das sowohl die nutzende Person als auch den Agenten benennt.
Effektive Zugriffsregeln für Agenten
In der Praxis wird das, was ein Agent tatsächlich tun kann, durch die exakte Schnittmenge aus den Berechtigungen des Agent Gateways und den Zugriffsrechten der Benutzer:innen begrenzt:
Was der Agent tun kann = Was das Gateway zulässt ∩ Was Benutzer:innen bereits tun können
Was das Gateway zulässt ← vom Gateway durchgesetzt
Was Benutzer:innen bereits tun können ← vom MCP-Server durchgesetzt
Agent Gateway weiß, welcher Agent anfragt und welche Tools freigegeben sind. Der MCP-Server kennt seine eigenen Datensätze und weiß, welche Benutzer:innen darauf zugreifen dürfen. Sie benötigen beides.
Das Agent Gateway selbst ist ein registrierter Workload mit einem eigenen Principal und ohne Standing-Berechtigung, um auf irgendetwas zuzugreifen. Ein:e Administrator:in konfiguriert zwei Dinge, bevor ein Aufruf aufgelöst wird:
- Delegierungslink: Gewährt einem bestimmten Agenten die Berechtigung, im Namen der Benutzer:in an dieses Gateway zu delegieren. Ohne diesen wird der Austausch abgelehnt.
- Ressourcenverbindung: Gewährt diesem Gateway die Berechtigung, einen bestimmten MCP-Server zu erreichen, und definiert genau, welche Tools dieses Servers zugänglich gemacht werden.
Die Berechtigung wird weder von der aufrufenden Instanz abgeleitet noch durch die Anmeldeinformationen des Agenten gewährt. Der Zugriff ist auf die Delegierungs- und Ressourcenberechtigungen beschränkt, die ein:e Administrator:in konfiguriert.
Identity Governance ist auch die Grundlage für Cost Governance
KI-Agenten verursachen nicht nur ein Zugriffsrisiko – sie können auch in Maschinengeschwindigkeit Ausgaben generieren. Ein Agent, der wiederholt eine Premium-API aufruft, teure Workflows auslöst oder ressourcenintensive Tools einsetzt, kann unerwartete Kosten verursachen, lange bevor ein Mensch dies bemerkt.
Kostensteuerung beginnt mit der Zuordnung. Wenn sich mehrere Agenten eine Anmeldeinformation teilen, ist es schwierig, grundlegende Fragen zu beantworten, wie zum Beispiel: Welcher Agent hat die Aktivität generiert? Für wen hat er gehandelt? Welches Tool oder welche Ressource hat die Kosten verursacht?
Das Agent Gateway von Okta schafft den Identitätskontext, der zur Beantwortung dieser Fragen erforderlich ist. Da jede Anfrage sowohl mit dem:der Benutzer:in als auch mit dem in dessen:deren Namen handelnden Agenten verknüpft ist, können Organisationen die Agentenaktivität mit den Tools und Ressourcen korrelieren, auf die dieser zugreift. Dies schafft eine klarere Grundlage für die Überwachung der Nutzung, die Untersuchung unerwarteter Aktivitäten und die Anwendung von Governance bei der Skalierung von Agent-Bereitstellungen.
Bald verfügbar: Unterstützung für Cross App Access und ein Not-Aus-Schalter über das Agent Gateway
Agent Gateway-Unterstützung für Cross App Access
Agenten müssen auf gewöhnliche SaaS-Apps wie Slack oder Salesforce zugreifen können, und Okta bietet dafür ein Protokoll nach einem offenen Standard: Cross App Access. Sobald der Support verfügbar ist, wird Cross App Access es KI-Agenten ermöglichen, im Namen von Benutzer:innen sicher auf Anwendungen zuzugreifen, wobei beide Identitäten intakt bleiben. Der:die Administrator:in genehmigt einmalig, welche Apps Agenten nutzen dürfen, anstatt dass jede:r Mitarbeiter:in jede App selbst genehmigt.
Die Umsetzung über ein Gateway bietet einen echten Mehrwert: Es stellt einen zentralen Kontrollpunkt dar, um den Zugriff eines Agenten zu aktivieren oder zu deaktivieren, anstatt diesen App für App zu verwalten.
Agent Gateway wird in naher Zukunft App-übergreifenden Zugriff unterstützen. Dadurch kann das Gateway anzeigen, „diese Anfrage stammt von einer Berechtigung, die Sie bereits genehmigt haben“, und diese Assertion dann gegen ein neues Token eintauschen, ohne dass Änderungen aufseiten der App erforderlich sind. Dieser Mechanismus wird im IETF-Entwurf Identity Continuation Assertion vorgeschlagen.
Agent-Gateway-basierter Not-Aus-Schalter
Schließlich kann das Agent Gateway Anfragen in Echtzeit stoppen, da jeder Tool-Aufruf einen einzigen Durchsetzungspunkt zur Laufzeit durchläuft. Sobald die Not-Aus-Schalter-Funktionalität verfügbar ist, ermöglicht sie eine sofortige Deaktivierung des Agenten – inklusive bereits ausgestellter Tokens –, indem jede Anfrage abgelehnt wird, die ein auf einen deaktivierten Agenten ausgetelltes Token enthält. Da dies direkt an der Systemgrenze von Okta durchgesetzt wird, entfällt das Warten auf die jeweilige unabhängige Zugriffswiderrufung durch die einzelnen angebundenen Anwendungen.
So bewerten Sie ein KI-Agenten-Gateway: Vier entscheidende Fragen, die Sie stellen sollten
Vier Fragen zeigen Ihnen, wo ein beliebiges Gateway steht:
- Überprüfung des Ausstellers: Welchen Berechtigungsnachweis erhält der MCP-Server und wer hat ihn ausgestellt?
- Nachweis der Benutzeridentität: Kann das Gateway anzeigen, für welche:n Benutzer:in ein Aufruf bestimmt ist, oder ist der/die Benutzer:in ein Parameter, den der/die Aufrufer:in bereitstellt?
- Zustimmungsherkunft: Wessen Zustimmung hat den Zugriff des Agenten auf diesen MCP-Server autorisiert?
- Umgehungsrisiko: Verfügt der Agent jemals über einen Berechtigungsnachweis, der ohne das Gateway im Pfad funktioniert?
Agent Gateway wurde entwickelt, um alle vier zu beantworten.
Das Agent Gateway ist ein Teil eines größeren Ganzen: Okta for AI Agents ist die umfassendere Plattform, die Ihnen die Transparenz, Kontrolle und Governance bietet, die Sie benötigen, um die Agenten abzusichern, die Ihr Unternehmen einsetzt.
Agent Gateway ist in Okta for AI Agents ohne zusätzliche Kosten enthalten.
Bestehende Kund:innen: Wenden Sie sich an Ihre:n Account-Betreuer:in, um es noch heute zu nutzen.
Noch kein:e Kund:in von Okta for AI Agents? Laden Sie unser Datenblatt herunter, um zu erfahren, wie Okta for AI Agents Ihnen dabei helfen kann, Ihre KI-Agenten sicher über eine zentrale Steuerungsebene zu verwalten.
Jegliche Erwähnung zukünftiger Produkte, Funktionen, Funktionalitäten oder Zertifizierungen in diesem Blog dient ausschließlich zu Informationszwecken. Es handelt sich nicht um Zusagen zur Bereitstellung und sollte nicht als Grundlage für Kaufentscheidungen herangezogen werden.
Diese Materialien dienen ausschließlich allgemeinen Informationszwecken und stellen keine Rechts-, Datenschutz-, Sicherheits-, Compliance- oder Unternehmensberatung dar.
Der Inhalt gibt womöglich nicht den aktuellen Stand der relevanten Sicherheits-, Rechts- und Datenschutzfragen wieder. Sie allein sind dafür verantwortlich, sich von Ihren eigenen Rechts- und/oder Fachexperten beraten zu lassen, und sollten sich bei Entscheidungen bezüglich Compliance, Implementierung oder Kauf nicht auf diese Materialien verlassen.
Okta übernimmt keinerlei Zusicherungen oder Garantien in Bezug auf diesen Inhalt und haftet nicht für Verluste oder Schäden, die aus Ihrer Implementierung dieser Empfehlungen resultieren. Informationen zu den vertraglichen Zusicherungen von Okta gegenüber Kundenunternehmen finden Sie unter okta.com/agreements.
