KI-Agenten Identity Management 2026: Standards, Akteure und die Governance-Lücke
MCP OAuth 2.1, MCP-I beim DIF, Microsoft Entra Agent ID - die Standards-Landschaft für KI-Agenten-Identitäten nimmt 2026 Gestalt an. Was davon real ist, was fehlt und wie man Governance heute bewertet.
10 Min. Lesezeit · Zuletzt aktualisiert Juli 2026
Die Zahlen sind keine Theorie mehr. Mehr als 80 % der Fortune-500-Unternehmen betreiben bereits aktive KI-Agenten, die mit Low-Code- und No-Code-Tools entwickelt wurden[1], und Gartner prognostiziert, dass bis Ende 2026 bis zu 40 % der Unternehmensanwendungen integrierte, aufgabenspezifische KI-Agenten enthalten werden - gegenüber weniger als 5 % heute[2]. Doch die Sicherheitslage unter dieser Deploymentwelle ist alarmierend: Im Durchschnitt werden nur 47,1 % der KI-Agenten einer Organisation aktiv überwacht oder abgesichert[3]. Die andere Hälfte arbeitet ohne Aufsicht, Logging oder Identitätskontrollen.
Das ist kein Zukunftsproblem. Es ist der aktuelle Zustand Ihrer Produktionsumgebung.
Die gute Nachricht - wenn man sie so nennen kann - ist, dass die Standards-Community aufmerksam geworden ist. In der ersten Hälfte des Jahres 2026 wurden mehr Governance-Spezifikationen für KI-Agenten-Identitäten verabschiedet als in der gesamten Vorgeschichte dieses Feldes. Dieser Beitrag zeigt, was diese Standards tatsächlich aussagen, welche Anbieterkategorien reagieren, wo die echten Lücken bleiben und was ein Käufer heute fordern sollte.
Die Standards-Landschaft: Was tatsächlich ausgeliefert wird
MCP OAuth 2.1 unter Linux-Foundation-Governance
Das Model Context Protocol begann im November 2024 als Anthropic-Experiment. Im Dezember 2025 übergab Anthropic MCP an die Agentic AI Foundation (AAIF) unter der Linux Foundation; OpenAI, Block, AWS, Google, Microsoft, Cloudflare und Bloomberg traten als Gründungs- oder Platin-Mitglieder bei[4]. Innerhalb von vier Monaten wuchs die AAIF auf 170 Mitgliedsorganisationen - mehr als doppelt so viele, wie die CNCF zum gleichen Zeitpunkt ihrer Geschichte hatte[5].
Der Governance-Wechsel ist für Unternehmenskäufer bedeutsam. MCP ist kein Single-Vendor-Protokoll mehr, das ein einzelnes Unternehmen abkündigen oder forken kann. Es ähnelt in seiner Struktur heute eher der CNCF als einer proprietären API.
Zur Authentifizierung im Speziellen: Die MCP-Spezifikation schreibt OAuth 2.1 mit PKCE für alle geschützten HTTP-basierten Deployments vor und verlangt HTTPS auf allen Endpunkten sowie auffindbare Authorization-Server-Metadaten[6]. Die im März veröffentlichte Roadmap für 2026 nennt Enterprise-Readiness - einschließlich Audit-Trails, SSO-integrierter Authentifizierung und Konfigurations-Portabilität - als oberste Priorität. Die Authorization Working Group der Spezifikation hatte beim MCP Dev Summit im April 2026 sechs dedizierte Sessions, an denen der Autor der OAuth-2.1-Spezifikation persönlich teilnahm.
Die MCP-Roadmap 2026 nannte Audit-Trail-Infrastruktur, SSO-integrierte Authentifizierung und Konfigurations-Portabilität als die meistgefragten Enterprise-Features[7]. Keines davon ist bisher gelöst. Die Roadmap ist eine Absichtserklärung, keine Lieferung.
The authentication gap is real. Research published in early 2026 documented more than 1,800 active MCP servers on the public internet with no authentication whatsoever. Because authentication in MCP is optional — not required by the spec — they are technically compliant and practically insecure. Before deploying any MCP server, verify OAuth 2.1 is enabled and enforced, not just installed.
MCP-I / KYA-OS: Dezentralisierte Identität für Agenten
OAuth 2.1 regelt die Authentifizierung - den Nachweis, dass ein Agent der ist, der er vorgibt zu sein. Es beantwortet nicht die schwierigeren Fragen: Wer hat diesen Agenten autorisiert? Was darf er im Auftrag welchen Menschen tun? Kann ein nachgelagerter Dienst diese Kette verifizieren, ohne vorherige Abstimmung?
Im März 2026 übergab Vouched das Model Context Protocol - Identity (MCP-I) Framework formell an die Decentralized Identity Foundation (DIF), wo es nun von der DIF Trusted AI Agents Working Group betreut wird[8]. Die Spezifikation wurde inzwischen in KYA-OS (Know Your Agent Operating System) umbenannt, um ihren Geltungsbereich jenseits von MCP allein zu verdeutlichen.
MCP-I / KYA-OS verwendet Decentralized Identifiers (DIDs) und Verifiable Credentials (VCs), um eine kryptografisch gesicherte Verifizierung sowohl von Agenten als auch ihrer menschlichen Auftraggeber zu ermöglichen - ohne vorherige Abstimmung zwischen den Parteien[9]. Das Framework definiert vier Identitätsfragen, die jeder Dienst beantworten können sollte: Wer ist der Agent? Wer hat ihn autorisiert? Was darf er tun? Wie weit reicht diese Delegation?
Das ist die richtige Architektur für agentenübergreifende Workflows zwischen mehreren Organisationen - etwa ein Reisebuchungsagent, der im Auftrag eines Nutzers mit Fluggesellschaft, Hotel und Zahlungssystem interagiert. Es ist aber auch noch früh. Die Spezifikation befindet sich in aktiver Community-Entwicklung, und produktive Implementierungen sind rar.
Microsoft Entra Agent ID
Microsoft war unter den großen Identity-Plattformen am schnellsten. Microsoft Entra Agent ID führt Agenten-Identitäten als eigenständiges, zweckgebautes Konstrukt ein - keine zweckentfremdeten Service-Principals oder User-Accounts - mit Agent-Identity-Blueprints als Vorlagen für die Erstellung einzelner Agenten-Identitäten mit Eltern-Kind-Beziehungen[10].
Agenten-Identitäten in Entra besitzen keine eigenen Credentials; sie nutzen den Agent-Identity-Blueprint, um Token in ihrem Namen zu beziehen, und authentifizieren sich ausschließlich über Federated Identity Credentials[11]. Das ist das richtige Modell: Credentials liegen im Blueprint, nicht beim Agenten - ein kompromittierter Agent kann also keine eigenen Schlüssel exfiltrieren.
Microsoft Agent 365, seit dem 1. Mai 2026 allgemein verfügbar, gibt jedem KI-Agenten eine eigene Entra Agent ID für Identity-, Lifecycle- und Access-Management und integriert sich in Conditional Access, Identity Protection und Microsoft Purview[12]. Drittanbieter-Agenten von AWS Bedrock, n8n und anderen Frameworks können per Workload Identity Federation eingebunden werden - ohne plattformspezifisches Credential-Management.
Die ehrliche Einschränkung: Entra Agent ID ist eine starke Lösung, wenn Ihr Agenten-Portfolio im Microsoft-Ökosystem lebt. Für Organisationen mit heterogenen Stacks - Anthropic, AWS, Open-Source-Frameworks und Eigenentwicklungen - reicht die Governance-Oberfläche weit über das hinaus, was ein einzelner IdP abdecken kann.
CSA Agentic Trust Framework und CSAI Foundation
Die Cloud Security Alliance war in diesem Bereich der produktivste Standards-Produzent. Die CSA veröffentlichte das Agentic Trust Framework (ATF) am 2. Februar 2026 - die erste Governance-Spezifikation, die Zero-Trust-Prinzipien auf autonome KI-Agenten mit einem strukturierten Reifegradmodell anwendet[13]. Das ATF wurde von John Kindervag mitentwickelt, dem ursprünglichen Schöpfer von Zero Trust.
Eine Begleitstudie unter 285 IT- und Sicherheitsexperten macht die Dringlichkeit konkret: 84 % der Organisationen würden ein Compliance-Audit zu Agentenverhalten oder Zugriffskontrollen nicht bestehen, und nur 23 % verfügen über eine formale Agenten-Identitätsstrategie[14].
Das MAESTRO-Bedrohungsmodell der CSA benennt Agent Impersonation explizit als eigene Bedrohungsklasse - böswillige Akteure, die Nutzer oder andere Agenten täuschen, indem sie legitime KI-Agenten imitieren. Die vorgeschriebenen Gegenmaßnahmen sind vertrauenswürdige Agenten-Registries, kryptografische Agenten-Identitäten und kurzlebige OAuth/OIDC-Token, die auf den Schnittbereich dessen beschränkt sind, was der Agent tun darf UND was der delegierende Nutzer tun darf. Ein UND-Gatter, kein ODER-Gatter.
Im März 2026 gründete die CSA auf der RSAC 2026 die CSAI Foundation - eine neue 501(c)3-Organisation, die sich ausschließlich der KI-Sicherheit widmet, mit der Mission 2026 "Securing the Agentic Control Plane": Governance von Identität, Autorisierung, Orchestrierung, Laufzeitverhalten und Trust Assurance für autonome KI-Agenten-Ökosysteme[15].
Die Akteurskarte: Vier Kategorien, unterschiedliche Stärken
Die Anbieterlandschaft hat sich in vier klar unterschiedliche Kategorien aufgeteilt. Es ist entscheidend zu verstehen, was jede davon leistet - und was nicht - bevor man kauft.
| Category | Examples | Core Strength | Key Gap |
|---|---|---|---|
| Identity Providers extending to agents | Microsoft Entra Agent ID, Okta (MCP server + Auth for MCP), Auth0 | Standards-based auth (OAuth 2.1/OIDC), existing enterprise trust, lifecycle hooks | Ecosystem lock-in; heterogeneous agent stacks require federation workarounds |
| NHI Security Specialists | Oasis Security, Entro, Teleport | Discovery, secrets rotation, posture management for service accounts and API keys | Agent governance is identity-discovery-led, not runtime-enforcement-led; agents treated as NHI subset, not first-class |
| MCP Gateways | Arcade, TrueFoundry, Cloudflare Agents SDK | Runtime authorization at the tool-call level; per-session ephemeral credentials; low-latency enforcement | Closed ecosystems; governance doesn't extend to human identities or non-MCP agents |
| IGA Platforms governing agents + humans | Iden, SailPoint (Agent Identity Security add-on), ServiceNow/Veza | Unified lifecycle governance across human and non-human identities; policy-driven provisioning and deprovisioning; access reviews | Legacy IGA platforms bolt on agent support; depth and automation vary significantly |
Einige Anmerkungen zur Landschaft:
Identity Provider bewegen sich schnell. Auth0s "Auth for MCP" wurde am 6. Mai 2026 allgemein verfügbar, und Okta veröffentlichte einen eigenen MCP-Server als sichere Protokoll-Abstraktionsschicht, die KI-Agenten die Interaktion mit Oktas bereichsbeschränkten Management-APIs ermöglicht - mit Least-Privilege-Zugriffskontrolle bei jedem Tool-Aufruf[2]. Das sind Authentifizierungslösungen. Sie regeln nicht den vollständigen Identity Lifecycle.
NHI-Spezialisten haben die Discovery-Geschichte richtig. Vezas "2026 State of Identity and Access"-Bericht ergab, dass gerade einmal 0,01 % der nicht-menschlichen Identitäten 80 % der Cloud-Ressourcen kontrollieren, während ein durchschnittlicher Mitarbeiter 96.000 Berechtigungen hält[16]. Das zu wissen ist wertvoll. Es zu steuern erfordert mehr als ein Posture-Dashboard.
MCP-Gateways lösen das Runtime-Enforcement-Problem elegant für Agenten, die innerhalb ihres Ökosystems gebaut werden. Das Problem ist die Abdeckung: Nur 23,7 % der Organisationen nutzen ihren bestehenden IAM/IdP als Authorization Server für ihre agentische MCP-Infrastruktur[3]. Der Rest betreibt voneinander getrennte Auth-Stacks.
IGA-Plattformen sind der natürliche Ort für Agenten-Governance - sofern sie diese tatsächlich gebaut haben. SailPoint erweiterte die Agent Identity Security Connectors 2026 um SaaS-Versionen von Salesforce, ServiceNow und Snowflake, doch die Governance von Agenten-Identitäten erfordert eine separate Agent Identity Security-Lizenz[17]. Legacy-IGA-Anbieter fügen Agenten-Unterstützung als Modul hinzu. Das ist nicht dasselbe wie eine von Grund auf dafür ausgelegte Architektur.
Die ehrlichen Lücken
Standards sind unreif. Das MCP-OAuth-2.1-Profil ist für die Authentifizierung solide, hat aber kein standardisiertes Audit-Trail-Format. MCP-I / KYA-OS befindet sich in aktiver Community-Entwicklung mit wenigen produktiven Implementierungen. Das CSA ATF ist ein Governance-Framework, kein Enforcement-Tool.
Die Monitoring-Lücke ist gravierend. Nur 14,4 % der Organisationen haben für ihre gesamte Agenten-Flotte die vollständige IT- und Sicherheitsgenehmigung erhalten, und 88 % der Organisationen meldeten im vergangenen Jahr bestätigte oder vermutete KI-Agenten-Sicherheitsvorfälle[18]. Nur 21,9 % der Organisationen behandeln KI-Agenten in ihrem Sicherheitsmodell als eigenständige, identitätstragende Einheiten[3]. Die meisten behandeln Agenten noch immer als Erweiterungen menschlicher Nutzer oder als generische Service-Accounts.
Das Überprivilegierungsproblem ist strukturell. 70 % der Sicherheitsverantwortlichen geben an, dass KI-Systeme mehr Zugriff haben als ein Mensch in derselben Rolle, und 67 % der Organisationen setzen auf statische Credentials für KI-Systeme[19]. Statische, langlebige Credentials sind das Gegenteil von dem, was jedes Framework empfiehlt. Sie bleiben nach Abschluss einer Agenten-Aufgabe bestehen, überleben das Offboarding und erzeugen dasselbe Problem verwaister Konten, das die menschliche Identity Governance seit Jahrzehnten plagt - nur in Maschinengeschwindigkeit.
Die CSA-Oasis State of NHI and AI Security 2026 ergab, dass 51 % der Organisationen überprivilegierten Zugriff als größten NHI-Schmerzpunkt nennen und 78 % keine dokumentierte Richtlinie für die Erstellung oder Entfernung von KI-Identitäten haben[20].
Wie IGA aussieht, wenn es dafür gebaut wurde
Das Governance-Problem für KI-Agenten ist strukturell identisch mit dem Governance-Problem für menschliche Identitäten - und aus demselben Grund, aus dem IGA existiert: Zugriffs-Sprawl, verwaiste Konten, Überprivilegierung und die Unfähigkeit, zu jedem Zeitpunkt zu beantworten: "Wer hat Zugriff auf was, und sollte das so sein?"
Der Unterschied liegt in Geschwindigkeit und Umfang. Nicht-menschliche Identitäten übersteigen menschliche Identitäten im durchschnittlichen Unternehmen im Verhältnis 17:1, und die NHI-Population wuchs zwischen 2024 und 2025 um 44 % im Jahresvergleich[21]. KI-Agenten sind das am schnellsten wachsende Segment innerhalb dieser ohnehin explodierenden Kategorie. Quartalsweise Access-Reviews können nicht mithalten. Excel-Listen auch nicht.
Was gebraucht wird, ist eine einheitliche Governance-Ebene, die menschliche und nicht-menschliche Identitäten mit derselben Policy-Engine, derselben Lifecycle-Automatisierung und denselben Access-Review-Workflows behandelt - ohne ein separates Modul, eine separate Lizenz oder ein separates Team zu erfordern.
Das ist das Designprinzip hinter Iden. Anstatt Agenten-Governance auf eine menschenzentrierte IGA-Plattform aufzupfropfen oder Agenten als Teilmenge der NHI-Discovery zu behandeln, steuert Iden alle Identitätstypen - Mitarbeiter, externe Mitarbeiter, Service-Accounts, Bots und KI-Agenten - über dieselbe richtliniengesteuerte Lifecycle-Engine. Feingranulare Kontrolle auf Kanal-, Repository- und Projektebene bedeutet, dass ein Agent genau den Zugriff erhält, den seine Aufgabe erfordert - und dieser Zugriff wird entzogen, wenn die Aufgabe abgeschlossen ist. Keine dauerhaften Berechtigungen. Keine verwaisten Agenten-Konten.
Für Organisationen, die evaluieren, wo KI-Agenten-Governance in ihren Stack passt, bietet der Beitrag 12 beste IGA-Anbieter 2026 eine vollständige Übersicht der Landschaft, und unser NHI-Explosion-Beitrag beleuchtet das Ausmaß des zugrundeliegenden Problems im Detail.
Wie man Agenten-Identitätsfähigkeiten heute bewertet
Die Standards sind unreif, die Anbieterversprechen sind den Implementierungen voraus, und die Bedrohung ist real. Hier ist ein praktisches Bewertungsframework für Käufer.
You cannot govern what you cannot see. Start with a full discovery pass: which agents are running, who deployed them, what credentials they hold, and what systems they can reach. Shadow agents — those with no registry entry, no assigned owner, and no managed identity — are your highest-risk population. Treat them as Critical findings.
Any platform that relies on shared API keys or long-lived static credentials for agent authentication is not a governance solution. Require per-session ephemeral tokens scoped to the specific task, with automatic teardown at end of session. This is the single highest-leverage control against prompt injection and credential theft.
An agent should only be able to do what the agent is authorized to do AND what the delegating user is authorized to do — not the union of both. Service accounts that inherit broad employee credentials create authorization bypass vulnerabilities. Confirm that your chosen platform enforces the intersection, not the superset.
Logging that an agent 'ran' is not an audit trail. You need: which agent, which user delegated, which tool was called, with what arguments, what data was accessed, and what the result was. The EU AI Act's transparency provisions take effect August 2, 2026. If your platform cannot produce this log on demand, it cannot support compliance.
Runtime authorization at the tool-call level is necessary but not sufficient. You also need: agent registration and approval workflows before deployment, access reviews on the same cadence as human identities, and automated deprovisioning when an agent is retired. Ask vendors specifically how they handle agent offboarding — most have no answer.
Separate tools for human IGA and agent governance create blind spots at the seams. An agent acting on behalf of a human should be governed in the same plane as that human — same policy engine, same access review, same audit log. If your IGA platform treats agents as a bolt-on module, you have a coverage gap.
Das Fazit
Die Standards-Landschaft 2026 für KI-Agenten-Identitäten ist real und bewegt sich schnell - MCP OAuth 2.1 unter Linux-Foundation-Governance, MCP-I / KYA-OS beim DIF, Microsoft Entra Agent ID in GA und das CSA Agentic Trust Framework als Governance-Vokabular. Das sind echte Meilensteine.
Aber Standards sind keine Implementierungen. Nur 3 % der Organisationen verfügen über automatisierte, maschinengeschwindige Kontrollen zur Steuerung des KI-Verhaltens[19]. Die Lücke zwischen dem, was die Frameworks vorschreiben, und dem, was Organisationen tatsächlich eingesetzt haben, ist enorm.
Die Organisationen, die diese Lücke am schnellsten schließen, werden diejenigen sein, die aufhören, Agenten-Governance als ein von Identity Governance getrenntes Problem zu behandeln. Agenten sind Identitäten. Sie benötigen dieselben Lifecycle-Kontrollen, dieselben Access-Reviews, dieselben Deprovisionierungs-Workflows und dieselben Audit-Trails wie jede andere Identität in Ihrer Umgebung - nur mit kurzlebigeren Credentials und schnellerer Policy-Durchsetzung.
Das ist keine neue Tooling-Kategorie. Es ist IGA, gebaut für die gesamte Population der Identitäten, die Ihr Unternehmen tatsächlich betreibt.