KI-Identitäten : KI²DM bringt Kontrolle : Identität als Steuerungsebene für KI-Agenten

Diese Lücke mag nun kleiner geworden sein, aber sie klafft noch immer. Was den meisten fehlt: Ein modernes Identitätsmanagement (IDM) für KI-Agenten sowie überhaupt die Einsicht, dass KI-Agenten eine digitale Identität benötigen, die ebenso zu behandeln ist, wie die von Menschen und Maschinen. Das bedeutet: Zugriffsrechte (und ihre umgehende Entziehung bei Gefahr), Eigentümer, Sicherheitsstandards, Compliance-Vorschriften, Audit-Dokumentation.

MCP macht diese Anforderung sichtbarer: In einer auf MCP basierenden Umgebung kann ein KI-Agent über MCP-Server verfügbare Tools ermitteln, APIs ansprechen, Dateien abrufen, Datenbanken abfragen oder Workflows auslösen. Die offizielle MCP-Dokumentation beschreibt Tools als Fähigkeiten, die von Sprachmodellen (LLMs) ermittelt und aufgerufen werden können, um mit externen Systemen, wie Datenbanken, APIs und Rechendiensten, zu interagieren. Zudem empfiehlt sie eine menschliche Aufsicht sowie eine klare Transparenz bezüglich der Frage, welche Tools bereitgestellt und wann diese genutzt werden.

Daher gilt es, die Grundlagen des Identitätsmanagements zu meistern, um eine Identitätssicherheit zu schaffen, die als Fundament für den sicheren Betrieb von KI-Agenten fungiert – vom Onboarding der KI-Agenten bis zu ihrem Einsatzende, über den gesamten Lebenszyklus hinweg.

Gefahren der Schatten-KI

Mit übermäßig vielen Zugriffsrechten ausgestattete KI-Agenten sind bereits Teil der Netzwerke sehr vieler Unternehmen – und fliegen oft unter dem Radar der IT-Sicherheitsverantwortlichen. Eine Schatten-KI hat sich ausgebildet und stellt eine große Angriffsfläche dar.

Es gilt daher, wie vor vielen Jahren bei der Schatten-IT, unautorisierte KI-Agenten in den virtuellen Umgebungen aufzuspüren, zu registrieren und in die Governance einzubeziehen, damit sie verwaltet, überwacht und sicher betrieben werden können. Sicherheitsverantwortliche müssen wissen, wer einem KI-Agenten wann welche Zugriffsrechte zu welchem Zweck gegeben hat. Außerdem muss ein Kill-Switch es jederzeit ermöglichen, bei einer Anomalie diesen Zugriff sofort wieder zu entziehen.

Konkret geht es um drei Fragen:

• Wo sind KI-Agenten eingerichtet?
• Womit können sie sich verbinden?
• Was dürfen sie tun?

MCP fügt eine vierte pragmatische Frage hinzu: Welche Tools, Ressourcen und Workflows werden den KI-Agenten zugänglich gemacht?

Dies ist von Bedeutung, da MCP einen KI-Agenten nicht bloß mit Informationen verknüpft, sondern auch mit Handlungsoptionen. Ein MCP-Server kann Tools bereitstellen, die Produktionssysteme abfragen, Dateien modifizieren, Tickets erstellen, Nachrichten versenden, auf Kalender zugreifen oder mit Entwicklerplattformen interagieren. Werden diese Tool-Schnittstellen nicht registriert, gesteuert und überwacht, hat die Organisation eine neue Ausführungsebene geschaffen, die außerhalb der Sichtbarkeit traditioneller Identity-and-Access-Management- (IAM)-, Endpoint- und Netzwerk-Kontrollen liegt.

Viele IT-Sicherheitsentscheider scheitern an diesen Fragen – aufgrund eines strukturellen Problems: KI-Agenten sind bereits im Einsatz, aber die derzeitige Identitätsverwaltung ist veraltet.

Während also noch über formelle Roll-outs diskutiert wird, verknüpfen Mitarbeiter häufig schon KI-Tools von Drittanbietern über OAuth-Berechtigungen mit ihren Unternehmenskonten – etwa Cursor mit GitHub, Claude mit Google Workspace oder KI-gestützte Meeting-Protokollanten mit ihren Kalendern. Dies geschieht in einer Geschwindigkeit, mit der die Governance nicht Schritt halten kann.

Jede dieser Berechtigungsvergaben erzeugt aber eine nicht-menschliche Identität mit delegierten Zugriffsrechten auf Unternehmensdaten – oft ohne einen verifizierten Eigentümer oder einen klar definierten „Schadensradius“.

Applikationsübergreifende Aktivität

Das Problem wird noch komplexer, wenn KIAgenten im Rahmen eines einzigen Workflows über mehrere Anwendungen hinweg agieren. Eine einzelne Benutzeranfrage könnte von einem KI-Agenten verlangen, ein Dokument zu lesen, einen Kalender zu prüfen, ein Support-Ticket zu erstellen, einen CRM-Datensatz zu aktualisieren, eine Bereitstellung auszulösen und einen Audit-Eintrag zu verfassen.

Cross-App-Access (XAA) begegnet diesem aufkommenden Muster, indem es einem Identity-Provider ermöglicht, kurzlebige, signierte Delegationsnachweise auszustellen. Diese übertragen die Identität eines Benutzers über Dienstegrenzen hinweg, anstatt auf wiederholte Zustimmungsdialoge, fehleranfällige Tokenübergaben oder gemeinsam genutzte Dienstkonten angewiesen zu sein.

Für CISOs liegt die Bedeutung von XAA im Bereich der Governance: Das Verfahren schafft die Möglichkeit, den Identitätskontext zu wahren, während ein KI-Agent von einer Anwendung zur nächsten wechselt. Ohne diese Funktion kann jeder einzelne Schritt innerhalb eines KI-Agenten-Workflows intransparent werden: Das erste System kennt möglicherweise noch den menschlichen Benutzer, das zweite erkennt eventuell ein Dienstkonto, das dritte empfängt womöglich ein langlebiges Token und das vierte protokolliert eine Aktion, ohne jedoch zu wissen, welcher Benutzer oder KI-Agent diese initiiert hat. Das untergräbt die Auditierbarkeit, das Prinzip der geringsten Privilegien (Least Privilege) sowie die Fähigkeit zur Reaktion auf Sicherheitsvorfälle.

Ein kürzlicher Vorfall auf einer namhaften Entwicklerplattform beruhte beispielsweise weder auf einer Sicherheitslücke noch auf einem Infrastrukturfehler, sondern lediglich auf einer OAuth-Verbindung zwischen dem Firmenkonto eines Mitarbeiters und einem externen KI-Tool – eine Verbindung, die gänzlich außerhalb des Sichtfelds der IT eingerichtet wurde. Als dieses KI-Tool kompromittiert wurde, avancierte das bereits gewährte Vertrauen zum Angriffsweg: einem direkten Zugang zu internen Systemen, API-Schlüsseln, Tokens und Umgebungsvariablen. Das ist Schatten-KI in der Praxis: eine unautorisierte OAuth-Freigabe, die jeglicher IT-Aufsicht entbehrt.

Die unbequeme Wahrheit lautet deshalb: Wenn CISOs mit der Absicherung der KI-Agenten warten, bis die allgemeinen KI-Richtlinien der Firma endgültig verabschiedet worden sind, versuchen sie lediglich, diese KIGovernance auf ein Risiko anzuwenden, das sich bereits stark verschärft hat.

IAM im Fokus

Traditionelle Sicherheitsmodelle priorisieren häufig den Netzwerk- oder Endgeräteschutz. Obwohl es sich hierbei um entscheidende Schutzebenen handelt, sind sie im Grunde blind dafür, welche autonomen KI-Agenten worauf und aus welchem Grund zugreifen:

• Netzwerk-Tools erfassen den Datenverkehr, aber ein im Auftrag eines Benutzers handelnder KI-Agent erscheint dabei als legitimer API-Traffic.
• Endgeräte-Tools überwachen Prozesse, aber ein KI-Agent wirkt hier wie ein standardmäßiger, autorisierter Prozess, der im Rahmen einer legitimen Benutzersitzung ausgeführt wird.

Beide Ebenen sind unverzichtbar, doch keine von beiden kann die Fragen beantworten, die im Falle eines Sicherheitsvorfalls wirklich zählen: Welcher KI-Agent hat hier etwas getan, in wessen Auftrag, in welchem Umfang – und war dies überhaupt zulässig?

Im Zeitalter autonomer KI-Agenten ist deren Identität die einzige Sicherheitsebene, welche die zugrunde liegende Absicht sowie den genauen Handlungsspielraum versteht. Aus diesem Grund stuften bereits in der erwähnten Umfrage 85% der befragten Führungskräfte das Identitäts- und Zugriffsmanagement (IAM) als die wichtigste Komponente ihrer KI-Strategie ein.

Ein modernes IAM identifiziert und integriert daher KI-Agenten plattformübergreifend und plattformunabhängig, schützt die Verbindungen durch einen auf das absolut notwendige Minimum beschränkten Zugriff (Least-Privilege-Principle) und steuert die KI-Agenten mittels regelmäßiger Zugriffsprüfungen sowie lückenloser Audit-Trails. Zudem ermöglicht sie es den Fachleuten, im Notfall einen KI-Agenten – etwa bei unerwartetem Verhalten – per Kill-Switch sofort manuell zu deaktivieren, um die Anforderung neuer Token und künftige Autorisierungen umgehend zu unterbinden.

MCP und XAA sind als komplementäre Elemente dieses identitätszentrierten Modells zu verstehen: MCP standardisiert die Art und Weise, wie sich KI-Agenten mit Tools und Daten verbinden – XAA trägt dazu bei, die delegierte Identität sowie den Autorisierungskontext zu wahren, während sich KI-Agenten über verschiedene Anwendungen hinweg bewegen. Gemeinsam steigern sie die Interoperabilität von auf KI-Agenten basierenden Systemen, machen es jedoch zugleich unerlässlich, dass Identität, Zugriff, Delegation, Protokollierung und Widerruf von Anfang an fest in die Architektur integriert werden.

Handlungsempfehlungen

Wenn Identität als Steuerungsebene für KI-Agenten fungiert, sollten CISOs vier Empfehlungen folgen:

• Agenten-Identität: KI-Agenten – ob intern entwickelt, in ein SaaS-Tool eingebettet oder auf dem Laptop eines Mitarbeiters ausgeführt – werden als Workload-Principals registriert, ausgestattet mit Zugangsdaten, einem zugewiesenen menschlichen Eigentümer und einem verwalteten Lebenszyklus.
• Kryptografische Zuordnung: Jede Aktion trägt sowohl die Identität des delegierenden Menschen als auch die des ausführenden KI-Agenten – jeweils kryptografisch signiert.
• Durchsetzung des Prinzips der geringsten Berechtigung (Least Privilege): Tokens sind auf einen einzelnen Aufruf beschränkt – nicht auf eine gesamte Sitzung oder Anwendung – dauerhafte Berechtigungen (Standing Privileges) entfallen.
• Integrierte Governance: Anfragen für KI-Agenten-Zugriffe sowie die Prüfung und Bestätigung von Zugriffsrechten sind fest in die Identitätsplattform integriert – nicht bloß nachträglich angeflanscht.

Diese Funktionen sind allerdings nur dann von Bedeutung, wenn sie überall dort greifen, wo KI-Agenten zum Einsatz kommen. Das bedeutet, dass die zugehörige Sicherheitsstrategie fest im gesamten IT-Ökosystem verankert sein muss, denn KI-Agenten laufen womöglich parallel auf verschiedenen Plattformen (z.B. Salesforce Agentforce, Amazon Bedrock und ServiceNow AI) sowie auf jeder weiteren Plattform, die unterschiedliche Teams künftig einführen. Jedes Mal, wenn ein KI-Agent die Grenzen eines IT-Ökosystems überschreitet, bliebe die Governance der Plattform, auf der er ursprünglich entwickelt wurde, zurück.

Genau aus diesem Grund sind MCP und XAA so wichtig: MCP stellt eine gemeinsame Integrationsschicht für KI-Agenten und Tools bereit – XAA liefert ein Modell, um Identität und delegierte Berechtigungen über Anwendungsgrenzen hinweg zu übertragen. Ohne Governance auf diesen beiden Ebenen wissen Organisationen zwar möglicherweise, wer sich angemeldet hat – jedoch nicht, womit sich ein KI-Agent verbunden, welches Tool er aufgerufen, welches nachgelagerte System die Delegation akzeptiert, oder wie weit sich die Aktion fortgepflanzt hat.

Identity-Provider erweitern, nicht ersetzen

Eine zentrale Sorge von IT-Architekten ist der Identity-Sprawl – die Befürchtung, für KI-Anwendungen ein zweites, isoliertes Identitäts-Silo schaffen zu müssen. Doch eine moderne KI-Governance sollte kein „Rip and Replace“ – also den vollständigen Austausch – der bestehenden Identitätsverwaltung für Mitarbeiter erfordern. Der Identity-Provider (IdP) fungiert schließlich als das maßgebliche System (System of Record) für die Belegschaft: Hier werden Anmelderichtlinien hinterlegt, die Multi-Faktor-Authentifizierung (MFA) durchgesetzt, der bedingte Zugriff konfiguriert. Jahrelange Integrationsarbeit sorgt für einen reibungslosen Ablauf der Identitätsverwaltung für menschliche Nutzer. Nichts davon sollte sich wegen der Integration von KI-Agenten ändern.

Umsetzbar ist das, wenn Identitätssicherheit meint: Das System ist föderal über Standardprotokolle (OIDC, SAML) ausgelegt und kommuniziert so mit dem bestehenden IdP. Dabei übernimmt es dessen Vertrauensbasis, ohne Anmeldedaten zu duplizieren oder eine separate Anmeldung zu verlangen. Wenn ein menschlicher Nutzer einen KI-Agenten aufruft, validiert es die vom IdP übermittelte Identitätsinformation und stellt ein kryptografisch signiertes Token aus, das sowohl die Identität des Nutzers als auch die des KI-Agenten enthält. Die menschlichen Nutzer verbleiben in ihrer gewohnten Umgebung, während die KI-Agenten eine speziell auf ihre Bedürfnisse zugeschnittene Governance erhalten.

XAA weitet diese Logik auf anwendungsübergreifende Ebenen aus: Anstatt jedes nachgelagerte System zu zwingen, sich auf eine separate Zustimmungsabfrage, ein gemeinsames Dienstkonto oder ein intransparentes Bearer-Token zu verlassen, kann der IdP kurzlebige Delegationsnachweise ausstellen. Diese geben Auskunft darüber, wer der veranlassende Benutzer ist, welcher KI-Agent im Auftrag handelt, welche Handlungen diesem gestattet sind und unter welchen Bedingungen dies erfolgt. Das verschafft nachgelagerten Anwendungen eine prüfbare Grundlage für Zugriffsentscheidungen und liefert Sicherheits-Teams einen kohärenten Audit-Trail über den gesamten Arbeitsablauf hinweg.

MCP sollte auf dieselbe identitätsbasierte Weise verwaltet werden: MCP-Server dürfen nicht lediglich als neutrale Infrastrukturkomponenten betrachtet werden. Sie müssen registriert, mit einer Verantwortlichkeit versehen, klassifiziert, überwacht und überprüft werden. Die von ihnen bereitgestellten Tools sollten an explizite Geltungsbereiche (Scopes), Risikostufen, Genehmigungsworkflows und Widerrufsmechanismen geknüpft sein. Ein riskantes MCP-Tool – das beispielsweise ProduktionsCode modifizieren, E‑Mails versenden, Ausgaben genehmigen oder auf Kundendatensätze zugreifen kann – darf niemals auf dieselbe Weise verwaltet werden wie ein reines Lese-Tool, das lediglich öffentliche Dokumentationen abruft.

Auf diese Weise wird das Identitätsfundament, in das eine Organisation bereits investiert hat, erweitert, um eine völlig neue Identitätsklasse abzudecken – ohne den Wechsel der Plattform, die Duplizierung von Verzeichnisdiensten oder zusätzlichen operativen Mehraufwand erforderlich zu machen.

Fazit

KI-Agenten werden bereits in großem Umfang in Unternehmen aller Art eingesetzt – Mitarbeiter und Führungskräfte warten nicht, bis irgendwann die allgemeine KI-Policy der Firma steht. Sie wollen „jetzt“ die Produktivität erhöhen und komplizierte Arbeitsschritte erleichtern.

CISOs müssen sich dieser Gegebenheit anpassen und damit beginnen, entstandene Schatten-KI aufzudecken, KI-Agenten mit digitalen Identitäten zu versehen und diese, wie alle Benutzer im Netzwerk, mit IAMGrundlagen auszustatten (etwa Zugriffsrechten und Eigentümern).

Sie müssen zudem die neuen Verbindungs- und Delegationsschichten steuern, die KI-Agenten so leistungsstark machen. MCP legt fest, was KI-Agenten sehen, womit sie sich verbinden und was sie aufrufen dürfen. XAA bestimmt, wie Identität und delegierte Befugnisse sicher über Anwendungsgrenzen hinweg übertragen werden können. Gemeinsam definieren sie die operative Oberfläche moderner KI-Agenten.

Dabei hilft es, wenn CISOs und ihre Teams auf bestehende Rahmenwerke und Blaupausen zurückgreifen, die schildern, weshalb die moderne Identitätssicherheit der Kern der KI-Agenten-Sicherheit ist. So können sie sich vom Druck der allgemeinen KI-Policy lösen und erkennen, dass IAM nicht nur die Grundlage der Identity-Security ist, sondern auch das Fundament des sicheren Betriebs von KI-Agenten bildet.

Stephen McDermid ist Regional CSO EMEA bei Okta.

Literatur

^{[1] Paula Hemker, Thomas Hemker, Nützlich, aber gefährlich, Betrachtungen zum Model-Context-Protocol für den Cybersecurity-Einsatz und als Sicherheitsproblem, 2025# 6, S.  14, www.kesinformationssicherheit.de/print/titelthema-security-schulungen-wie-nachhaltiges-training-gelingt/nuetzlich-aber-gefaehrlich/ (<kes>+)}

^{[2] Okta, AI at Work 2025: Securing the AI-powered workforce, Umfrageergebnisse, August 2025, https://www.okta.com/newsroom/articles/ai-at-work-2025–securing-the-ai-powered-workforce/}