Der Konstruktionsfehler: Agent = geliehener Mensch
In den meisten Agenten-Pilotprojekten entsteht die Rechtevergabe pragmatisch: Ein Entwickler braucht schnell Zugriff auf CRM, Ticket-System und Zahlungsdienst, nimmt sein eigenes Token oder einen bereits existierenden Service-Account, und der Agent läuft damit los. Das Projekt funktioniert — bis zur ersten Frage aus dem Audit oder der ersten Rechnungsverarbeitung, die aus dem Ruder läuft.
Das Muster ist immer dasselbe: Der agentische Prozess bekommt keine eigene Identität, sondern erbt eine fremde. Drei Varianten sind in freier Wildbahn verbreitet, und alle drei haben denselben Kernfehler.
Variante 1: Admin-Token geliehen
Der Agent nutzt das persönliche Zugangstoken eines Administrators oder Entwicklers, weil das am schnellsten geht. Der Agent kann dann alles, was dieser Mensch kann — inklusive Rechten, die seine Aufgabe nie braucht. Ein Agent, der Support-Tickets zusammenfasst, hat plötzlich Schreibzugriff auf die Produktionsdatenbank, weil der Admin-Account den hat.
Variante 2: Geteilter Service-Account
Etwas disziplinierter, aber strukturell gleich problematisch: Ein technischer Account wird für „die Agenten" angelegt und von mehreren Agenten oder mehreren Instanzen gleichzeitig genutzt. Das Geheimnis ist dauerhaft, der Rechteumfang statisch, und im Log lässt sich nicht mehr rekonstruieren, welcher Agent oder welcher Lauf eine bestimmte Aktion ausgelöst hat.
Variante 3: API-Key im Environment, nie rotiert
Der API-Key liegt seit dem Projektstart in einer Konfigurationsdatei oder Umgebungsvariable, hat volle Scopes „damit nichts bricht" und wird nie ausgetauscht. Kompromittiert er einmal — etwa über eine Log-Datei oder einen kompromittierten MCP-Server —, bleibt er es, bis jemand händisch eingreift.
Der gemeinsame Nenner: In allen drei Fällen ist der Rechteumfang des Agenten identisch mit dem Rechteumfang der Person oder des Systems, von dem er das Credential geliehen hat — nicht mit dem, was seine tatsächliche Aufgabe erfordert. Genau das ist das Gegenteil von Zero Trust.
Warum das im Audit durchfällt
Ein Auditor — ob intern, extern für ISO 27001 oder im Rahmen eines Cyber-Versicherungs-Audits — stellt bei jeder Zugriffsprüfung dieselben Fragen: Wer hat wann worauf zugegriffen? War der Zugriff notwendig für die Aufgabe? Lässt sich der Zugriff einer eindeutigen, verantwortlichen Identität zuordnen?
Bei geliehenen Admin-Tokens oder geteilten Service-Accounts lassen sich diese drei Fragen nicht sauber beantworten. Das Log zeigt den Namen des Administrators oder eines generischen Accounts, nicht den des Agenten. Ehrlich: Die meisten Mittelständler bemerken das erst, wenn der Auditor genau danach fragt — und dann hilft keine nachträgliche Dokumentation, weil die Daten im Log schlicht fehlen.
Im Schadensfall wird aus dem Dokumentationsproblem ein Ermittlungsproblem. Wenn ein Agent versehentlich 40 statt 4 Rückerstattungen auslöst oder ein manipulierter Datensatz eine Kette von Aktionen anstößt, muss forensisch rekonstruierbar sein: Welcher Lauf, welches Werkzeug, welcher Parameter, welche Entscheidung. Mit einem geteilten Konto ist diese Rekonstruktion bestenfalls eine Vermutung.
In der Praxis: Ein Versicherer oder Auditor fragt nach einem Sicherheitsvorfall zuerst nach der Kette „Identität → Aktion → Zeitpunkt → Entscheidung". Kann ein Unternehmen diese Kette für einen KI-Agenten nicht liefern, wird der Agent faktisch wie eine ungeprüfte Blackbox behandelt — mit entsprechenden Konsequenzen für die Deckung.
Der Agent als eigener Principal
Die Lösung ist konzeptionell einfach, auch wenn die Umsetzung sauberes Identitätsmanagement voraussetzt: Der Agent bekommt eine eigene Identität — einen eigenständigen Principal mit eigener Kennung, eigenem Rechteumfang und eigener Spur im Audit-Log, getrennt von der Identität des Menschen, der den Lauf ausgelöst hat.
Das bedeutet nicht, jeden Agenten manuell im Identity Provider anzulegen und zu pflegen. Es bedeutet, dass die Plattform, auf der Agenten laufen, für jeden Agent-Typ oder sogar jeden Lauf ein eigenes, maschinenlesbares Identitäts-Objekt führt — angebunden an den vorhandenen Identity Provider (Entra ID, Keycloak oder ein anderes OIDC-fähiges System), nicht daneben.
Eigene Scopes statt geerbter Rechte
Jeder Agent bekommt nur die Scopes, die seine konkrete Aufgabe erfordert — nicht die des Systems, über das er angebunden ist. Ein Rechnungsverarbeitungs-Agent braucht Lesezugriff auf Belege und Schreibzugriff auf ein Buchungssystem, aber keinen Zugriff auf Personalakten oder Produktionsdatenbanken, selbst wenn dieselbe Infrastruktur beides technisch erreichen könnte.
Kurzlebige Tokens statt dauerhafter Geheimnisse
Statt eines API-Keys, der Monate oder Jahre gültig ist, bekommt der Agent ein Credential, das für einen einzelnen Lauf ausgestellt wird und nach wenigen Minuten verfällt. Ein gestohlenes Token ist damit ein kurzes Zeitfenster, kein dauerhaftes Einfallstor.
OAuth 2.1 mit Resource Indicators (RFC 8707)
Der technische Kern ist ein Standard, der ursprünglich nicht für Agenten gedacht war, aber genau ihr Problem löst: Nach RFC 8707 (Resource Indicators for OAuth 2.0) gibt der Agent beim Anfordern eines Tokens explizit an, für welches Zielsystem (welche Audience) es gelten soll. Das ausgestellte Token ist dann an genau dieses Ziel gebunden — bei jedem anderen Dienst ist es wertlos, selbst wenn es dort abgefangen wird. In Kombination mit OAuth 2.1, das unter anderem PKCE verpflichtend macht und unsichere Grant-Typen entfernt, ergibt sich ein Autorisierungsfluss, der für kurzlebige, maschinelle Principals gebaut ist statt für menschliche Login-Sessions.
Token-Austausch statt Weitergabe
Ein zweiter wichtiger Baustein: Wenn ein Agent im Auftrag eines Nutzers handelt, bekommt er nicht dessen Token weitergereicht (Token Passthrough), sondern tauscht es über einen definierten Vorgang (Token Exchange) gegen ein eigenes, auf seine Aufgabe zugeschnittenes Token. Das trennt zwei Kontexte, die sonst leicht verschwimmen: die delegierten Rechte des Nutzers, in dessen Auftrag der Agent handelt, und die eigenen Rechte des Agenten als System. Ohne diese Trennung erbt der Agent implizit alles, was der Nutzer darf — inklusive Rechten, die für die konkrete Aufgabe nie gebraucht werden.
Policy-Entscheid je Tool-Call, nicht je Sitzung
Eigene Identität und kurzlebige Tokens lösen die Frage „Wer ist der Agent?". Sie lösen nicht die Frage „Was darf er in diesem einen Moment tun?". Dafür braucht es eine zweite Schicht: eine Policy Engine, die nicht einmal pro Sitzung, sondern bei jedem einzelnen Tool-Call neu entscheidet.
Der Unterschied ist mehr als technische Feinheit. Eine Freigabe pro Sitzung bedeutet: Ist der Agent einmal autorisiert, kann er innerhalb dieser Sitzung beliebig oft und beliebig viel tun. Eine Freigabe pro Tool-Call bedeutet: Jede einzelne Aktion wird gegen aktuelle Grenzen geprüft — Betragsgrenzen, Scopes, Zeitfenster, Freigabeschwellen.
- Betragsgrenzen: Ein Refund-Agent darf bis zu einer definierten Summe selbstständig erstatten, darüber greift eine Freigabe.
- Scopes je Aufruf: Nicht jeder Agent mit „Lese"-Recht darf automatisch auch schreiben — die Policy prüft das Werkzeug, nicht nur den Agenten.
- Zeitfenster: Manche Aktionen sind nur innerhalb der Geschäftszeiten oder außerhalb von Wartungsfenstern erlaubt.
- Freigabeschwellen: Ab einem definierten Risiko oder Betrag wechselt die Aktion von „automatisch erlaubt" zu „wartet auf Mensch".
Entscheidend ist, dass diese Regeln als versionierte, testbare Konfiguration existieren — nicht als Textabschnitt im System-Prompt. Eine Policy-Datei lässt sich in Git versionieren, in einem Review begutachten, automatisiert testen und im Streitfall als Beleg vorlegen. Ein Satz im Prompt lässt sich das alles nicht.
Warum Regeln im Prompt keine Sicherheitsgrenze sind
Der naheliegende, aber unzureichende Ansatz lautet: „Wir schreiben einfach ins System-Prompt, dass der Agent maximal 250 Euro erstatten darf." Das Problem ist nicht die Absicht, sondern die Durchsetzbarkeit. Ein System-Prompt ist eine Bitte an das Modell — keine Bedingung, die unabhängig vom Modellverhalten geprüft wird.
Genau hier setzt Prompt Injection an: Eine manipulierte Werkzeugantwort, ein präpariertes Dokument oder eine kompromittierte Datenquelle kann dem Modell eine andere Anweisung unterschieben, die im Kontext plausibel aussieht. Ein Modell, das eine im System-Prompt formulierte Grenze „vergisst" oder überredet wird, sie zu ignorieren, verletzt keine Regel im technischen Sinn — es folgt einfach dem, was gerade im Kontext steht.
Eine Regel in der Policy Engine hat dieses Problem nicht, weil sie unabhängig vom Modell geprüft wird: Der Tool-Call mit Betrag über 250 Euro wird von der Engine blockiert oder in die Freigabe geschickt, unabhängig davon, was das Modell „glaubt" oder welchen Text es gerade verarbeitet hat. Die Grenze liegt außerhalb der Reichweite der Injection — das ist der entscheidende Unterschied zwischen einer Bitte und einer Bedingung.
Ehrlich: Damit ist Prompt Injection nicht gelöst — weder bei uns noch anderswo. Was sich lösen lässt, ist der Schaden, den eine erfolgreiche Injection anrichten kann. Wenn die Policy-Grenze unabhängig vom Prompt greift, bleibt eine Injection ein ärgerlicher, aber begrenzter Vorfall statt eines unbegrenzten.
Sandboxing und Egress-Allowlists
Identität und Policy regeln, wer etwas darf. Sandboxing regelt, was technisch überhaupt möglich ist, selbst wenn Identität oder Policy versagen sollten. Beide Schichten zusammen ergeben Verteidigung in der Tiefe.
- Isolierte Ausführung: Jeder nicht selbst gebaute MCP-Server läuft in einem eigenen Container ohne Zugriff auf das Dateisystem des Hosts, ohne Zugangsdaten anderer Werkzeuge, mit begrenztem Speicher und begrenzter Laufzeit.
- Egress-Allowlist: Ausgehende Verbindungen sind grundsätzlich blockiert. Erlaubt sind nur namentlich gelistete Ziele mit Port. Ein Datenabfluss über einen kompromittierten Konnektor wird damit zur sichtbaren Konfigurationsänderung, nicht zum stillen Vorfall.
- Daten sind keine Anweisungen: Rückgaben von Werkzeugen werden als nicht vertrauenswürdig markiert und in einen separaten Kontextbereich gelegt, statt Verhalten umzudefinieren.
- Gepinnte Versionen: Externe MCP-Server laufen auf einer geprüften, festgelegten Version. Ein Update ist eine bewusste, erneut geprüfte Entscheidung, kein automatischer Vorgang im Hintergrund.
Diese Maßnahmen adressieren einen Teil dessen, was in der wachsenden agentischen Lieferkette an Angriffsfläche entsteht — von kompromittierten Paketen bis zu gefälschten Werkzeug-Beschreibungen. Details zu Auswahl, Herkunftsprüfung und Versionierung von MCP-Servern in Produktion behandelt der Artikel MCP in Produktion: Tool-Gateway, die Risiken der Lieferkette selbst der Artikel Agentische Lieferkette und Supply-Chain-Risiken. Wie Prompt Injection und Schatten-KI im Alltag konkret aussehen, zeigt der bestehende Artikel KI-Agenten-Sicherheit: Schatten-KI, Prompt Injection und MCP.
Praxisbeispiel: Der Refund-Agent mit 250-Euro-Limit
Ein konkreter Ablauf macht das Zusammenspiel greifbar. Rechenbeispiel, Annahme: Ein Agent bearbeitet Rückerstattungsanfragen aus dem Support-Postfach eines Online-Shops.
- Der Agent-Lauf startet mit einer eigenen Identität und fordert beim Token-Service ein Credential mit Audience „billing-api" und Scope „write:refund" an — gültig für zehn Minuten.
- Ein Nutzer verlangt die Erstattung einer Bestellung über 180 Euro. Der Agent prüft die Bestellung, ruft
stripe.refundmit Betrag, Währung und Bestell-ID auf. - Die Policy Engine prüft: Scope vorhanden, Betrag unter 250 Euro, Währung EUR, Bestell-ID gehört zum aktuellen Lauf. Alle Bedingungen erfüllt — die Aktion wird ausgeführt.
- Ein zweiter Fall verlangt eine Erstattung über 480 Euro. Dieselbe Policy erkennt: Betrag über der Grenze. Der Aufruf geht nicht an das Zahlungssystem, sondern in eine Freigabe-Warteschlange.
- Ein berechtigter Mitarbeiter sieht Kontext, Betrag und Begründung, prüft kurz und genehmigt oder lehnt ab. Diese Entscheidung — wer, wann, mit welchem Ergebnis — wird mit dem Agenten-Lauf verknüpft im Audit-Log festgehalten.
- Erst nach positiver Freigabe führt der Agent die Erstattung aus, mit demselben Credential-Umfang wie im ersten Fall.
Das Ergebnis: Im Audit-Log steht nicht „Admin-Account hat 480 Euro erstattet", sondern die vollständige Kette — welcher Agent, welcher Lauf, welche Policy-Entscheidung, welcher Mensch hat wann freigegeben. Genau diese Kette fehlt bei geliehenen Admin-Tokens vollständig. Wie sich Freigabeprozesse, Warteschlangen und Eskalationsstufen strukturiert aufbauen lassen, vertieft der Artikel Human-in-the-Loop: Freigaben und Limits.
Vergleich: Admin-Token, Service-Account, Agent Identity
| Kriterium | Geteilter Admin-Token | Service-Account je System | Agent Identity mit Policy-Gate |
|---|---|---|---|
| Rechteumfang | Alles, was der Admin darf | Statisch, oft breiter als nötig | Minimal, je Aufgabe modelliert |
| Lebensdauer | Dauerhaft, selten rotiert | Dauerhaft bis manuelle Rotation | Minuten, je Lauf neu ausgestellt |
| Zuordenbarkeit im Log | Zeigt Admin, nicht Agent | Zeigt Account, nicht Lauf/Agent | Eindeutig je Lauf und Agent |
| Entscheidungsgranularität | Keine — technisch alles möglich | Keine — statischer Scope | Je Tool-Call, versioniert |
| Widerruf bei Auffälligkeit | Betrifft alle Systeme des Admins | Betrifft alle Nutzer des Accounts | Betrifft nur den einen Agenten |
| Audit-/ISO-27001-Tauglichkeit | Fällt regelmäßig durch | Bedingt, mit Vorbehalten | Grundlage erfüllt |
Wann sich das nicht lohnt / Grenzen von Agent Identity
Agent Identity und Policy-Gate sind kein Ersatz für gesunden Menschenverstand bei der Frage, ob ein Agent überhaupt Aktionsrechte braucht. Für einen rein lesenden Recherche-Agenten ohne Schreibzugriff ist der Aufwand einer vollständigen Identitäts- und Policy-Schicht oft unverhältnismäßig — hier reicht ein eng gefasster, schreibgeschützter Lesezugriff über einen kurzlebigen Token ohne komplexes Freigabe-Regelwerk.
Auch für Einzelentwickler-Prototypen ohne Produktionsanspruch lohnt sich der volle Ausbau nicht sofort. Die meisten Mittelständler bauen die Identitäts- und Policy-Schicht erst mit dem Schritt von Prototyp zu Produktivbetrieb auf — dazu mehr im Artikel Vom Prototyp in Produktion in 90 Tagen, sobald verfügbar. Wichtig ist, diesen Schritt bewusst zu gehen und nicht erst nachzuholen, wenn bereits ein Vorfall oder ein Audit ansteht.
Grenze, die bleibt: Identität ersetzt keine fachliche Prüfung. Ein Agent mit korrektem Scope und eingehaltenem Betragslimit kann trotzdem eine im Rahmen seiner Rechte liegende, aber fachlich falsche Entscheidung treffen — etwa einen berechtigten, aber unpassenden Refund. Dafür braucht es weiterhin fachliche Tests, Stichprobenkontrollen und, wo die Auswirkung relevant ist, eine Freigabe durch einen Menschen. Identität und Policy begrenzen den Schaden, sie beurteilen nicht die Qualität der Entscheidung.
Häufige Fragen zu Agent Identity
Warum ist es ein Problem, wenn der Agent mit einem Admin-Token läuft?
Weil der Schadensradius im Fehlerfall dem des Administrators entspricht, nicht dem der eigentlichen Aufgabe. Ein Refund-Agent mit Admin-Rechten kann theoretisch Nutzer löschen, Preise ändern oder Datenbanken lesen — Fähigkeiten, die seine Aufgabe nie braucht. Im Audit ist zudem nicht unterscheidbar, ob ein Mensch oder der Agent gehandelt hat.
Reicht ein geteilter Service-Account nicht auch aus?
Ein geteilter Service-Account löst das Rechteproblem nicht, nur das Namensproblem. Er hat weiterhin einen dauerhaften Rechteumfang, ein langlebiges Geheimnis und keine Bindung an einen einzelnen Lauf. Bei mehreren Agenten oder Instanzen lässt sich im Log nicht mehr trennen, welcher Agent welche Aktion ausgelöst hat.
Was bedeutet OAuth 2.1 mit Resource Indicators für Agenten konkret?
Nach RFC 8707 gibt der Agent beim Anfordern eines Tokens das Zielsystem (die Audience) explizit an. Das ausgestellte Token gilt nur für dieses eine Zielsystem und ist bei jedem anderen Dienst wertlos — selbst wenn es dort abgefangen wird. Kombiniert mit kurzer Lebensdauer entsteht ein Credential, das je Lauf ausgestellt und danach automatisch ungültig ist.
Warum ist eine Regel im Prompt keine Sicherheitsgrenze?
Weil ein Prompt eine Bitte an das Modell ist, keine erzwingbare Bedingung. Ein manipuliertes Dokument oder eine präparierte Werkzeugantwort kann dem Modell eine andere Anweisung unterschieben — die Bitte im System-Prompt kann es dann ignorieren. Eine Regel in der Policy Engine prüft dagegen jeden Tool-Call unabhängig vom Modellverhalten und lässt sich nicht wegargumentieren.
Wie läuft eine Freigabe ab, wenn ein Agent ein Limit überschreitet?
Die Policy Engine erkennt die Überschreitung vor der Ausführung und leitet den Fall an eine Freigabe-Warteschlange statt an das Zielsystem. Ein berechtigter Mensch sieht Kontext, Betrag und Begründung, entscheidet, und die Entscheidung wird mit Zeitstempel und Identität im Audit-Log festgehalten. Der Agent führt erst nach positiver Freigabe aus.
Was kostet die Einführung von Agent Identity in der Praxis?
Rechenbeispiel, keine Preisliste: Bei HostSpezial liegt der Betrieb einer Agentenplattform inklusive Identitäts- und Policy-Schicht je nach Ausbaustufe bei 690, 1.490 oder ab 3.900 Euro Betriebspauschale pro Monat zzgl. USt., dazu nutzungsabhängige Komponenten je Lauf und je Tool-Call. Der eigentliche Aufwand liegt meist nicht in der Lizenz, sondern in der sauberen Modellierung der Scopes je Agent.
Ersetzt Agent Identity die fachliche Prüfung der Agentenlogik?
Nein. Identität und Policy begrenzen, was ein Agent technisch tun kann — sie prüfen nicht, ob eine im Rahmen seiner Rechte liegende Entscheidung fachlich richtig ist. Ein Agent mit korrektem Scope kann trotzdem einen falschen, aber erlaubten Refund auslösen. Dafür braucht es weiterhin fachliche Tests, Stichproben und im Zweifel Human-in-the-Loop.
Einordnung: Wo Agent Identity in der Plattform sitzt
Agent Identity ist keine isolierte Maßnahme, sondern eine von fünf Schichten einer produktionsreifen Agentic-AI-Infrastruktur. Einen Überblick über alle Schichten und die interaktive Einordnung, welche Schicht für welchen Anwendungsfall greift, zeigt die Systemkarte auf der Übersichtsseite. Wie Identität und Policy technisch mit Laufzeitumgebung, Orchestrierung und Nachvollziehbarkeit zusammenspielen, zeigen die Seiten Architektur und Observability. Wer direkt loslegen will, findet den praktischen Einstieg unter Quickstart.
Wie sich das mit bestehenden IT-Landschaften verzahnt — etwa mit vorhandenem Identity Provider, Ticket-System und ERP —, behandelt der Artikel Agentic AI Systemintegration. Wer On-Premise-Modelle betreibt, findet ergänzend im Artikel On-Premise-KI mit vLLM die passende Laufzeitumgebung für die hier beschriebene Identitäts- und Policy-Schicht.
Für Unternehmen, die eine Agentenplattform nicht selbst aufbauen wollen, liefert KI Managed Services Identitäts- und Policy-Schicht als Betriebsleistung, wahlweise ergänzt um On-Premise-Betrieb für Unternehmen mit strengeren Datenresidenz-Anforderungen. Einen vollständigen End-to-End-Ansatz von Modell bis Agentenbetrieb zeigt KI Full Stack Providing.