Zusammenfassung
Angesichts der aktuellen Beschleunigung im Bereich der Agentic AI scheint es nicht länger prophetisch zu sein, zu sagen, dass es in nicht allzu ferner Zukunft mehr KI-Agenten geben wird, die sich mit Produktionsanwendungen und -daten verbinden, als menschliche Benutzer.
Es wird tiefgreifende Auswirkungen auf den Arbeitsplatz haben – einige Schätzungen gehen davon aus, dass die Hälfte der Angestellten innerhalb von fünf Jahren nicht mehr beschäftigt sein wird. Es gibt auch tiefgreifende Auswirkungen auf die Cybersicherheit.
Agenten-KI birgt neuartige Risiken, wie z. B. Prompt-Injection-Angriffe, bei denen KI-Agenten effektiv durch "Social Engineering" dazu gebracht werden, im Namen eines Angreifers zu handeln, nachdem sie nicht vertrauenswürdigen Eingaben ausgesetzt wurden.
Als Identity-Unternehmen ist Okta in größerem und unmittelbarem Maße besorgt darüber, wie agentische KI die Angriffsfläche jeder Organisation aus Sicht der Authentifizierung und Autorisierung vergrößert. Wir können zuverlässig davon ausgehen, dass Angreifer die unzähligen Service-Account-Passwörter und statischen API-Schlüssel entdecken und missbrauchen werden, die Entwickler generieren, um KI-Agenten Zugriff auf Unternehmensressourcen zu gewähren. Wir können auch zuverlässig davon ausgehen, dass die breit gefasste Autorisierung, die KI-Agenten gewährt wird, den potenziellen Datenverlust durch die Kompromittierung eines bestimmten Accounts verschärfen wird.
Dieses Dokument dient als Leitfaden für Service Provider, Organisationen und Developer, die mit Agentic KI experimentieren, mit dem Ziel, Produktionsanwendungen zu erstellen.
Die Rolle, die KI bei Identitätsschulden spielt
Identitätsschulden entstehen, wenn gemeinsame, statische Geheimnisse im Laufe der Zeit in einem System angesammelt werden dürfen. Ein Geheimnis wird geteilt, wenn es von mehr als einem Benutzer oder an mehr als einem Ort bekannt ist oder gespeichert wird. Ein Geheimnis ist statisch, wenn es langlebig ist und über lange Zeiträume nicht rotiert wird.
Unsere Forschung hat ergeben, dass Agentic KI zu einer Beschleunigung dieses Aufbaus von Identity-Schuld beiträgt. Organisationen sollten sich auf Methoden für Großunternehmen geeignet verlassen, um einen Client (KI-Anwendung) zu autorisieren, im Namen eines Benutzers in einer geschützten Ressource (Apps und Daten) zu handeln.
Unsere Forschung hat das Gegenteil ergeben. Unsere Untersuchungen haben ergeben, dass die gängigsten Methoden zur Autorisierung des Zugriffs eines KI-Agenten auf Funktionen und Daten in SaaS-Apps, Programmcode-Repositories, Datenbanken und anderen Ressourcen zur Offenlegung hochprivilegierter Geheimnisse führen.
Die Tabelle auf der folgenden Seite bewertet die Sicherheitseigenschaften verschiedener Autorisierungsansätze.
Agentische Plugins: Die Vorläufer von MCP
Eine Studie über Copilot-Plugins
Unsere Forschung hat ergeben, dass die Mehrzahl der Machine-to-Machine-Authentifizierungsmethoden, die zur Verbindung von KI-Agenten mit geschützten Ressourcen (Unternehmensanwendungen und -daten) verwendet werden, Authentifizierungsformen verwenden, die für den Einsatz in Produktionsumgebungen nicht geeignet sind, mit wenig bis gar keiner Kontrolle über die Autorisierung.
Um dies zu veranschaulichen, haben wir die verfügbaren Authentifizierungsmethoden bewertet, die zur Verfügung gestellt werden, um Microsoft Copilot AI-Agenten den Zugriff auf einige der sensibelsten Daten im Unternehmen zu ermöglichen: Sicherheitsanwendungen.
Copilot gehört zu den weltweit führenden KI-Assistenten für allgemeine Zwecke. Microsoft bietet die Möglichkeit, „Plugins“ für Microsoft Copilot zu erstellen, um die Funktionen von Sicherheits-Apps von Drittanbietern für Microsoft-Anwendungen verfügbar zu machen (unter der Marke „Microsoft Security Copilot“). Jedes Microsoft Security Copilot-Plugin wird in einer YAML- oder JSON-Datei (einem Plugin-Manifest) konfiguriert, die beschreibt, welche Tools im externen Dienst für den Copilot-Agenten verfügbar sind.
Verwendung dieser Dienste:
- Microsoft Copilot fungiert als Hostanwendung
- Die Tools und Daten von Sicherheitsanwendungen wie Splunk, SentinelOne, Forescout oder Cyberark sind geschützte Ressourcen.
Ein gemeinsamer Kunde (beider Dienste) muss Copilot zunächst autorisieren, in seinem Namen auf geschützte Ressourcen zuzugreifen. Dafür muss der Kunde Copilot Anmeldedaten (Passwörter, API-Schlüssel oder die Client-ID und das Client Secret in einem OAuth-Ablauf) zur Verfügung stellen, die auf Microsoft-Servern im Ruhezustand gespeichert werden. Die verfügbaren Schemas sind in der folgenden Tabelle aufgeführt.
Security Copilot unterstützt verschiedene Schemata für die Authentifizierung von Plugins:
Abbildung 2: Authentifizierungsoptionen für Microsoft Security Copilot. Quelle: Microsoft
Wenn ein Benutzer Copilot auffordert, eine geschützte Ressource zu nutzen, analysiert die Copilot-KI die Anfrage und ermittelt, welches Plugin die relevante „Fähigkeit“ (wie im Plugin-Manifest definiert) anbietet, aus der sie schöpfen kann. Copilot verwendet dann die gespeicherten Anmeldedaten, um einen authentifizierten API-Aufruf an die Drittanbieter-Anwendung zu tätigen, die die Daten abruft oder eine Aktion ausführt und ein Ergebnis an Copilot zurückgibt. Wir wollten verstehen, welche Authentifizierungsmethoden verwendet wurden, um diese geschützten Ressourcen (Sicherheitsanwendungen) mit Microsoft Copilot zu verbinden. 5
Aus unserer Analyse der auf GitHub ver entlichten Plugin-Manifeste von Drittanbietern haben wir Folgendes festgestellt:
- 20 % unterstützen die Standardauthentifizierung
- 75 % Support für die ApiKey -Methode
- 5 % unterstützen einen OAuth2 -Ablauf
Die Risiken, die mit der Verwendung eines Copilot-KI-Plugin verbunden sind, hängen im Wesentlichen von (a) der Wahl der Authentifizierungsmethode und (b) dem Umfang der Zugangsrechte ab, der dem Agent gewährt wird.
Standardauthentifizierung
Bei Verwendung der Standardauthentifizierung müssen Administratoren ein Dienstkonto in der Drittanbieteranwendung erstellen und den Benutzernamen sowie das Passwort auf die Microsoft-Server hochladen. Copilot sendet dann den Benutzernamen und das Passwort im Header jeder Anfrage an die Sicherheits-App (immer dann, wenn Copilot dieses Tool basierend auf einer Benutzeraufforderung auswählt).
Abbildung 3 und 4: Screenshots aus der Hilfedokumentation des Microsoft Security Plugin
Definitionsgemäß können Benutzer- oder Dienst-Accounts, die so konfiguriert sind, dass ein KI-Agent über das http:basic-Schema (Standardauthentifizierung) auf Ressourcen zugreifen kann, keine Multifaktor-Authentifizierung unterstützen.
Kunden, die dieses Schema verwenden, müssen folglich Benutzer- oder Service-Accounts offenlegen, die oft für einen breiten Zugriff auf sensible Daten ausgelegt sind und somit Credential-Stuffing- und Passwort Spraying-Angriffen ausgesetzt sind.
APIKey
Drei von vier Microsoft Security Copilot-Plugins können mit der APIKey-Methode autorisiert werden.
Während der Konfiguration erstellen Administratoren ein langlebiges API-Token in der geschützten Ressource, das typischerweise im Kontext eines Benutzer- oder Dienst-Accounts erstellt und manuell auf Microsoft-Server hochgeladen wird. Copilot sendet das API-Token in der Überschrift jeder HTTP-Anfrage, die es an die geschützte Ressource richtet (d. h. immer dann, wenn Copilot dieses Sicherheitstool basierend auf einer Benutzerabfrage auswählt).
Statische API-Keys bieten mehrere Vorteile gegenüber der Standardauthentifizierung:
- API-Keys eignen sich besser für Machine-to-Machine-Abläufe. Jedes eindeutige API-Token kann oft so konfiguriert werden, dass es nach Inaktivität oder einer bestimmten Dauer abläuft. Der Widerruf des Schlüssels hat keine Auswirkungen auf das Benutzer- oder Dienst-Account, das ihn erstellt hat.
- Der Zugriff auf das Service-Account, das zum Erstellen des API-Tokens verwendet wird, kann jetzt mit Multifaktor-Authentifizierung geschützt werden.
- Administratoren beschränken eher den „Umfang“ dessen, wofür ein API-Token zum Lesen oder Ändern verwendet werden kann, im Vergleich zu den Berechtigungen eines Dienstkontos, das für die Standardauthentifizierung verwendet wird.
Das Restrisiko besteht darin, dass diese API-Token in der Regel eine lange Lebensdauer haben. API-Keys werden routinemäßig in Quellcodeverwaltungssysteme eingecheckt. API-Keys werden routinemäßig in Logs gespeichert, wenn sie als Abfrageparameter festgelegt werden. Gelegentlich werden API-Keys in Textdateien auf Developer-Rechnern gespeichert, bereit zur Sammlung durch den nächsten generischen Infostealer, der das Gerät infiziert.
Abbildung 5: Der Zugriff auf das in diesem Copilot-Plugin referenzierte Token ermöglicht den Zugriff auf Daten über alle Geräte in einer Organisation.
Statische API-Token sind für Angreifer von hohem Wert und das Erste, wonach viele Angreifer nach der Kompromittierung eines Systems suchen. Einmal abgefangen, sind diese Token in der Regel lange gültig, was sie zu idealen Kandidaten für den Weiterverkauf auf Online-Märkten macht.
Statische API-Token stellen auch Verfügbarkeitsrisiken dar, zumindest im Vergleich zu temporären Token, die in OAuth-Abläufen erstellt werden, da statische Token eher im Kontext eines Benutzers als einer Anwendung erstellt werden.
In vielen Fällen wird das Token gelöscht, wenn das Benutzer- oder Dienst-Account, das das Token erstellt hat, gelöscht oder deprovisioniert wird. Dadurch werden alle M2M-Integrationen unterbrochen, die damit verbunden sind.
OAuth2
Der kleine Rest der Microsoft Security Copilot-Plugins scheint OAuth2-Flows für Großunternehmen geeignet zu verwenden.
Bei diesen Schemata werden eine Client-ID und ein Client Secret (die mit Microsoft geteilt werden) mit einem Autorisierungsserver ausgetauscht, um ein kurzlebiges Access Token zu erhalten, das unabhängig vom Ressourcenserver validiert wird.
Wenn diese Abläufe in Okta erstellt wurden, können die resultierenden Access Tokens IP-beschränkt (nur gültig von einem konfigurierten IP-Bereich) und clientbeschränkt (nur gültig von dem Client, der sie angefordert hat) sein. Scopes werden auf der Ebene der Dienstanwendung festgelegt, nicht auf der Ebene des Benutzers, was bedeutet, dass Administratoren nicht versehentlich Machine-to-Machine-Integrationen deaktivieren, wenn ein Administratorkonto oder ein Dienstkonto außer Betrieb genommen wird.
Obwohl es enttäuschend ist festzustellen, dass so wenige Copilot-Agenten für die Authentifizierung für Großunternehmen geeignet ausgelegt sind, spiegeln diese Entscheidungen in vielerlei Hinsicht die bestehenden Authentifizierungsmethoden wider, die von den Sicherheits-Apps bereitgestellt werden. Im Kontext der Integration mit einem einzelnen proprietären KI-Tool waren diese Sicherheitsanbieter offensichtlich nicht bereit, in die Aktualisierung ihrer verfügbaren Authentifizierungsmethoden zu investieren.
Was aber, wenn Developer, anstatt Plugin-Manifeste für jede KI-Anwendung zu schreiben, einen einzigen Server nach einem Industriestandard erstellen könnten, der von allen Varianten von KI-Anwendungen unterstützt wird?
Implementieren Sie das Model Context Protocol.
Modellierung von Bedrohungen für das Model Context Protocol
Wenn Sie ein Developer von Unternehmens-Apps sind, ist die Wirtschaftlichkeit, für jede andere Variante eines KI-Modells einen neuen benutzerdefinierten Connector (z. B. ein Microsoft Copilot-Plugin) schreiben zu müssen, alles andere als wünschenswert.
Service Provider würden es vorziehen, von vornherein zu deklarieren, welche Daten und Tools das Unternehmen bereit ist, mit einem beliebigen KI-Modell zu teilen, die Bedingungen zu definieren, unter denen diese Ressourcen verfügbar gemacht werden, festzulegen, wie Kunden den Zugriff autorisieren sollen, und die KI-Anwendungen auf die Allowlist zu setzen, die auf diese Ressourcen zugreifen können.
Aus diesem Grund gewinnt die Dynamik in Bezug auf agentische KI nun um das Model Context Protocol (MCP) an Fahrt. MCP ist eine standardisierte Schnittstelle für die Verbindung von KI-Anwendungen (Hosts) mit Unternehmensdiensten, die so unterschiedlich sind wie Cloud-Plattformen, SaaS-Anwendungen, Programmcode-Repositories, Datenbanken und sogar Zahlungsdienste. Die Client-Server-Architektur von MCP ermöglicht das „Plug-and-Play“ von KI-Anwendungen mit den Datenquellen und Tools, die ihnen Kontext verleihen.
Im Unternehmen verspricht MCP folgende Möglichkeiten:
- Ermitteln Sie, welche unternehmenseigenen Datenquellen und Tools verfügbar sind.
- Ermöglichen Sie es agentischen KI-Anwendungen, auf Datenquellen und Tools aus mehreren Anwendungen zuzugreifen, ohne Datenübertragungskontamination.
- Senkung der Kosten für das Experimentieren mit verschiedenen KI-Anwendungen, die auf diese Datenquellen und Tools zugreifen.
Abbildung 6: Eine visuelle Beschreibung des Model Context Protocol. Quelle: modelcontextprotocol.io
MCP-Server können lokal oder remote bereitgestellt werden. Diese Wahl des Bereitstellungsmodells für einen bestimmten Anwendungsfall hat einen erheblichen Einfluss auf das resultierende Bedrohungsmodell.
Der Umfang unserer Forschung beschränkte sich auf das Verständnis, wie Al-Anwendungen (Hosts), MCP-Clients und MCP-Server mit Anmeldedaten umgehen. Die Kernkomponenten, die wir bewertet haben, waren:
- MCP-Hosts: Alle Anwendungen, einschließlich integrierter Entwicklungsumgebungen (IDEs) wie Cursor, VS Code oder Claude, die Zugriff auf die von MCP-Servern bereitgestellten Tools benötigen.
- MCP-Clients: Die mehreren Clients, die ein MCP-Host zur Kommunikation mit einem gekoppelten MCP-Server verwendet.
- MCP-Server: MCP-Server werben für die in einem externen Dienst verfügbaren Tools und Ressourcen und tätigen API-Aufrufe an diese Dienste.
Lokale MCP-Server
Das MCP-Modell ist besonders attraktiv für Softwareentwicklungs-Anwendungsfälle.
Softwareentwickler, die KI-fähige IDEs wie Cursor und VS Code verwenden, können Code lokal erstellen und dabei die Unterstützung von Remote-KI-Modellen nutzen, um Vorschläge zu machen, während der Developer Code schreibt.
Anthropic stellt seinen Claude-AI-Agenten zur lokalen Bereitstellung als „Claude Desktop“ zur Verfügung. Claude Desktop ist ein lokal bereitgestellter macOS- und Windows-Client und eine Alternative zum Zugriff auf die AI-Modelle von Anthropic über den Browser. Ein Vorteil lokaler MCP-Server besteht darin, dass Clients sowohl mit einem Remote-KI-Modell als auch mit lokalen Dateien (Dokumente, Bilder usw.) interagieren können.
Diese Desktop-Anwendungen müssen sich oft sowohl beim LLM (dies erfordert typischerweise einen API-Key) als auch bei Remote-Datenquellen (wie z. B. Programmcode-Repositories, die ein persönliches Zugriffstoken benötigen) authentifizieren.
Wenn ein Benutzer die Hostanwendung startet, z. B. Claude oder Cursor, erzeugt der MCP-Client einen MCP-Server und übergibt dem Server alle Anmeldedaten (API-Keys, Datenbank-Anmeldedaten, Passwörter, OAuth-Clientgeheimnisse usw.), die für den Betrieb erforderlich sind, aus einer lokalen Konfigurationsdatei, einschließlich der Anmeldedaten, die der MCP-Server für den Zugriff auf Remotedienste benötigt.
Wenn der MCP-Server beispielsweise für den Zugriff auf Github-Ressourcen ausgelegt ist, benötigt der Host ein Github Personal Access Token (PAT), das in der lokalen Konfigurationsdatei verfügbar ist. Der Server gibt eine Fehlermeldung aus, wenn das Github PAT nicht bereitgestellt wird.
Abbildung 7: Ein MCP-Server, der für den Zugriff auf GitHub-Ressourcen verwendet wird, gibt eine Fehlermeldung aus, wenn in der Konfigurationsdatei kein PAT angegeben ist.
Die Speicherorte von Konfigurationsdateien für drei der beliebtesten Entwicklungsanwendungen, die KI verwenden, werden unten angegeben:
| App | Lokale Konfigurationsdatei | Standardorte |
|---|---|---|
| Claude Desktop | claude_desktop_config.json | Standardspeicherort auf MacOS: ~/Library/Anwendung Support/Claude/ Standardspeicherort auf Windows: ~/AppData/Roaming/Claude |
| Cursor | mcp.json | Standardort bei globaler Verwendung (alle Betriebssysteme): ~/.cursor/mcp.json. Wenn ein MCP-Server nur für ein bestimmtes Projekt verfügbar ist, wird die Konfigurationsdatei im Projekt-Directory abgelegt. |
| VS Code | settings.json | Standardspeicherort unter MacOS: ~/Library/Anwendung Support/Code/Benutzer/ Standardspeicherort unter Windows: ~/AppData/Roaming/Code/Benutzer |
Untersuchungen von Keith Hoodlet bei Trail of Bits wiesen auf die Risiken der Speicherung statischer API-Keys im Klartext in diesen Dateien hin und nannten Beispiele, in denen diese Dateien für die ganze Welt lesbar waren (d. h. für jeden Benutzer des Systems zugänglich).
In Fortführung dieser Untersuchung haben wir die Standardkonfigurationsdateien für Claude Desktop, Cursor und VS Code bewertet und die gleichen Berechtigungen festgestellt.
Abbildung 8: Standardberechtigungen für Claude-, Cursor- und VS Code-Konfigurationsdateien.
Dieselben Berechtigungen scheinen für Konfigurationsdateien zu gelten, die in zahlreichen offiziellen MCP-Server -Implementierungen enthalten sind, die als "produktionsreif" beschrieben werden, und für fast alle Community-Integrationen, die von Drittanbietern entwickelt wurden und nicht von den betreffenden Service Providern unterstützt werden.
Abbildung 9 und 10: Eine inoffizielle „Community-Integration“ fordert Okta-Kunden auf, ein SSWS-Token in eine lokale Konfigurationsdatei hochzuladen.
Jede Bedrohungsmodellierung sollte berücksichtigen, dass die überwiegende Mehrheit der bisher freigegebenen MCP-Server nicht unterstützt wird, was zu erhöhten Risiken bei der Verwendung von nicht autorisierten MCP-Servern durch Developer führt.
Eine vorläufige VirusTotal-Analyse von auf GitHub hochgeladenen MCP-Servern [2] ergab, dass 8 % von ihnen verdächtig waren. Eine nicht genannte Anzahl davon enthielt Code, der versucht, Geheimnisse (Schlüssel, Passwörter usw.) in Eingabeaufforderungen zu identifizieren und an externe Endpunkte zu senden.
Die unsichere Speicherung von API-Keys birgt eine Reihe von Risiken, die im Folgenden näher erläutert werden.
Risiken im Zusammenhang mit der unsicheren Speicherung von API-SchlüsselnAuf Software-Repositories hochgeladene Schlüssel
In Software-Repositories hochgeladene Schlüssel
Die meisten Dokumentationen für lokale MCP-Server-Implementierungen warnen Entwickler oder andere Benutzer nicht vor den Risiken der Speicherung von Klartext-Anmeldeinformationen für Produktionsressourcen in Konfigurationsdateien. Es wird davon ausgegangen, dass Entwickler die Anmeldedaten sicher verwahren, sodass die Konfigurationsdatei nur auf eine Anmeldedaten verweist, die an einem sicheren Ort gespeichert ist.
Wir haben einige Szenarien beobachtet, in denen die MCP-Konfiguration die Anmeldedaten zur Laufzeit nicht abrufen konnte, es sei denn, sie wurden im Klartext in der Konfigurationsdatei gespeichert.
- Laut einer Untersuchung von Gaetan Ferry von GitGuardian von Repositories, die aus der inoffiziellen Smithery.KI -MCP-Server-Registry geklont wurden, enthielten 202 Beispiele mindestens ein Geheimnis (5,2 % aller gescannten Repositories). Statische API-Token (siehe „x-api-key“) waren besonders auffällig[3].
Quelle: „A look into the secrets of MCP“, GitGuardian, April 2025
Schlüssel werden in Container-Metadaten offengelegt
Das Ausführen von MCP-Servern in Containern verschiebt das Problem eher, als es zu entschärfen. Das Geheimnis muss im Container in einem Format übergeben werden, das der MCP-Server unterstützt.
Die Überprüfung der Containerkonfiguration bietet einen direkten Verweis auf ein Klartextgeheimnis – sei es in Form einer Datei auf dem Host oder durch die Möglichkeit, die relevanten Umgebungsvariablen in einem Container zu identifizieren, die durch Ausführen von `docker inspect` offengelegt werden können, einem Befehlszeilentool, das die Inspektion von Docker-Ressourcen ermöglicht.
Abbildung 11: Ein in Container-Metadaten offengelegter GitHub-Personal-Access-Token.
Von Malware abgerufene Keys
Commodity-Infostealer-Malware wurde entwickelt, um bestimmte Pfade und Dateitypen zu finden, in denen Anmeldedaten gespeichert sind.
Beispiele:
- Windows-Infostealer, wie z. B. Vidar Stealer, suchen nach Geheimnissen, die unter ~\AppData\Roaminggespeichert sind.
- MacOS-Infostealer wie Atomic Stealer suchen nach Geheimnissen, die unter ~/Library/Application Supportgespeichert sind.
Es ist sehr wahrscheinlich, dass die unsichere Speicherung statischer API-Token an diesen Orten zu schwerwiegenden Events führen wird. Während ein an diesem Ort gespeichertes Sitzungs-Token ein kurzes Zeitfenster bietet, in dem ein Angreifer Zugriff auf eine Ressource auf Benutzerebene erlangen kann, bietet ein statisches API-Token dauerhaften Zugriff auf organisationsweite Ressourcen.
Auf externen Systemen gesicherte Schlüssel
Schlüssel werden in Backup-Volumes offengelegt, wenn Administratoren es versäumen, sensible Ordner auszuschließen (z. B. ~\AppData\Roaming unter Windows oder ~/Library/Anwendung Support unter MacOS).
Rechner, die von mehreren Benutzern gemeinsam genutzt werden
Da Konfigurationsdateien als öffentlich lesbar eingestuft wurden, sind Schlüssel, die von einem Benutzer auf einem gemeinsam genutzten Gerät gespeichert werden, auch für andere Benutzer zugänglich, die sich auf demselben Gerät anmelden.
Sichere Alternativen für die lokale Speicherung von Anmeldedaten
Der Abschnitt mit den Empfehlungen in diesem Dokument beschreibt taktische Lösungen, die diese Risiken bei der Speicherung von Anmeldedaten minimieren.
Alternativ können Organisationen, die mit MCP experimentieren, einen Ansatz verfolgen, der auf „Secure by Design“ basiert, und Lösungen verwenden, die unter Berücksichtigung dieser Bedrohungen entwickelt wurden.
Nehmen Sie zum Beispiel den Auth0 MCP Server [4]. Der Autho MCP Server bietet Administratoren die Möglichkeit, den Zugriff auf Autho-Ressourcen von lokalen Claude Desktop-, Cursor- oder Windsurf-Anwendungen mithilfe des OAuth 2.0 Gerätecode-Autorisierungsablaufs zu autorisieren.
Abbildung 12: Authentifizierungsablauf mit Autho MCP Server
Standardmäßig werden Anmeldedaten nach der Authentifizierung im MacOS-Schlüsselbund gespeichert und aus dem Schlüsselbund entfernt, wenn sich der Administrator vom MCP-Server abmeldet.
Darüber hinaus sind standardmäßig keine Scopes ausgewählt: Ein administrativer Benutzer wird aufgefordert, diese auszuwählen.
Remote MCP-Server
Ein Remote-MCP-Server arbeitet als webbasierten Dienst. Wenn die MCP-Spezifikation getreu implementiert wird, baut ein MCP-Client eine langlebige HTTP-Verbindung mit dem Server auf, wobei die Session-Verwaltung durch Token-basierte Authentifizierung erfolgt.
Die Version vom 26. März 2025 der Model Context Protocol-Spezifikation legte fest, dass OAuth 2.1 die geeignete Methode ist, wenn eine Autorisierung erforderlich ist:
MCP-Auth-Implementierungen MÜSSEN OAuth 2.1 mit geeigneten Sicherheitsmaßnahmen für sowohl vertrauliche als auch öffentliche Clients implementieren.
Atlassian war einer der ersten Enterprise-Softwareanbieter, der einen remote MCP Server für Kunden anbot. Dies bietet eine einfache, OAuth-fähige Alternative zu einem Community-Server, der ihm mehrere Monate vorausging.
Ein Vergleich zwischen dem offiziellen Remote-MCP-Server und dem lokalen, von der "Community" entwickelten lokalen Server ist aufschlussreich.
Wenn der Community-Server Authentifizierungsmethoden entdeckt, die in einer lokalen .env-Datei (Konfigurationsdatei) verfügbar sind, haben alle für die Standardauthentifizierung konfigurierten Passwörter Vorrang vor allen konfigurierten Personal Access Tokens, die wiederum Vorrang vor OAuth-Anmeldedaten haben.
Abbildung 13: Anweisungen für den Atlassian Community Server
Die Autoren dieses Plugin geben offen an, dass sie die Benutzerfreundlichkeit für Developer über die Sicherheit gestellt haben.
Abbildung 14: Anweisungen für Atlassian Community Server
Im Gegensatz dazu beinhaltet der offizielle Remote-MCP-Server von Atlassian localhost-Support, um OAuth-basiertes Login und Zustimmung für alle Benutzer zu ermöglichen, einschließlich derjenigen, die sich von lokalen IDEs wie Cursor aus verbinden.
Dadurch entfällt die Notwendigkeit für Entwickler, Geheimnisse in lokale Konfigurationsdateien zu kopieren und einzufügen. Die Konfigurationsdatei verweist einfach auf den Remote-Dienst, und der Benutzer wird nach erfolgreicher Authentifizierung aufgefordert, eine OAuth-Einwilligung zu erteilen.
Und im Gegensatz zu Microsoft Copilot, das eher auf die Wahl der Authentifizierungsmethoden als auf ein bestimmtes Sicherheitsergebnis optimiert ist, ist OAuth die einzige verfügbare Authentifizierungsmethode im Remote-MCP-Server von Atlassian. Atlassian führt auch eine Allowlist darüber, welche Hosts (KI-Anwendungen) sich mit diesem Remote-MCP-Server verbinden dürfen.
Abbildung 15: Quelle: Atlassian
Agentische KI absichern
Die einzige Frage ist, welcher OAuth-Ablauf verwendet werden soll!
Während Remote-MCP-Server, die auf OAuth basieren, einen sichereren und standardisierteren Ansatz als proprietäre Plugins bieten, ist der Weg noch lange nicht geebnet. 20 Einige der verbleibenden Sicherheitsherausforderungen sind:
- Wie können wir KI-Agenten autorisieren, auf geschützte Ressourcen zuzugreifen, während wir den interaktiven (menschlichen) Benutzer immer einbeziehen?
- Wie können wir den Verwaltungsaufwand für das Schreiben von Autorisierungsregeln für jede einzelne Ressource auf Service Provider Ebene reduzieren?
- Wie können wir eine zentrale Richtlinie und ein Audit von Autorisierungsrechten bereitstellen?
In den von uns bewerteten Remote-MCP-Servern wurden KI-Agenten mit dem gleichen Zugriffsniveau auf Dienste autorisiert wie der Benutzer, der sie autorisiert hat. Sie handeln „im Namen“ eines Benutzers im vollen Umfang dessen, wozu der Benutzer berechtigt ist.
Dies erfüllt möglicherweise nicht die Anforderungen von CISOs, die sich über die Risiken der Anbindung von KI-Agenten an Daten sorgen, die sie zum Schutz verpflichtet sind. Unternehmensadministratoren werden sich nicht damit zufrieden geben, dass Service Provider die letzte Autorität darüber sind, welche Tools der MCP-Server bereitstellt.
Ein zentraler Administrator kann im Atlassian-Beispiel keine Richtlinien schreiben, die es Benutzern ermöglichen, Al-Agenten zum Lesen und Schreiben von Confluence-Wiki-Seiten zu autorisieren, aber die Möglichkeit zum Ändern von Jira-Tickets verweigern. Administratoren können keine bestimmten Projekte auswählen, auf die Al-Agenten nicht zugreifen sollen. Wenn der Benutzer darauf zugreifen kann, kann dies auch der Agent.
Der IETF-Entwurf OAuth Identity Assertion Grant, der von aktuellen und ehemaligen Okta-Architekten verfasst wurde, soll dieses Problem lösen. Diese Genehmigung kombiniert zwei bestehende Standards - den OAuth 2.0 Token Exchange und das JWT Profile for OAuth 2.0 Authorization Grants in eine Genehmigung, die Enterprise-Kontrolle und Transparenz bietet.
Mit diesem Ansatz können Administratoren zentralisierte Richtlinien konfigurieren, die sicherstellen, dass ein SSO-geschützter Benutzer einen KI-Agenten autorisieren kann, auf Daten in mehreren Anwendungen zuzugreifen, in denen bereits eine Vertrauensbeziehung besteht.
Der CISO wäre wiederum in der Lage, den Umfang dessen zu begrenzen, worauf Clients (in diesem Fall KI-Agenten) in einer geschützten Ressource zugreifen können. Okta arbeitet mit unabhängigen Softwareanbietern (Independent Software Vendors, ISVs) zusammen, um diese Funktionen im Rahmen des neu angekündigten Cross App Access für Kunden bereitzustellen.
Schlussbemerkungen
Als Branche müssen wir nun einige wichtige Entscheidungen treffen, um die Vorteile der Verbindung geschützter Ressourcen mit Agentic Al sicher nutzen zu können.
Wir müssen der Versuchung widerstehen, Authentifizierungsmethoden wiederzuverwenden, die bereits ungeeignet waren, um Systeme über das öffentliche Internet zu verbinden, geschweige denn Systeme, die autonom agieren können. Da KI-Agenten immer umfassendere Berechtigungen anfordern und erhalten, wird der "Blast Radius" einer einzelnen Kompromittierung erheblich verstärkt. Eine einzige Sicherheitsverletzung könnte deutlich mehr Daten und kritische Systeme offenlegen als zuvor.
Wir müssen stattdessen Abläufe einführen, die für das KI-Zeitalter entwickelt wurden – eng gefasste, benutzerdelegierte Zugriffsabläufe, die kurzlebige, überprüfbare Token verwenden und dem CISO eine längst überfällige Kontrolle und Sichtbarkeit bieten.
Anhang: Schutzmaßnahmen
Empfehlungen für Service Providers
- Nutzen Sie OAuth 2.1 als minimal tragfähiges Autorisierungsmodell für Model Context Protocol (MCP)-Server.
- Abonnieren Sie Updates zu MCP, um über neue Entwicklungen auf dem Laufenden zu bleiben.
Empfehlungen für Entwickler
- Beschränken Sie die Verwendung von statischen API-Token nur auf Entwicklungs- und Testumgebungen (keine Produktionsdaten) und wenden Sie die minimal erforderlichen Scopes an.
- Verwenden Sie bei der lokalen Entwicklung OS-basierte Secret Vaults (MacOS-Keychain, Windows Credential Manager), um Secrets dynamisch zur Laufzeit abzurufen.
- Ändern Sie die Berechtigungen der Datei .env. und anderen Konfigurationsdateien sowie den lokalen Log-Dateien von Al-Anwendungen, sodass nur Ihr User Account diese lesen oder verändern kann.
- Listen Sie alle Konfigurations- und Logdateien in .gitignore auf, um zu verhindern, dass sie versehentlich in Versionskontrollsysteme übernommen werden.
Empfehlungen für Security-Teams
- Beschränken Sie Entwicklungsaktivitäten auf von Unternehmen ausgegebene, gehärtete Rechner.
- Phishing-resistente Authentifizierung ist erforderlich, um auf Unternehmensressourcen zuzugreifen.
- Verwenden Sie dedizierte Secrets-Management-Lösungen für Produktionsanmeldedaten.
- Verwalten und steuern Sie die Mitgliedschaft von Gruppen mit Zugriff auf Containerressourcen und stellen Sie sicher, dass der Docker-Daemon (Prozess) so konfiguriert ist, dass eine Gefährdung vermieden wird.
- Erfordern Sie OAuth 2.1 Abläufe, um den Client-Zugriff auf Unternehmensressourcen zu autorisieren.
- Für Anwendungsfälle, in denen die Risiken der Verwendung statischer API-Token akzeptiert werden:
- Schulen Sie Entwickler über die Risiken der Verwendung von Token mit langer Lebensdauer.
- Anforderungen mit dem Token auf den bekannten IP-Bereich des entsprechenden MCP-Servers zulassen.
- Verweigern Sie den interaktiven Zugriff auf Anwendungen mit dem Service-Account, das mit dem API-Token verknüpft ist, oder fordern Sie zumindest Authentifizierungsherausforderungen mit Höchstmaß an Sicherheit für den Zugriff darauf an.
- Suchen Sie proaktiv nach Token, die im Klartext auf Servern, in Dateien, in Programmcode-Repositories, in Logs sowie in Messaging- und Collaboration-Apps gespeichert sind.
- Überwachen Sie den Missbrauch von Tokens.
