Ohne Identität bleibt Agentic AI ein Nebenaccount mit zu viel Macht

Viele Unternehmen reden bei KI-Agenten zuerst über Modelle, Prompts und Automatisierungsgewinn. Das ist nachvollziehbar, führt im Betrieb aber schnell in die falsche Richtung. Sobald ein Agent Mails lesen, Kalender ändern, Tickets anlegen, Dokumente abrufen oder Tools über MCP ansprechen darf, geht es nicht mehr nur um gute Antworten. Dann geht es um Identität, Rechte, Delegation, Protokollierung und die Frage, wer für welche Aktion gerade eigentlich geradesteht.

Für Nicht-Spezialisten: NIST ist die US-Behörde, die technische Standards, Leitlinien und Praxisprojekte für Industrie und Verwaltung vorbereitet. Wenn NIST bei KI-Agenten nicht nur über Modellrisiken spricht, sondern über Identifizierung, Authentisierung, Autorisierung und Auditspuren, ist das ein Signal an IT-Organisationen: Agenten werden gerade vom Experiment zum normalen Betriebsobjekt. Wer sie produktiv einsetzen will, braucht also dieselbe Disziplin wie bei anderen privilegierten Systemen.

Genau diese Verschiebung wird in den aktuellen NIST-Veröffentlichungen deutlich. Im Januar sammelte CAISI zunächst Rückmeldungen zu Sicherheitsrisiken von AI-Agent-Systemen. Im Februar folgte die AI Agent Standards Initiative. Und im Mai legte NIST dann eine Auswertung der RFI-Antworten vor, in der Sicherheitsbedenken ausdrücklich als Adoptionsbremse beschrieben werden. Parallel dazu treibt das NCCoE ein eigenes Konzeptpapier voran, das nicht bei abstrakter Agentensicherheit stehen bleibt, sondern sehr konkret nach Agenten-Identität, starken Authentisierungsverfahren, Least Privilege, delegierten Rechten, Logging und Prompt-Injection-Folgen fragt.

Warum NIST die Debatte gerade vom Modell zur Identität schiebt

Die Kernbotschaft aus den NIST-Quellen ist ziemlich klar: Klassische Cybersicherheitsprinzipien gelten weiter, reichen für Agenten aber nicht unverändert. Das Mai-Papier fasst die Rückmeldungen so zusammen, dass KI-Agenten neue Sicherheitsrisiken mitbringen und diese Risiken die Einführung real bremsen. Das ist wichtig, weil hier nicht nur ein einzelner Anbieter auf Produktmarketing umschaltet, sondern weil eine Standardisierungsinstanz den Markt praktisch darauf hinweist, dass Agenten ohne neue Kontrollen kein belastbares Betriebsmodell ergeben.

Besonders interessant ist, dass NIST das Thema nicht auf Prompt Injection verengt. In der Januaranfrage tauchen zwar indirekte Prompt Injections, Datenvergiftung und fehlgeleitete Agenten explizit auf. Gleichzeitig fragt die Behörde aber auch nach Messverfahren, nach Begrenzung von Agentenzugriffen in produktiven Umgebungen und nach Methoden, mit denen sich Agenten in Entwicklung und Betrieb absichern lassen. Das ist für IT-Leitungen die eigentlich spannende Stelle: Die Debatte wird von "Wie clever ist das Modell?" zu "Welche technische und organisatorische Hülle braucht dieses System, damit es überhaupt sicher arbeiten darf?" verschoben.

Das Konzeptpapier des NCCoE macht daraus ein umsetzungsnahes Arbeitsprogramm. Dort steht nicht nur, dass Agenten produktiver werden können, sondern auch, dass dieser Nutzen ohne Identifizierung, Authentisierung und Autorisierung nicht belastbar zu heben ist. Noch wichtiger: NIST fragt dort sehr konkret nach Metadaten für Agentenidentitäten, nach Schlüsselmanagement, nach Zero-Trust-Prinzipien für Agentenrechte, nach "on behalf of"-Delegation und nach der Bindung zwischen menschlicher und nicht-menschlicher Identität bei Human-in-the-loop-Freigaben. Genau das sind keine Zukunftsfragen mehr, sondern Betriebsfragen für heute.

Aus Assistenten werden privilegierte Ausführungsschichten

Viele Teams behandeln Agenten aktuell noch wie einen besseren Chatbot mit API-Zugriff. Das ist bequem, aber gefährlich. Ein Agent, der Termine verschiebt, Freigaben vorbereitet, Security-Daten zusammenzieht oder Deployments begleitet, ist kein neutraler Zuschauer mehr. Er wird zu einer Ausführungsschicht mit eigener Reichweite. NIST beschreibt diese Reichweite bewusst als Identitäts- und Autorisierungsproblem, nicht nur als Promptproblem. Das ist der richtige Blick, denn die größten Schäden entstehen im Betrieb oft nicht dadurch, dass ein Agent einen Satz falsch formuliert, sondern dadurch, dass er mit den falschen Rechten im falschen Kontext auf echte Systeme zugreift.

Spannend ist dabei der Bezug auf MCP. Das Konzeptpapier nennt Model Context Protocol ausdrücklich als relevantes Protokoll und verknüpft es mit OAuth und OpenID Connect. Damit wird ein Punkt offiziell greifbar, den viele Plattformteams seit Monaten spüren: Sobald Agenten über standardisierte Toolpfade auf Datenquellen, Services und Aktionen zugreifen, müssen diese Pfade auch als Identitäts- und Berechtigungspfad gedacht werden. MCP ist dann nicht nur Integrationskomfort, sondern ein Zugangssystem. Wer es ohne saubere Rechtevergabe, ohne Delegationslogik und ohne nachvollziehbare Token-Pfade aufzieht, öffnet sich eine neue privilegierte Innenverbindung ins Unternehmen.

Das Konzeptpapier geht deshalb folgerichtig über einfache Access-Checks hinaus. Es nennt auch Logging, Transparenz, Datenfluss-Nachweise und nicht-abstreitbare Zuordnung von Agentenaktionen. Für ITSM, Security Operations und Plattformbetrieb ist das eine direkte Übersetzung in bekannte Disziplinen. Ein produktiver Agent braucht Inventar, Zweck, Rechte, Lebenszyklus, Auditspur und einen sauberen Entzugspfad. Kurz: Er darf nicht als graue Zwischenrolle zwischen Nutzerkonto, Servicekonto und Toolplugin herumfliegen.

Was das für IT-Management und Governance jetzt ändert

Der eigentliche Fortschritt in den NIST-Papieren liegt also nicht in einem einzelnen Kontrollmechanismus, sondern im Betriebsmodell. Agenten sollen in Zukunft als identifizierbare, steuerbare und protokollierbare Akteure behandelbar sein. Das zwingt Organisationen zu ein paar unangenehmen, aber fälligen Entscheidungen. Erstens müssen sie klarmachen, ob ein Agent eine eigene Identität bekommt oder nur verdeckt über Menschen oder Backend-Dienste mitläuft. Zweitens müssen sie definieren, wann ein Agent autonom handeln darf und wann eine delegierte Freigabe mit Rückbindung an eine menschliche Identität nötig ist. Drittens müssen sie Agentenzugriffe so protokollieren, dass später nicht nur das Ergebnis, sondern auch Absicht, Kontext und verwendete Datenquellen nachvollziehbar bleiben.

Genau hier wird auch sichtbar, warum klassische IAM- und Zero-Trust-Bausteine plötzlich wieder im Mittelpunkt stehen. NIST nennt im Konzeptpapier unter anderem OAuth 2.x, OpenID Connect, SPIFFE/SPIRE, SCIM und NGAC als relevante Standards oder Muster. Das ist kein Zufall. Diese Werkzeuge helfen nicht dabei, Agenten intelligenter zu machen. Sie helfen dabei, Agenten beherrschbar zu machen. Und das ist für produktive Einführung oft die wichtigere Leistung.

Für viele Unternehmen ist das auch eine unangenehme Wahrheit. Sie wollten Agenten zunächst als schnellen Produktivitätshebel testen, ohne ihre Identitäts- und Berechtigungsarchitektur anzufassen. Genau diese Abkürzung verliert gerade an Glaubwürdigkeit. Wenn ein Agent auf Kalender, CRM, Wissensbasis, Fileshare, Ticketing und interne APIs zugreift, dann ist er aus Governance-Sicht kein nettes Frontend mehr, sondern ein zusammengesetzter Zugriffsträger. Ohne klare Rechtegrenzen wird daraus sehr leicht ein Nebenaccount mit zu viel Macht, zu wenig Nachweis und unklarer Verantwortlichkeit.

Die praktische Lehre für laufende Agentenprojekte

Aus ITSM-Sicht ist die Konsequenz recht direkt. Agentenprojekte sollten nicht mehr nur als Use-Case- oder Modellvorhaben gesteuert werden. Sie brauchen von Anfang an ein kleines Betriebsdossier: Zweck, Owner, angebundene Systeme, Delegationslogik, erlaubte Aktionen, Logging, Abschaltpfad und Review-Zyklus. Wer das erst nach dem Pilot baut, hat den schwierigsten Teil der Arbeit nach hinten verschoben.

Ebenso wichtig ist die Trennung zwischen menschlicher und nicht-menschlicher Autorität. NIST fragt zu Recht danach, wie sich menschliche Identität mit Agentenidentität bei Freigaben verbinden lässt. Genau daran werden viele echte Rollouts hängen. Ein Agent darf nicht einfach deshalb mehr dürfen, weil er in einer nützlichen Oberfläche steckt. Er braucht nachprüfbare, entziehbare und kontextgebundene Rechte. Und wenn er im Namen eines Menschen handelt, muss diese Delegation sichtbar und widerrufbar sein.

Der Markt bewegt sich damit weg von der Frage, ob Agenten "irgendwie funktionieren", hin zu der Frage, ob sie sich sauber in Identitäts-, Zugriffs- und Nachweislogiken einhängen lassen. Das ist keine theoretische Feinheit. Es ist wahrscheinlich die Voraussetzung dafür, dass Agentic AI in Unternehmen nicht als Dauerpilot endet. NIST macht damit gerade sehr deutlich: Wer Agenten produktiv will, muss sie zuerst als kontrollierbare Akteure behandeln. Alles andere bleibt ein Versuch mit zu viel Vertrauen und zu wenig Betrieb.

Quellen

• NIST / CAISI: Request for Information About Securing AI Agent Systems, 12.01.2026
• NIST / CAISI: AI Agent Standards Initiative, 17.02.2026
• NIST NCCoE: Accelerating the Adoption of Software and AI Agent Identity and Authorization, Februar 2026
• NIST: Summary Analysis of Responses to the Request for Information Regarding Security Considerations for AI Agents, 18.05.2026