Der blinde Fleck der KI-Sicherheit in Ihrem Unternehmen
Die Fähigkeit, drei Fragen zu beantworten, entscheidet darüber, ob Ihre KI-Agenten unter Kontrolle sind:
- Wo sind meine Agenten?
- Womit können sie sich verbinden?
- Was können sie tun?
Für die meisten Sicherheitsverantwortlichen gibt es keine klare Antwort auf die zweite Frage.
Der Grund, warum dies so schwer zu beantworten ist, liegt darin, dass Agenten, die geschäftskritische Aufgaben ausführen, oft nicht intern entwickelt werden. Bisher gab es keinen Standardweg für Claude Code, GitHub Copilot oder Salesforce Agentforce, um Anmeldedaten bei Okta abzurufen, ihren Scope einzuhalten oder ihre Aktivitäten zu protokollieren.
Die übliche Ausweichlösung sind langlebige API-Keys: umfassender Zugriff, keine Benutzerzuordnung, kein Audit-Trail und nur ein offengelegter Berechtigungsnachweis von einer Sicherheitsverletzung entfernt. Und wenn etwas schiefgeht, können Sie Ihren Prüfer:innen höchstwahrscheinlich nicht die entscheidenden Informationen liefern, die sie benötigen, wie z. B. welcher Agent auf die Daten zugegriffen hat, in wessen Auftrag der Agent gehandelt hat und nach welcher Richtlinie er agierte.
Das Ergebnis: die erhöhte Wahrscheinlichkeit einer Sicherheitsverletzung. Und wenn es zu einer Sicherheitsverletzung kommt, könnten Sie mit regulatorischen Risiken, fehlgeschlagenen Audits und den Betriebskosten für den manuellen Entzug der Zugriffsrechte in allen Systemen, auf die der Agent zugegriffen hat, konfrontiert werden.
So sieht das in der Praxis aus: Ein Entwickler benötigt einen Agenten, der auf GitHub und Slack zugreift. Er hinterlegt ein Personal Access Token und ein Slack-Token direkt in der Konfiguration des Agenten. Das Ergebnis: Ein Agent verfügt nun über dauerhaften Zugriff auf die Quellcode-Verwaltung und die internen Kommunikationskanäle.
Die Anmeldedaten befinden sich in einer ungeschützten Datei. Niemand kann sagen, welche Aktionen vom Agenten und welche vom Menschen stammten. Wenn ein vergifteter Prompt diesen Agenten kompromittiert, sind die Token ebenfalls betroffen.
Aktive Anmeldedaten haben kein Ablaufdatum und keinen Audit-Trail, was sie zu einer vorprogrammierten Sicherheitsverletzung macht. Multiplizieren Sie das mit jedem Entwickler und jedem Programmierassistenten, den Ihre Teams nutzen.
Warum die Governance von KI-Agenten eine Laufzeit-Identität erfordert
Die Steuerung von Agenten erfordert Identitätsdurchsetzung zur Laufzeit. Ohne dies verliert man die Fähigkeit, die wichtigsten Fragen zu beantworten, wenn etwas schiefgeht.
Der effizienteste Ort, um Schlüsselinformationen zu erfassen – etwa welcher Agent auf diese Daten zugegriffen hat, in dessen Auftrag und unter welcher Richtlinie –, ist der Moment, in dem ein Tool-Abruf ausgeführt wird. Nicht bei der Konfiguration, nicht im Nachhinein. Das erfordert eine Identity-Ebene im Anfragepfad.
Traditionelle Gateways vs. Identity-zentrierte Gateways
| Funktion | Traditionelles API/MCP-Gateway | Identity-zentrierter Agent Gateway |
|---|---|---|
| Hauptschwerpunkt | Traffic-Routing, Load-Balancing und Rate-Limiting | Identitätsprüfung und Durchsetzung von Richtlinien |
| Benutzerzuordnung | Keine (erfasst IP/System, nicht einzelne Benutzer:innen) | Ordnet jeden Aufruf einem bestimmten Agenten und menschlichen Benutzer zu |
| Anmeldedaten-Management | Speichert oder überträgt statische, langlebige API-Keys | Vermittelt dynamisch kurzlebige, isolierte Tokens |
| Zugriffswiderruf | Erfordert die Rotation von Schlüsseln in allen nachgelagerten Apps | Sofortiger Widerruf am Gateway-Endpoint |
Wie Agent Gateway Tool-Aufrufe mit Ihren Zugriffsrichtlinien absichert
Agent Gateway, eine neue Funktion in Okta for AI Agents, schließt diese Lücke. KI-Agenten können über einen einzigen, durch Okta gesicherten Endpoint sicher auf Unternehmens-Tools zugreifen. Agent Gateway vermittelt Anmeldedaten zur Laufzeit, ordnet Tool-Aufrufe zu und erfordert keine Codeänderungen am Agenten. Das Ergebnis: Security-Teams können ihre Audit-Fragen beantworten, und KI-Teams können schneller ausliefern.
Okta ist der Identity Provider im Pfad: Er verifiziert den Agenten, steuert, welche Tools dieser verwenden kann, bewahrt die Anmeldedaten auf, sodass der Agent nicht darauf zugreifen kann, und protokolliert Tool-Aufrufe unter einer verwalteten Identität.
Das Agent Gateway befindet sich im Pfad der Tool-Aufrufe Ihrer Agenten und beantwortet eine entscheidende Frage aus dem Konzept für den sicheren Einsatz von Agenten in Unternehmen: Womit können sich Ihre Agenten verbinden?
Agent Gateway setzt Richtlinien zur Laufzeit durch. Doch eine Durchsetzung zur Laufzeit setzt voraus, dass bekannt ist, wer Ihre Agenten sind, worauf sie zugreifen dürfen und welche Richtlinien für sie gelten. Okta for AI Agents bietet das Identity- und Governance-Fundament, indem es Agenten in Ihrem gesamten Unternehmen entdeckt, onboarded, schützt und steuert.
Die Agent-Gateway-Architektur
Agent Gateway liefert drei entscheidende Ergebnisse:
- Durchsetzung: Sie steuern den Agentenzugriff auf Unternehmenstools zentral und können ihn sofort widerrufen
- Sicherheit: Agenten verfügen nur über kurzlebige Token, sodass Angreifende keine nachgelagerten Anmeldedaten exfiltrieren können
- Transparenz: Alle Aktionen sind systemübergreifend mit vollständiger Zuordnung auditierbar
Sie müssen den Code des Agenten nicht besitzen. Agent Gateway bietet herstellerneutralen Schutz über Plattformen und Clouds hinweg, einschließlich Claude Code, Cursor, GitHub Copilot, Salesforce Agentforce und jedem Agenten, den Ihre Teams auf einen MCP-Endpoint richten können.
Integration von Agent Gateway in Ihre bestehende Infrastruktur
Agent Gateway ersetzt Ihr bestehendes MCP oder API-Gateway nicht. Stattdessen legt es eine Identitäts- und Richtlinienebene über Ihre aktuelle Infrastruktur.
Ihr bestehendes Gateway übernimmt weiterhin Routing, Anzahlbegrenzung und Konnektivität. Das Agent Gateway übernimmt die Identitätsdurchsetzung.
Ihre Teams richten ihre Agenten-Clients einfach auf den Endpoint des Agent Gateways aus. Es sind keine Codeänderungen an den Agenten und keine Anpassungen an nachgelagerten Systemen erforderlich. Der Agent führt einen Aufruf durch und erhält eine Antwort. Was sich ändert: Sämtliche Tool-Aufrufe laufen von nun an über die Okta-Richtlinien.
Unterstützte Muster für Anmeldedaten
Agent Gateway unterstützt derzeit zwei Muster für Anmeldedaten:
- Cross-App Access (XAA): Das neue Protokoll für sicheren Agent-zu-App-Zugriff auf Okta-fähige Ressourcen
- Vermittelte Zustimmung: Der Secure Token-Dienst (STS) von Okta vermittelt dynamisch die OAuth-Zustimmung für externe Systeme wie GitHub und Slack
Die Erfahrung des Agenten ist in beiden Fällen identisch.
Absicherung von On-Premises-Anforderungen mit MCP Bridge
Organisationen mit strengen regulatorischen Anforderungen – wie etwa FedRAMP-Compliance, private Netzwerke oder Vorgaben zur Datenresidenz – können MCP Bridge bereitstellen.
Über Okta Professional Services verfügbar, bietet MCP Bridge eine ähnliche Identity-Durchsetzung und Isolierung von Anmeldedaten innerhalb Ihrer eigenen Infrastruktur.
So starten Sie noch heute mit dem Agent Gateway
Wenn Ihr Security-Team die Tool-Aufrufe von KI-Agenten aus der letzten Woche überprüfen würde, könnte es dann feststellen, welcher Agent gehandelt hat, in wessen Auftrag, auf welche Daten er zugegriffen hat und ob Anmeldedaten offengelegt wurden?
Ein herkömmliches MCP-Gateway kann Tool-Aufrufe weiterleiten, kann jedoch nicht den Identitätskontext bereitstellen, der zur Beantwortung dieser Fragen erforderlich ist.
Ein Identity-zentriertes Gateway kann. Es zeigt zum Zeitpunkt der Ausführung jedes Aufrufs, welcher Agent für wen und gemäß welcher Richtlinie auf welche Daten zugegriffen hat.
Gehören Sie zu den Ersten, die Agent Gateway testen. Wir bieten diese neue Okta for AI Agents Funktion als Research-Release an. Um Ihr Interesse zu bekunden, bewerben Sie sich für die Teilnahme an unserem Research Partner Program.
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.
