Die Welle der agentenbasierten KI beschleunigt sich rasant. Was als Chatbots mit einfachen Tools begann, entwickelt sich nun zu autonomen digitalen Mitarbeitern, die tief in die Arbeitsabläufe von Unternehmen integriert sind.
Mit der zunehmenden Reife dieser Implementierungen wird eine kritische Sicherheitslücke immer deutlicher.
Viele aktuelle Agentenarchitekturen beruhen immer noch auf einem Modell, das man als „God Key“ bezeichnen kann. Dabei werden Benutzeridentität, Autorisierung und Tool-Zugriff durch umfassende, langlebige Anmeldeinformationen in einem einzigen gemeinsamen Geheimnis zusammengefasst.
Dieser Ansatz ist nicht sicher skalierbar.
Unternehmen, die Agenten in großem Umfang einsetzen wollen, müssen zu einer delegierten Identität und KI-gestützten Durchsetzungsmechanismen übergehen.
Nachfolgend finden Sie einen detaillierten Überblick über das eigentliche Problem und eine produktionsreife Lösung.
1. Das wahre Risiko: Überprivilegierte Agenten-Zugangsdaten
In vielen frühen Agent-Implementierungen – wie z.B. bei LangChain-ähnlichen Tools, benutzerdefinierten MCP-Servern und internen Tool-Gateways – wird die Authentifizierung häufig über statische Dienstanmeldedaten verwaltet:
- Langlebige API-Schlüssel
- Shared-Service-Konten
- breite OAuth-Client-Anmeldeinformationen
- oder grobe Arbeitsbelastung Identitäten
Zur Klarstellung: MCP selbst erfordert keine statischen Schlüssel. Das Protokoll unterstützt die richtigen OAuth- und delegierten Identitätsmodelle. In realen Implementierungen verwenden viele Agenten jedoch immer noch übergreifende, nicht benutzergebundene Anmeldeinformationen, um mit einzelnen MCP-Servern zu kommunizieren.
Dies ist die Quelle des Risikos.
Das Problem der gemeinsamen Identität (benutzerübergreifende Attribution)
Betrachten Sie ein Szenario, in dem:
- 50 Mitarbeiter nutzen einen einzigen Marketing-Agenten
- der Agent ruft GitHub mit einer Service-Anmeldung auf
In diesem Fall würden die GitHub-Protokolle einfach anzeigen: Agent_Service_Account hat Repo X gelöscht.
Was noch fehlt:
- welcher Mensch die Aktion ausgelöst hat
- ob der Benutzer autorisiert war
- ob die Aktion erwartet wurde
Aus Sicht von Audit und Forensik geht die Zuordnung verloren. Dies ist kein Fehler von MCP, sondern eine Lücke in der Identitätsweitergabe, die bei vielen Agentenimplementierungen auftritt.
Das Problem der zu weit gefassten Erlaubnis (werkzeugübergreifender Geltungsbereich)
Betrachten Sie einen MCP-Server, der mehrere Tools zur Verfügung stellt:
- read_file
- listen_dateien
- delete_file
Wenn sich der Agent mit einer einzigen, breit angelegten Berechtigung authentifiziert, kann jede erfolgreiche Eingabeaufforderung oder jedes Fehlverhalten des Agenten potenziell Tools mit höherem Risiko aufrufen. MCP ermöglicht es Servern zwar, die Autorisierung für einzelne Tools durchzusetzen, aber viele MCP-Dienste konzentrieren sich heute in erster Linie auf die Tool-Funktionalität und sind nicht dafür ausgelegt, als vollständige Punkte zur Durchsetzung von Unternehmensrichtlinien zu dienen.
Dies schafft eine erhebliche architektonische Lücke.
2. Die architektonische Realität: MCP-Server sind keine ZTNA-Gateways
In den meisten Unternehmen wird von internen Anwendungen nicht erwartet, dass sie selbst eine umfassende Authentifizierungs-, Autorisierungs- und Risikopolitiklogik implementieren. Stattdessen wird diese Verantwortung in der Regel in einer Zero Trust Network Access (ZTNA)-Schicht zentralisiert, die den Unternehmensanwendungen vorgelagert ist.
MCP-Dienste sollten auf die gleiche Weise betrachtet werden.
In der Praxis sind viele MCP-Server:
- Fokus auf die Ausführung der Werkzeuge
- Vertrauen in die vorgelagerte Identität
- grobe Authentifizierung oder Authentifizierung auf Dienstebene implementieren
- fehlende tiefgreifende Benutzer-/Gruppenrichtlinienmodelle
- keinen Token-Tausch durchführen
- sind nicht für zeitnahe Risikoentscheidungen ausgelegt
Die Erwartung, dass jeder MCP-Server als vollständige Zero Trust Enforcement Engine fungiert, ist weder realistisch noch skalierbar.
3. Warum ZTNA der natürliche Kontrollpunkt ist
ZTNA spielt bereits eine etablierte Rolle in der Unternehmenssicherheit:
- Fronting interner Anwendungen
- Zentralisierte Authentifizierung
- Durchsetzung von Zugriffsrichtlinien
- Bereitstellung einer einzigen Steuerungsebene
- Entlastung der Anwendungsteams
Die Anwendung dieses Modells auf MCP-Dienste bietet Unternehmen einen einheitlichen Ansatz zum Schutz sowohl herkömmlicher Anwendungen als auch des Zugriffs auf KI-gesteuerte Tools.
Eine konsistente Möglichkeit, sowohl herkömmliche Apps als auch KI-gesteuerte Tools zu schützen.
Die KI stellt jedoch eine neue Anforderung an ZTNA-Lösungen.
4. Traditionelle ZTNA ist blind für KI-Verhalten
Herkömmliche ZTNA-Lösungen basieren ihre Entscheidungen auf Faktoren wie:
- Benutzeridentität
- Gerätestellung
- Netzwerkkontext
- Anwendungsidentität
Agentischer KI-Verkehr fügt neue Risikodimensionen hinzu, wie z.B.:
- welches MCP-Tool gerade aufgerufen wird
- welche Argumente übergeben werden
- ob die Anfrage als Eingabeaufforderung erstellt wurde
- ob die Aktion ein hohes Risiko darstellt
- ob der Benutzer für dieses spezielle Tool autorisiert ist
Herkömmliche ZTNA-Lösungen können Kontrollen auf dieser Ebene nicht erkennen oder durchsetzen. Um MCP-Dienste sicher zu schützen, muss ZTNA das MCP-Protokoll und die KI kennen.
Was wir brauchen, ist kein Ersatz für ZTNA, sondern eine Weiterentwicklung von ZTNA.
MCP-fähige ZTNA: Die erforderliche Entwicklung
Die traditionelle ZTNA bleibt die richtige architektonische Eingangstür für Unternehmensanwendungen, einschließlich MCP-Dienste. Die Zentralisierung der Zugriffskontrolle außerhalb der Anwendung hat sich als skalierbar, überprüfbar und betrieblich effizient erwiesen.
Agentengesteuerte Arbeitsabläufe bringen jedoch zwei neue Anforderungen mit sich, für die die klassische ZTNA nicht ausgelegt war:
Delegierte Identität auf Benutzerebene für die Ausführung von Tools
Sichtbarkeit der MCP-Tool-Aktivitäten auf Protokollebene
Die Erfüllung dieser Anforderungen ersetzt die ZTNA nicht – sie entwickelt sie weiter.
Eine MCP-fähige ZTNA-Schicht erweitert das traditionelle Zero-Trust-Modell um zwei entscheidende Dimensionen: Identitätsdelegation und protokollabhängige Autorisierung.
Delegierte Identität: Warum der Token-Austausch erforderlich ist
Wenn ein KI-Agent ein MCP-Tool aufruft, muss der nachgeschaltete Dienst in der Lage sein, eine grundlegende Frage zu beantworten:
Für welchen Menschen wird diese Aktion durchgeführt?
Die Weitergabe eines umfassenden, langlebigen Benutzer-Tokens direkt an jeden MCP-Dienst ist weder sicher noch skalierbar. Es führt zu einer übermäßigen Verbreitung von Vertrauen und erhöht den Explosionsradius, wenn ein Token missbraucht wird.
Stattdessen verwenden moderne Zero Trust-Architekturen eine delegierte Identität.
In diesem Modell:
- der Benutzer authentifiziert sich beim IdP des Unternehmens
- der Agent gibt die Identität des Benutzers weiter
- die ZTNA-Durchsetzungsschicht validiert den Benutzer
- die Durchsetzungsschicht führt den Token-Austausch durch
- ein kurzlebiger, eng begrenzter Berechtigungsnachweis wird für den spezifischen MCP-Dienst geprägt
Dieser Ansatz stellt sicher, dass nachgelagerte Dienste nur die für den angeforderten Vorgang erforderliche Mindestberechtigung erhalten.
Der delegierte Token-Austausch ermöglicht es Unternehmen außerdem:
- konsequente Kontrollen der Lebensdauer durchsetzen
- Publikum normalisieren
- Verringern Sie den Explosionsradius des Tokens
- und die vollständige Benutzerzuordnung beibehalten
Aber Identität allein ist nicht ausreichend.
Warum die Kenntnis des MCP-Protokolls wichtig ist
Selbst bei perfekter Identität ist bei der traditionellen ZTNA immer noch nicht klar, was der Agent tatsächlich tut.
Aus der Netzwerkperspektive erscheint der MCP-Verkehr oft als Standard-HTTPS. Ohne Protokollbewusstsein kann die Durchsetzungsschicht nicht sehen:
- welches MCP-Tool gerade aufgerufen wird
- welche Argumente übergeben werden
- ob die Aktion ein hohes Risiko darstellt
- ob der Benutzer für dieses spezielle Tool autorisiert ist
Dies ist der wichtigste blinde Fleck.
Eine MCP-fähige ZTNA-Schicht umfasst ein tiefes Protokoll-Parsing, das die Daten extrahieren kann:
- Werkzeugname
- Tool-Argumente
- Sitzungskontext
- Benutzeransprüche
Diese Signale ermöglichen feinkörnige, KI-gesteuerte Autorisierungsrichtlinien, die weit über einfache Entscheidungen zum Anwendungszugriff hinausgehen.
Erst wenn sowohl die Identitätsdelegation als auch die Überprüfung auf MCP-Ebene eingerichtet sind, kann eine echte Durchsetzung der geringsten Rechte für agentenbasierte Arbeitsabläufe erreicht werden.
Kritisches Detail der Implementierung: Agenten müssen die Benutzeridentität weitergeben
Damit die delegierte Identität durchgängig funktioniert, muss die Laufzeit des Agenten die Informationen zur Benutzeridentität aktiv weitergeben. In vielen aktuellen Implementierungen wird der Benutzer am Frontend authentifiziert (z.B. mit ZTNA und OIDC), aber nachgelagerte Toolaufrufe erfolgen immer noch mit statischen Dienstanmeldedaten. In diesem Fall geht die Benutzerzuordnung verloren und die Kontrolle der geringsten Rechte ist nicht mehr gewährleistet.
Um AI-aware Zero Trust zu ermöglichen, muss der Agent oder das Agenten-Framework sicherstellen, dass ausgehende MCP- oder Tool-Anfragen eine überprüfbare, benutzergebundene Berechtigung für AI>Secure enthalten. Diese Fähigkeit ist in den meisten Agenten-Frameworks nicht automatisch vorhanden und erfordert in der Regel eine explizite Konfiguration und in einigen Fällen auch kleinere Codeänderungen.
Empfohlenes Produktionsmuster: Dual Identity Header
In produktiven AI>Secure-Implementierungen umfassen die Anfragen in der Regel zwei unabhängig voneinander überprüfbare Identitäten:
Identität des Agenten:
Autorisierung: Bearer
Benutzeridentität:
X-AI-User-Assertion:
Im Vorfeld delegiert:
Autorisierung: Bearer
Beide Token werden von AI>Secure unabhängig voneinander validiert, bevor eine Bewertung der Richtlinien stattfindet.
Was ändert sich im Agenten (Minimal)
Die meisten Agent-Frameworks erfordern nur geringfügige Änderungen, um dieses Muster zu unterstützen:
- richten Sie den MCP-Endpunkt auf AI>Secure
- das bestehende Agent JWT weiter senden
- einen ausgehenden Header hinzufügen, der den Benutzer-JWT enthält
Moderne Frameworks wie OpenClaw unterstützen in der Regel benutzerdefinierte ausgehende Header, so dass dieser Übergang unkompliziert ist. Es sind keine Änderungen am MCP-Protokoll erforderlich.
Wie AI>Secure Least Privilege durchsetzt
Wenn eine Anfrage AI>Secure erreicht, finden die folgenden Schritte statt:
- Die Identität des Agenten wird validiert
- Die Identität des Benutzers wird überprüft
- MCP-Verkehr wird geparst
- Feinkörnige Richtlinie wird ausgewertet
- AI>Secure führt einen Token-Tausch durch
- Ein kurzlebiges delegiertes Token wird stromaufwärts gesendet
Bevor die Anfrage weitergeleitet wird, entfernt AI>Secure die ursprünglichen Anmeldeinformationen und injiziert sie:
Autorisierung: Bearer
Dadurch wird sichergestellt, dass der MCP-Server nur eine ordnungsgemäß zugewiesene Identität erhält.
Womit AI>Secure konfiguriert werden muss
Upstream-Authentifizierung per MCP-Server
Für jeden MCP-Server wird AI>Secure mit der entsprechenden Upstream-Authentifizierungsmethode konfiguriert, z. B:
- OAuth-Träger
- API-Schlüssel
- mTLS
- andere unterstützte Methoden
Feinkörnige Autorisierungsrichtlinien
AI>Sicherheitsrichtlinien sind in der Lage, durchzusetzen:
- Werkzeug erlauben/verweigern Regeln
- Überprüfung der Argumente
- Benutzer-/Gruppenkontrollen
- risikobasierte Bedingungen
Identity Broker Konfiguration
Der AI>Secure Identity Broker übernimmt die folgenden Aufgaben:
- Validierung eingehender Benutzer-Tokens
- Überprüfung von Emittent und Publikum
- OAuth Token Austausch durchführen
- Prägung von kurzlebigen delegierten Token
- Scoping-Token für den Ziel-MCP-Dienst
- Durchsetzung von Lebenszeitbeschränkungen
- Ansprüche optional umwandeln
Mit diesen Mechanismen erhalten MCP-Server nur Anmeldedaten mit den geringsten Rechten und müssen selbst keine komplexe Identitätslogik implementieren.
Die Quintessenz
Die Herausforderung liegt nicht in einem Fehler des MCP-Protokolls. Das Kernproblem besteht darin, dass viele frühe (oder sogar noch aktuelle) Agent-Implementierungen auf Anmeldeinformationen beruhen, die übermäßig privilegiert sind und keine angemessene Zuordnung ermöglichen. Diese Berechtigungsnachweise gewähren übermäßige Berechtigungen und lassen nicht eindeutig erkennen, welcher Benutzer oder Agent eine bestimmte Aktion durchgeführt hat. Infolgedessen werden MCP-Dienste aufgefordert, Sicherheitskontrollen und Zugriffsrichtlinien durchzusetzen, für die sie eigentlich gar nicht vorgesehen sind, was eine unangemessene Belastung für ihre Implementierungen darstellt.
Indem Sie eine KI-fähige ZTNA-Schicht vor die MCP-Dienste stellen, können Unternehmen:
- Zugriffskontrolle zentralisieren
- Benutzer-Attribution bewahren
- Least Privilege pro Werkzeug erzwingen
- eine Überlastung der MCP-Dienstimplementierungen zu vermeiden
Unternehmen, die ihre Zero-Trust-Architektur an die KI-Ära anpassen, sind am besten positioniert, um digitale Mitarbeiter sicher zu skalieren. In der Ära der autonomen Agenten muss Zero Trust über die Frage hinausgehen, wer eine Verbindung herstellen darf – und was die KI tatsächlich tun darf.