Identität von KI-Agenten: Kontrolle ohne Skalierung zu bremsen

KI-Agenten skalieren nur mit Identität, Grenzen und Nachweisen für jede Aktion. Wenn ein Agent Daten liest, Systeme abfragt, Datensätze verändert oder Abläufe startet, ist er nicht länger nur eine Sprachschnittstelle. Er agiert als nicht menschliche Identität innerhalb des Unternehmens.

Dieser Wandel erfordert die Überprüfung einer verbreiteten Annahme: Anwendungsberechtigungen reichen nicht aus, um Autonomie zu steuern. Ein Agent kann eine legitime Anfrage erhalten und während der Ausführung auf bösartige Anweisungen in E-Mails, Dokumenten, Webseiten oder Tickets stoßen. Er kann zudem Daten aus unterschiedlichen Quellen kombinieren und eine Aktion auslösen, die keines der isolierten Systeme ausdrücklich autorisiert hätte.

Das Thema hat zuletzt deutlich an technischer Relevanz gewonnen. Im Februar 2026 veröffentlichte NIST einen spezifischen Vorschlag zu Identifizierung, Authentifizierung, Autorisierung, Delegation und Nichtabstreitbarkeit für Software- und KI-Agenten. Im Mai stellte Google Cloud Agentenidentitäten als eigenständigen Principal-Typ vor, getrennt von Nutzern und Servicekonten. Auch OWASP zählt den Missbrauch von Identität und Privilegien zu den kritischsten Risiken agentischer Anwendungen. NIST, 2026 (nccoe.nist.gov) Google Cloud, 2026 (cloud.google.com) OWASP, 2026 (genai.owasp.org)

Was ist die Identität von KI-Agenten und warum muss sie getrennt sein?

Die Identität von KI-Agenten ist der überprüfbare Nachweis, der einen Agenten von Personen, generischen Anwendungen und anderen Agenten unterscheidet. Sie muss technische und operative Attribute enthalten: Eigentümer, Umgebung, Zweck, verwendetes Modell, zulässige Tools, Codeherkunft, Risikostufe und Lebenszyklus.

Ein wiederkehrender Fehler besteht darin, den Agenten mit einem weitreichenden Servicekonto oder, schlimmer noch, mit dem permanenten Token eines Nutzers auszuführen. Das reduziert den anfänglichen Aufwand, beseitigt aber die Accountability. Nach einem Vorfall weiß das Team, dass eine Berechtigung eine Aktion ausgeführt hat, kann jedoch grundlegende Fragen nicht beantworten: Welcher Agent hat sie verwendet, mit welchem Ziel, in welchem Kontext und im Auftrag von wem?

Eine eigene Identität schafft eine klare Trennung der Verantwortlichkeiten. Der Nutzer bleibt die Instanz, die eine Aufgabe anfordert. Der Agent wird zur Instanz, die sie ausführt. Das Tool oder die API ist die geschützte Ressource. Diese Differenzierung ermöglicht unterschiedliche Richtlinien für jede Beziehung.

Das Glossar hilft, das Design zu präzisieren:

• Nicht menschliche Identität: Identität von Software, Service, Bot oder Agent, die auf Ressourcen zugreift, ohne eine Person zu sein.
• Delegation: Temporäre Autorisierung für den Agenten, im Namen eines Nutzers oder Prozesses zu handeln.
• Attestierung: Kryptografischer Nachweis, dass die Workload tatsächlich die behauptete Identität besitzt und in der erwarteten Umgebung ausgeführt wird.
• Nichtabstreitbarkeit: Fähigkeit, nachträglich nachzuweisen, welche Identität eine Aktion mit welcher Autorisierung vorgenommen hat.

Die Trennung verhindert zudem, dass der Agent wie ein Corporate Chat mit uneingeschränktem Zugriff behandelt wird. Ein Assistent, der Dokumente zusammenfasst, hat ein anderes Risikoprofil als ein Agent, der Preise ändert, Rückerstattungen genehmigt oder Tickets für Lieferanten eröffnet. Die Identität muss diesen Unterschied bereits bei der Registrierung ausdrücken.

Welche Zugriffsentscheidungen müssen bei jeder Aktion getroffen werden?

Die Autorisierung muss die konkrete Aktion bewerten, nicht nur die bei der Installation gewährte Berechtigung. In traditionellen Systemen erhält eine Anwendung Scopes und verwendet sie relativ vorhersehbar. Bei Agenten verändert sich der Ausführungspfad abhängig von Aufgabe, abgerufenem Kontext und verfügbaren Tools.

Deshalb muss die Zugriffsentscheidung mindestens sieben Signale berücksichtigen: Identität des Agenten, delegierender Nutzer oder Prozess, angeforderte Ressource, beabsichtigte Aktion, betroffene Daten, Umgebung und Transaktionsrisiko. Ein Support-Agent kann die Historie eines Kunden abfragen. Das bedeutet nicht, dass er die gesamte Kontaktdatenbank exportieren oder kommerzielle Konditionen ändern darf.

Dieses Modell wird als kontextbezogene Autorisierung bezeichnet. Es kombiniert RBAC, also rollenbasierte Zugriffskontrolle, mit ABAC, also attributbasierter Zugriffskontrolle. RBAC legt eine einfache Grundlage fest, etwa „Support-Agent“. ABAC ergänzt Bedingungen: Region des Kunden, Datenklassifizierung, Uhrzeit, finanzieller Wert, Ursprungskanal und Vertrauensniveau der Sitzung.

Die aktuelle Dokumentation von Microsoft empfiehlt, die Autorisierung des Nutzers beizubehalten, wenn der Agent auf Tickets, Dateien, E-Mails oder Kundendatensätze zugreift. Das delegierte Zugriffsmuster eignet sich besser, wenn ein authentifizierter Nutzer vorhanden ist; ausschließlicher Anwendungszugriff sollte auf klar abgegrenzte und auditierbare Backoffice-Aufgaben beschränkt bleiben. Microsoft Learn, 2026 (learn.microsoft.com)

In der Praxis sollte die Richtlinienfrage nicht lauten: „Darf der Agent das CRM nutzen?“ Sie muss lauten: „Darf dieser Agent für diesen Nutzer in dieser Aufgabe diesen Datensatz lesen und diese Aktion jetzt ausführen?“ Der Unterschied wirkt semantisch. Er ist ein Architekturunterschied.

Wie lässt sich das Prinzip minimaler Privilegien anwenden, wenn der Agent den nächsten Schritt bestimmt?

Minimale Privilegien für Agenten bedeuten, nur den Zugriff zu gewähren, der für den nächsten überprüfbaren Schritt erforderlich ist. Es bedeutet nicht, einen umfassenden Berechtigungssatz bereitzustellen, weil der Ablauf ihn möglicherweise irgendwann benötigt.

Der sicherste Weg zur Anwendung dieses Prinzips besteht darin, permanente Berechtigungen durch kurzlebige, spezifische und widerrufbare Tokens zu ersetzen. Jeder Token muss nach Tool, Ressource, Aktion und Laufzeit begrenzt sein. Ein Agent, der einen Entwurf für ein Angebot erstellen soll, kann Lesezugriff auf freigegebene Kundendaten und Schreibzugriff ausschließlich auf ein Entwurfs-Repository erhalten. Er benötigt keine Berechtigung, das Dokument zu versenden, einen Rabatt anzuwenden oder den Stammdatensatz zu aktualisieren.

Auch die Segmentierung von Tools nach Kritikalität ist sinnvoll. Organisieren Sie sie in vier Gruppen:

1. Abfrage mit geringer Auswirkung: Artikel, Bestellstatus und öffentliche Dokumentation abrufen.
2. Sensible Abfrage: Auf Verträge, Finanzdaten, HR-Informationen oder personenbezogene Daten zugreifen.
3. Umkehrbare Aktion: Entwürfe erstellen, Tickets eröffnen, Änderungen vorschlagen und nicht kritische Felder aktualisieren.
4. Materielle Aktion: Zahlungen senden, Daten löschen, Preise ändern, Berechtigungen anpassen oder externe Verpflichtungen eingehen.

Die Gruppen drei und vier erfordern zusätzliche Richtlinien. Für materielle Aktionen nutzen Sie eine Just-in-Time-Freigabe oder JIT: Die Berechtigung wird nur für diese Entscheidung, zu diesem Zeitpunkt und mit engem Scope erteilt. Der Nutzer oder Manager „gibt dem Agenten keinen Zugriff“; er genehmigt eine deklarierte Aktion.

Das verringert die Auswirkungen von zwei häufigen Risiken. Das erste ist indirekte Prompt-Injection, bei der externe Inhalte versuchen, den Agenten umzulenken. Das zweite ist Tool-Missbrauch, bei dem eine scheinbar harmlose Anweisung zu einer Aktion außerhalb der ursprünglichen Absicht führt. OWASP weist darauf hin, dass der Missbrauch von Identität und Privilegien eine der größten Lücken zwischen Risikoschwere und organisatorischer Vorbereitung aufweist. (genai.owasp.org)

Wo sollte die Richtlinie liegen: im Prompt, im Agenten oder in der Infrastruktur?

Die Autorisierungsrichtlinie muss außerhalb des Prompts durchgesetzt und vor der Ausführung eines Tools validiert werden. Prompts steuern Verhalten. Sie sind keine Zugriffskontrollen. Ein Modell kann eine Anweisung falsch interpretieren, widersprüchlichen Kontext erhalten oder durch externe Inhalte manipuliert werden. Die Entscheidung, eine Transaktion zuzulassen, muss in einer deterministischen Ebene liegen.

Eine ausgereifte Architektur hat fünf Kontrollpunkte. Der erste ist das Inventar: Jeder Agent, jedes Tool, jeder MCP-Server, jede Integration und jede Berechtigung muss bekannt sein. MCP oder Model Context Protocol ist ein Protokoll zur Verbindung von Modellen und Agenten mit Tools und Kontextquellen. Es kann Integrationen beschleunigen, vervielfacht jedoch auch die Zugriffsfläche.

Der zweite Punkt ist der Identity Provider. Er stellt Berechtigungen für Nutzer, Agenten und Workloads aus und validiert sie. Der dritte ist die Policy Engine, die Attribute bewertet und eine Entscheidung zum Zulassen, Ablehnen oder Anfordern einer Freigabe trifft. Der vierte ist ein Tool-Gateway, das Aufrufe an APIs, Datenbanken, SaaS-Systeme und Automatisierungen abfängt. Der fünfte ist die Observability-Ebene, die Absicht, Kontext, Entscheidung, Ausführung und Ergebnis aufzeichnet.

Der empfohlene Ablauf ist einfach:

1. Der Nutzer oder Prozess startet eine Aufgabe.
2. Der Agent erhält eine eigene Identität und eine begrenzte Delegation.
3. Vor jedem Tool-Aufruf sendet das Gateway die Attribute an die Policy Engine.
4. Die Richtlinie erlaubt, verweigert oder fordert eine zusätzliche Freigabe.
5. Das Ereignis wird mit einer Korrelation zwischen Nutzer, Agent, Tool und Ressource gespeichert.

NIST hebt genau diese Bereiche hervor: Identifizierung, Authentifizierung, dynamische Autorisierung, Delegation, Aktionsprotokollierung und Nachverfolgbarkeit der Herkunft von Daten und Prompts. (nccoe.nist.gov) Die praktische Konsequenz ist klar: Sicherheit muss die Ausführung begleiten, nicht nur das anfängliche Provisioning.

Welche Nachweise sind erforderlich, um einen Agenten in Produktion zu auditieren?

Ein hilfreicher Audit-Trail muss die vollständige Entscheidungskette rekonstruieren, nicht nur API-Aufrufe auflisten. Herkömmliche Logs erfassen, dass ein Endpoint aufgerufen wurde. Für Agenten reicht das nicht aus. Es muss nachvollziehbar sein, warum die Aktion getroffen wurde und welche Einschränkungen galten.

Jedes relevante Ereignis muss eine Korrelations-ID enthalten. Diese ID verknüpft die ursprüngliche Anfrage, den delegierenden Nutzer, die Agentenversion, das Modell, die abgerufenen Dokumente, den Aktionsplan, die aufgerufenen Tools, die Richtlinienentscheidungen und die endgültige Antwort.

Protokollieren Sie auch Versionen. Das Verhalten eines Agenten kann sich durch Änderungen am System-Prompt, Modell, Speicher, Tool oder an der Richtlinie verändern. Ohne Versionierung ist es schwierig, Vorfälle zu vergleichen, und unmöglich, einen Fehler einer bestimmten Änderung zuzuordnen.

Es gibt einen wichtigen Unterschied zwischen Ausführungs-Telemetrie und Kontrollnachweis. Telemetrie zeigt Latenz, Aufrufvolumen, Fehlerrate und Kosten. Ein Kontrollnachweis belegt, dass eine Aktion gemäß der geltenden Richtlinie autorisiert wurde. Unternehmen benötigen beides.

Definieren Sie Kennzahlen, die Governance mit dem Betrieb verbinden: Anteil inventarisierter Agenten, Anzahl ungenutzter Berechtigungen, Volumen abgelehnter Aktionen, Freigaben nach Risikokategorie, Zugriffsversuche außerhalb des Scope, Zeit bis zum Widerruf von Berechtigungen und Log-Abdeckung pro Tool. Diese Kennzahlen zeigen, ob die Organisation Autonomie steuert oder lediglich ihre Ausweitung beobachtet.

Wie lässt sich die Identität von Agenten implementieren, ohne den Betrieb zu lähmen?

Die Implementierung sollte mit den Agenten beginnen, die bereits auf kritische Systeme zugreifen, und nicht mit einer idealisierten Plattform. Das anfängliche Ziel besteht darin, reale Exposition zu reduzieren und wiederverwendbare Standards zu schaffen.

Beginnen Sie mit einem 30-Tage-Inventar. Erfassen Sie Agenten in Produktion, Prototypen mit Zugriff auf reale Daten, Automatisierungsintegrationen, von Agenten verwendete Servicekonten, MCP-Tools sowie in Vaults oder Umgebungsvariablen gespeicherte Berechtigungen. Klassifizieren Sie jedes Element nach Autonomie, abgerufenen Daten und Auswirkung seiner Aktionen.

Wählen Sie anschließend einen Ablauf mit hohem Wert und kontrollierbarem Risiko. Geeignete Kandidaten sind Ticket-Triage, Angebotserstellung, Konsolidierung von Kennzahlen oder unterstützte Aktualisierung von Stammdaten. Beginnen Sie nicht mit Zahlungen, Datenlöschung, administrativen Berechtigungen oder regulatorischen Entscheidungen.

Erstellen Sie für diesen Ablauf eine exklusive Agentenidentität, kurzlebige Tokens, Scopes pro Tool und JIT-Freigabe für materielle Aktionen. Implementieren Sie anschließend die Korrelationsprotokollierung und simulieren Sie Fehler: eine bösartige Anweisung in einem Dokument, einen abgelaufenen Token, einen Leseversuch außerhalb des Scope, ein nicht verfügbares Tool und eine Kontextänderung während der Ausführung.

Die Ausweitung muss über Standards erfolgen, nicht über improvisierte Kopien. Ein internes Verzeichnis von Agenten, freigegebenen Tools, Richtlinienvorlagen und Mindestanforderungen an Logging reduziert Abweichungen zwischen Teams. Orchestrierungsplattformen wie Centriu können die operative Transparenz bündeln, sofern die Autorisierung weiterhin durch unabhängige und überprüfbare Kontrollen durchgesetzt wird.

Das angestrebte Ergebnis ist nicht, Agenten am Handeln zu hindern. Es besteht darin, dass jede Aktion eine Identität, eine explizite Autorität, eine technische Grenze und einen abrufbaren Nachweis hat. Das ist die Grundlage, um Automatisierung in nachhaltige operative Fähigkeit zu verwandeln.