Agenten-Identität 2026: Warum Ihre KI-Agenten keine Service-Accounts sind

Ein KI-Agent ist kein Skript. Er entscheidet zur Laufzeit, welches Werkzeug er als Nächstes aufruft, er kettet Aufrufe aneinander, und er tut das im Auftrag eines Menschen, der die einzelnen Schritte nicht vorab kennt. Genau deshalb bricht das Identitätsmodell, mit dem die meisten Unternehmen heute arbeiten: der technische Nutzer, angelegt einmalig im Active Directory, ausgestattet mit einem Passwort, das seit zwei Jahren im selben Secrets-Store liegt.

Der 28. Juli 2026 hat diese Diskussion aus der Architekturzeichnung in die Ausschreibung geholt. Seit der neuen Revision der Model-Context-Protocol-Spezifikation ist Autorisierung normativ an OAuth 2.1 (draft-ietf-oauth-v2-1-13) gebunden – mit harten MUSS-Anforderungen für Clients und Server. Wer heute einen MCP-Server einkauft oder selbst betreibt, muss diese Anforderungen im Lastenheft stehen haben. Dieser Beitrag zeigt, was genau vorgeschrieben ist, was die aktuellen Erhebungen über den realen Reifegrad sagen, und wie eine Referenzarchitektur im eigenen Netz aussieht.

Warum der Service-Account als Modell versagt

Der klassische technische Nutzer wurde für Batchjobs entworfen: ein Prozess, eine feste Aufgabe, ein feststehender Satz Berechtigungen. Ein agentisches System verletzt jede dieser drei Annahmen. Es führt viele verschiedene Aufgaben aus, in wechselnder Reihenfolge, für wechselnde Auftraggeber – und der Berechtigungsbedarf ist erst zur Laufzeit bekannt.

Daraus folgen drei strukturelle Defekte:

• Kein Zweckbezug, keine Delegationskette. Ein Service-Account beantwortet die Frage „wer handelt hier?" mit einem Namen wie svc-agent-prod. Er beantwortet nicht, für welchen Mitarbeiter, in welchem Vorgang und mit welcher Berechtigungsgrundlage gehandelt wurde. Für eine DSGVO-Auskunft oder eine Innenrevision ist das wertlos.
• Langlebige Secrets ohne Rotation. Client Secrets und API-Keys von technischen Nutzern werden typischerweise angelegt und dann vergessen. In der Erhebung der Cloud Security Alliance vom 24. März 2026 (im Auftrag von Aembit, 228 IT- und Security-Fachleute) gaben 33 Prozent an, überhaupt nicht zu wissen, wie oft die Credentials ihrer Agenten rotiert werden.
• Ein kompromittierter Account öffnet alle Werkzeuge. 43 Prozent der befragten Organisationen stützen ihre Agenten auf gemeinsam genutzte Service-Accounts, 31 Prozent lassen Agenten sogar unter der Identität eines Menschen laufen. 74 Prozent sagen selbst, dass ihre Agenten mehr Zugriff haben, als sie brauchen.

Die letzte Zahl korrespondiert mit einem Befund des Palo-Alto-Networks-Reports: 96 Prozent der Organisationen berichten, dass auch ihre menschlichen Identitäten weit mehr Zugriff haben, als die jeweilige Rolle erfordert. Ein Agent, der unter einer solchen Identität läuft, erbt diese Überprivilegierung eins zu eins – und multipliziert sie mit der Geschwindigkeit einer Maschine.

Die Größenordnung: 109 Maschinen auf einen Menschen

Der 2026 Identity Security Landscape Report von Palo Alto Networks, veröffentlicht im Mai 2026 auf Basis einer Befragung von 2.930 Cybersecurity-Entscheidern weltweit, liefert die belastbarste Mengenangabe: Maschinenidentitäten übersteigen menschliche Identitäten im Verhältnis 109:1. Im Vorjahresbericht lag das Verhältnis noch bei 82:1. Das ist ein Zuwachs von rund einem Drittel innerhalb von zwölf Monaten.

Nach Auswertungen des Reports entfällt der größere Teil dieser Maschinenidentitäten inzwischen auf KI-Agenten – die häufig zitierte Aufteilung von 79 der 109 Identitäten je Mensch findet sich allerdings nur in Sekundärauswertungen, nicht in den öffentlich zugänglichen Primärseiten. Belastbar sind hingegen die Prognosewerte: Für die kommenden zwölf Monate erwarten die Befragten ein Wachstum der Maschinenidentitäten um 77 Prozent, der menschlichen Identitäten um 56 Prozent und der KI-Agenten um 85 Prozent.

Die Verbreitung ist bereits jetzt praktisch flächendeckend: 99 Prozent der Organisationen haben KI-Agenten eingeführt, und 40 Prozent dieser Agenten haben Zugriff auf Unternehmensdaten. Gleichzeitig hatten neun von zehn Organisationen in den letzten zwölf Monaten einen erfolgreichen identitätsbezogenen Sicherheitsvorfall.

Kennzahl	Wert	Erhebung
Maschinen- zu Menschenidentitäten	109:1 (Vorjahr 82:1)	Palo Alto Networks 2026, n = 2.930
Können Agenten-Credentials widerrufen	37 %	Palo Alto Networks 2026
Haben unveränderliche Audit-Logs für Agenten	30 %	Palo Alto Networks 2026
Haben unbekannte Agenten in der Umgebung entdeckt	82 % (41 % mehrfach)	CSA / Token Security, 21.04.2026, n = 418
Hatten in 12 Monaten einen Agenten-Vorfall	65 %	CSA / Token Security, 21.04.2026
Können Agenten- nicht von Menschenhandlung unterscheiden	68 %	CSA / Aembit, 24.03.2026, n = 228

Zwei Einschränkungen gehören zur Redlichkeit dazu: Die beiden CSA-Umfragen sind mit 418 beziehungsweise 228 Teilnehmenden klein und wurden von Anbietern beauftragt, die im Markt für Non-Human-Identity-Produkte aktiv sind. Sie taugen als Richtungsindikator, nicht als repräsentative Statistik. Der Palo-Alto-Report ist mit 2.930 Befragten deutlich breiter angelegt.

Was die MCP-Spezifikation 2026-07-28 vorschreibt

Die Revision vom 28. Juli 2026 ist die bislang umfangreichste Härtung der Autorisierung im Model Context Protocol. Sie betrifft nicht nur Sicherheitsteams, sondern jede Beschaffung: Ein MCP-Server, der diese Anforderungen nicht erfüllt, ist im regulierten Umfeld nicht abnahmefähig.

Die harten Pflichten im Überblick

Anforderung	Normstufe	Adressat
Protected Resource Metadata (RFC 9728)	MUSS	MCP-Server
resource-Parameter (RFC 8707) in Auth- und Token-Request	MUSS	MCP-Client
PKCE mit S256, Vorabprüfung der Unterstützung	MUSS	MCP-Client
iss-Validierung nach RFC 9207 vor Code-Einlösung	MUSS	MCP-Client
iss-Parameter in Autorisierungsantworten senden	SOLL	Autorisierungsserver
Token-Audience prüfen, kein Token-Passthrough	MUSS	MCP-Server
Client-Credentials an ausstellenden Issuer binden	MUSS	MCP-Client
CIMD unterstützen (DCR bleibt Rückfallebene)	SOLL / MAY	Client & AS

Wichtig ist die genaue Normsprache, weil sie in Ausschreibungen häufig verschärft zitiert wird. Die Issuer-Prüfung nach RFC 9207 ist clientseitig Pflicht: Ein MCP-Client MUSS die Validierung nach Abschnitt 2.4 anwenden, bevor er einen Authorization Code an einen Token-Endpunkt schickt. Für den Autorisierungsserver gilt bislang nur ein SHOULD, den iss-Parameter mitzusenden – die Spezifikation kündigt allerdings ausdrücklich an, dass eine künftige Revision diese Pflicht auf MUST anheben wird. Wer heute einen Server beschafft, sollte MUST bereits vertraglich vereinbaren.

CIMD: die Client-ID ist eine URL

Der größte praktische Bruch liegt bei der Client-Registrierung. Dynamic Client Registration nach RFC 7591 ist formal deprecated. An seine Stelle treten Client ID Metadata Documents (CIMD): Der Client hostet ein JSON-Metadatendokument unter einer stabilen HTTPS-URL – und diese URL ist die client_id. Pflichtfelder sind mindestens client_id, client_name und redirect_uris. Die im Dokument angegebene client_id muss exakt der Dokument-URL entsprechen, der Autorisierungsserver muss das prüfen, muss die redirect_uris gegen das Dokument validieren und soll dabei SSRF-Risiken berücksichtigen.

Der Vorteil ist Portabilität: CIMD-Client-IDs funktionieren über Autorisierungsserver hinweg, DCR-Registrierungen und vorregistrierte Credentials nicht. Die Spezifikation gibt Clients eine klare Prioritätsreihenfolge vor: erstens vorregistrierte Client-Daten, zweitens CIMD (sofern der Autorisierungsserver client_id_metadata_document_supported meldet), drittens DCR als Fallback, viertens manuelle Eingabe durch den Nutzer. DCR bleibt als MAY für Rückwärtskompatibilität erhalten, mit einem Mindest-Deprecation-Fenster von zwölf Monaten. „CIMD ist vorgeschrieben" wäre also falsch – „DCR ist abgekündigt" ist richtig.

Am Rande, aber betriebsrelevant: Dieselbe Revision macht den Protokollkern zustandslos. Der initialize/initialized-Handshake und der Mcp-Session-Id-Header entfallen, Multi Round-Trip Requests (MRTR) mit resultType: "input_required" ersetzen serverinitiierte Requests, Tasks werden zur offiziellen Extension mit tasks/get und tasks/update, und Listen-Antworten tragen ttlMs sowie cacheScope. Wer Gateways oder Proxies betreibt, muss diese Änderungen mitziehen.

Delegation: der Agent handelt im Auftrag eines Menschen

Die zentrale Anforderung an ein Agenten-Identitätsmodell lautet: Die Verbindung zwischen Agent, Auftraggeber und Zweck darf auf keinem Schritt der Kette verloren gehen. Ein Multi-Agenten-System, in dem ein Orchestrator drei Subagenten beauftragt, produziert schnell vier Ebenen – und wenn Ebene vier ein CRM schreibt, muss noch nachvollziehbar sein, welche Sachbearbeiterin den Vorgang angestoßen hat.

Drei Konstruktionsregeln haben sich bewährt:

1. Die menschliche Identität bleibt Teil der Kette. On-Behalf-Of-Muster tragen den Endnutzer als Subject weiter, während der Agent als handelnder Actor auftritt. Das Token beantwortet damit beide Fragen: wer wollte, und wer hat ausgeführt.
2. Scope je Aufgabe, nicht je Agent. Ein Agent bekommt nicht einmalig „CRM lesen und schreiben", sondern für den konkreten Vorgang „Kontakt 4711 lesen, Notiz anhängen". Das reduziert den Schaden eines Prompt-Injection-Treffers drastisch, weil das erbeutete Token außerhalb dieses Vorgangs wertlos ist.
3. Ablaufzeit an die Aufgabendauer koppeln. Wenn ein Rechercheauftrag typischerweise vier Minuten dauert, ist eine Token-Lebensdauer von 15 Minuten großzügig und von acht Stunden fahrlässig. Zur Einordnung: Palo Alto beziffert die Zeit vom Erstzugriff bis zur Exfiltration bei KI-gestützten Angriffen auf 25 Minuten.

Ehrlicherweise gehört dazu: Die Standardisierung dieser Delegationskette ist noch nicht abgeschlossen. Es gibt keinen verabschiedeten RFC für Workload-Delegation im Agentenkontext. Wer heute baut, implementiert ein Muster – kein zertifizierbares Protokoll. Das ist kein Argument gegen den Bau, aber eines für saubere Abstraktion: Halten Sie die Token-Ausstellung hinter einer eigenen Schnittstelle, damit ein späterer Standard eingezogen werden kann, ohne dass jede Tool-Use-Integration angefasst werden muss.

Governance-Lücke: Zweckbindung, Kill Switch, Nachweiskette

Die Erhebungen des Jahres 2026 zeichnen ein konsistentes Bild: Agenten sind im produktiven Einsatz – 85 Prozent der von der CSA befragten Organisationen betreiben sie in Produktion – aber die drei Kontrollen, die im Ernstfall zählen, fehlen mehrheitlich.

Zweckbindung wird kaum durchgesetzt

In der CSA-/Token-Security-Umfrage vom 21. April 2026 blockieren nur 11 Prozent Aktionen automatisch, die außerhalb des erteilten Auftrags liegen. 38 Prozent verlangen dann eine menschliche Freigabe, 24 Prozent protokollieren lediglich. 66 Prozent geben an, klare Guardrails definiert zu haben – zwischen definierter Leitplanke und technisch durchgesetzter Leitplanke liegt offenkundig eine Lücke.

Der Kill Switch existiert selten wirklich

Nur 37 Prozent der Organisationen können laut Palo Alto die Credentials eines KI-Agenten überhaupt widerrufen. Gefragt nach der konkreten Eindämmung eines fehlgeleiteten Agenten nennen in der CSA-/Aembit-Erhebung 49 Prozent das Deaktivieren von Identitäten oder Widerrufen von Token, 42 Prozent das Beenden der Compute-Umgebung und 33 Prozent die Änderung von Zugriffsrichtlinien in Echtzeit. Nur 21 Prozent haben überhaupt einen formalen Prozess zur Außerbetriebnahme eines Agenten.

Die Nachweiskette bricht an der Zuordnung

68 Prozent der Befragten können Aktivitäten von KI-Agenten nicht klar von menschlichen Aktivitäten unterscheiden. Nur 30 Prozent verfügen über manipulationssichere Audit-Logs für Agentenaktivitäten. Wer in einem Vorfall nicht sagen kann, ob eine Datenbankabfrage von einem Mitarbeiter oder von einem Agenten kam, kann weder eine Meldefrist sauber bedienen noch eine Betroffenenauskunft belegen.

Referenzarchitektur im eigenen Netz

Der gute Teil der Nachricht: Sämtliche Bausteine für ein belastbares Agenten-Identitätsmodell sind als offene Software verfügbar und lassen sich on-premise betreiben. Eine bewährte Aufteilung in vier Schichten:

1. Lokaler OIDC-Provider als Aussteller

Ein selbst betriebener OpenID-Connect-Provider – Keycloak, Authentik oder ZITADEL sind die üblichen Kandidaten – wird zur einzigen Ausstellungsstelle für Agenten-Identitäten. Jeder Agent bekommt einen eigenen Client-Eintrag, kein geteiltes Konto. Token-Laufzeiten werden auf Minuten gesetzt, nicht auf Stunden. Refresh Tokens werden rotiert und an den ausstellenden Issuer gebunden.

2. Credential-Broker am Egress

Der Agent selbst sieht niemals das echte Zielsystem-Secret. Er erhält ein kurzlebiges Token seines eigenen Identitätsproviders; erst am Egress-Gateway tauscht ein Credential-Broker dieses Token gegen die tatsächliche Zugangsberechtigung des Zielsystems – und protokolliert den Tausch. Damit ist ein per Prompt Injection abgegriffener Kontext wertlos, weil er kein Zielsystem-Secret enthält. Wie das im MCP-Kontext konkret aussieht, beschreiben wir im Beitrag zu Egress-Kontrolle und Credential-Injection.

3. Policy-Punkt mit Laufzeitentscheidung

Zwischen Agent und Werkzeug gehört ein Punkt, der pro Aufruf entscheidet: erlauben, blockieren oder zur menschlichen Freigabe umleiten. Die Entscheidungsgrundlage sind Identität, Scope, Zweck des Vorgangs und Risikoklasse der Aktion. Dieser Punkt ist auch die Stelle, an der die 11-Prozent-Lücke bei der Zweckbindung geschlossen wird – automatische Blockade statt nachträglicher Protokollierung.

4. Widerruf auf zwei Ebenen gleichzeitig

Ein Kill Switch, der nur die Identität beim Provider deaktiviert, lässt bereits ausgestellte Tokens bis zum Ablauf gültig. Ein Kill Switch, der nur den Netzwerkpfad sperrt, lässt den Agenten auf lokal zwischengespeicherte Credentials zurückfallen. Beide Ebenen müssen aus einer Aktion heraus greifen: Token-Revocation beim Provider und Egress-Sperre am Gateway – idealerweise auch bei laufenden Verbindungen.

Proprietäre Agent-Passports gegen offene Standards

Weil die Standardisierung hinterherhinkt, füllt der Markt die Lücke mit Produkten. Unter Namen wie „Agent Passport", „Agent Identity Fabric" oder „Non-Human Identity Platform" werden im Kern drei Funktionen gebündelt: eine Attestierung des Agenten gegen Kontrollrahmen wie OWASP, das NIST AI Risk Management Framework und MITRE ATLAS; eine Laufzeitentscheidung nach dem Muster allow / block / route inklusive Widerruf; und ein Nachweisspeicher, der beides revisionsfest ablegt.

Der Nutzen ist real – der Preis ist Bindung. Es gibt Ende August 2026 keinen verabschiedeten offenen Standard für Agent Passports. Der Stand im Einzelnen:

• CIMD ist ein Internet-Draft: draft-ietf-oauth-client-id-metadata-document, Revision -02 vom 6. Juli 2026, Autoren Aaron Parecki (Okta) und Emelia Smith in der OAuth-Arbeitsgruppe. Die MCP-Spezifikation referenziert normativ sogar noch Revision -00.
• WIMSE (Workload Identity in Multi System Environments), die IETF-Arbeitsgruppe, die für Workload-Identität zuständig wäre, hat bislang keinen einzigen RFC veröffentlicht – nur Internet-Drafts; das Architekturdokument war für Juli 2026 fällig.
• IPSIE bei der OpenID Foundation (Vorsitz Aaron Parecki, Okta, und Dick Hardt, Hellō) profiliert bestehende Spezifikationen – OpenID Connect, OAuth 2.0, SCIM, Shared Signals – für SSO, User Lifecycle, Entitlements, Risikosignale, Logout und Token-Widerruf. Agenten-Identität wird auf der Charter-Seite bisher nicht explizit adressiert.

Die pragmatische Abwägung für den Mittelstand: Kaufen Sie Produkte für Sichtbarkeit und Laufzeitdurchsetzung, wenn Ihnen die Zeit fehlt – aber halten Sie Ausstellung und Widerruf im eigenen OIDC-Provider. Das ist der Teil, der nach einem Anbieterwechsel weiterlaufen muss. Und verlangen Sie im Vertrag einen Exportpfad für die Nachweisketten: Ein Audit-Log, das nur im SaaS-Portal des Anbieters lesbar ist, hilft Ihnen bei einer Prüfung durch die Aufsichtsbehörde nicht weiter.

Fazit: drei Schritte für die nächsten 90 Tage

Agenten-Identität ist 2026 kein Zukunftsthema mehr, sondern eine offene Flanke mit belegbarer Größenordnung. Drei Schritte, die sich ohne Großprojekt umsetzen lassen:

1. Inventarisieren. Suchen Sie gezielt an den vier bekannten Fundorten für Schatten-Agenten: interne Automatisierungen, LLM-Plattformen, SaaS-Tools mit eingebauter Automatisierung, entwicklergebaute Workflows. Rechnen Sie mit Funden – 82 Prozent tun es.
2. Trennen. Kein Agent läuft mehr unter einer menschlichen Identität oder einem geteilten Service-Account. Jeder Agent bekommt einen eigenen Client im eigenen OIDC-Provider, mit Token-Laufzeiten im Minutenbereich.
3. Üben. Führen Sie eine Kill-Switch-Übung durch: einen produktiven Agenten stilllegen, Zeit stoppen, danach die letzten 24 Stunden seiner Aktivität rekonstruieren. Was dabei nicht funktioniert, ist Ihre Prioritätenliste.

Wenn Sie MCP-Server im eigenen Netz betreiben oder beschaffen, nehmen Sie die Anforderungstabelle aus Abschnitt drei direkt ins Lastenheft auf. Unsere Gateway- und Identitätsberatung begleitet Sie dabei von der Inventur bis zur abgenommenen Architektur.

Quellen & Primärbelege

Alle Zahlen, Fristen und Produktangaben in diesem Beitrag wurden vor der Veröffentlichung gegen die folgenden Primärquellen geprüft.

1. Palo Alto Networks Blog Verhältnis 109:1, Reifegradbewertung
2. Identity Security Landscape Report 2026 Primärseite, n = 2.930
3. Help Net Security, 14.05.2026 Auswertung des Reports
4. MCP-Spezifikation 2026-07-28 – Authorization OAuth 2.1, RFC 8707, RFC 9207, PKCE
5. MCP-Spezifikation – Client Registration CIMD, DCR-Deprecation, Prioritätsreihenfolge
6. MCP-Spezifikation – Security Considerations Token-Audience, Passthrough-Verbot
7. MCP-Release-Ankündigung 28.07.2026 Stateless Core, MRTR, Tasks-Extension
8. CSA / Token Security, 21.04.2026 Schatten-Agenten, n = 418
9. CSA / Aembit, 24.03.2026 Zuordnung Agent/Mensch, n = 228
10. IETF Datatracker – CIMD-Draft Revision -02 vom 06.07.2026
11. IETF-Arbeitsgruppe WIMSE Charter -01, bislang kein RFC
12. OpenID Foundation – IPSIE Profilierung bestehender Spezifikationen
13. VectorEdge – NHI Security Sekundärauswertung Maschinenidentitäten

Häufig gestellte Fragen zur Agenten-Identität

Kann ich Agenten nicht einfach als technische Nutzer im AD anlegen?

Technisch ja, praktisch nein. Ein statischer Account trägt weder Zweckbindung noch Delegationskette und lässt sich nicht gezielt für eine einzelne Aufgabe widerrufen.

Was ist CIMD und warum ersetzt es Dynamic Client Registration?

Client ID Metadata Documents beschreiben den Client über ein abrufbares Dokument statt über eine dynamische Registrierung. Die MCP-Spezifikation 2026-07-28 hat DCR zugunsten von CIMD abgekündigt.

Brauche ich ein kommerzielles Agent-Passport-Produkt?

Nicht zwingend. Mit einem eigenen OIDC-Provider, kurzlebigen Tokens, einem Credential-Broker und einem Gateway lässt sich derselbe Funktionsumfang im eigenen Netz abbilden.

Wie sieht ein echter Kill Switch aus?

Er wirkt auf zwei Ebenen gleichzeitig: Widerruf der Identität beim Provider und Sperrung des Egress am Gateway. Nur eine der beiden Maßnahmen lässt Restwege offen.