AI Agent Governance: Fünf Säulen, die Sie bauen, nicht schreiben

Was Agent Governance tatsächlich steuert

Jane, eine Support-Ingenieurin, gibt einen einzigen Satz in einen Support-Copilot ein: Erstelle eine Rückerstattungszusammenfassung für Ticket #4521. Der Copilot übergibt die Anfrage an einen Planner Agent, der wiederum einen Research Agent (Zendesk-Ticket, verknüpfter Jira-Bug) und einen Billing Agent (Stripe-Zahlungsdatensatz) aufruft. Eine menschliche Anfrage führt zu sechs Machine-to-Machine-Aufrufen, die größtenteils von Software initiiert wurden, die eigenständig entschieden hat, weitere Software aufzurufen.

Kette — User → Application → Agent → Sub-Agent → MCP Tool — ist der Agentic Call Path, und genau diesen muss AI Governance steuern. Jedes Zugriffmodell in Unternehmen basiert auf drei Annahmen: Ein Benutzer steht am Anfang der Anfrage, das aufrufende Element ist dieser Benutzer, und der Umfang entspricht dem, worin der Benutzer eingewilligt hat. Beim dritten Hop sind alle drei Annahmen falsch, sodass drei Fragen unbeantwortet bleiben:

• Für wen ist dieser Aufruf? Der Benutzer hat sich vor drei Hops authentifiziert. Ist seine Identität noch in der Anfrage enthalten oder wurde sie durch einen Service Account ersetzt?
• Wer führt ihn aus? Ein Bearer-Token weist den Besitz einer Anmeldeinformation nach, nicht aber, welcher Ihrer zweihundert Agenten sie hält.
• Was darf er tun? Ein Token, das für den ersten Aufgerufenen ausgestellt wurde, ist für jeden nachfolgenden Aufgerufenen überprivilegiert.

Diese drei Fragen bei jedem Hop mit Nachweisen zu beantworten, ist die Aufgabe von Agentic AI Governance – fünf Systeme, nicht bloß ein Absatz über verantwortungsvolle Nutzung.

Der Agent ist eine dritte Art von Principal

Die meisten Teams greifen auf eine von zwei Abkürzungen zurück: Der Agent leitet das Token des Benutzers weiter oder erhält einen gemeinsamen Service Account. Beide Ansätze sind falsch, da ein Agent keines von beidem ist.

Jedem Agenten eine eigene verifizierbare Identität zuzuweisen, ist die zentrale Entscheidung, von der alles Weitere abhängt. Sie ermöglicht Attribution, da der Empfänger erkennen kann, welcher Agent aufgerufen hat; agentenspezifische Richtlinien, da Janes Copilot, der Jira liest, und ihr Engineering Agent, der in Jira schreibt, unterschiedliche Principals sind, obwohl beide für Jane handeln; und keine anonymen Agenten, da ein Tool, das nur über eine registrierte Identität erreichbar ist, die Registrierung zum Enforcement Point macht.

Die Dringlichkeit ist unscheinbar, aber hoch: Maschinenidentitäten übersteigen die Zahl menschlicher Benutzer in den meisten Unternehmen bereits um mehr als das 40-fache, und Agenten vervielfachen sich schneller als Service Accounts je zuvor – jeder mit einem Framework und einem API-Key kann einen erstellen.

Die fünf Säulen

Vollständige Governance besteht aus fünf Fähigkeiten in einem geschlossenen Kreislauf. Die ersten beiden laufen ab, bevor ein Agent auch nur einen einzigen Aufruf tätigt, die mittleren zwei bei jedem Aufruf, die letzte kontinuierlich – mit Rückmeldung an die zweite Säule.

In Säule 4 trifft Governance auf die Praxis. Bei jedem Hop löst das Gateway den Aufrufer auf, prüft, ob dieser Agent dieses Ziel aufrufen und im Auftrag dieses Benutzers handeln darf, stellt ein neues Token aus, das genau auf den nächsten Aufgerufenen zugeschnitten ist, führt Guardrails aus, leitet die Anfrage weiter und zeichnet sie auf. Drei Eigenschaften ergeben sich daraus automatisch: Attribution pro Hop, Least-Privilege-Tokens (ein kompromittiertes Token gilt nur für einen Aufgerufenen und einen Gültigkeitsbereich) und zentrale Widerrufbarkeit.

Warum das Gateway und nicht der IdP?

Jede Säule könnte in einem anderen Tool angesiedelt sein. Was das Modell zusammenhält, ist die Durchsetzung an einem Gateway im Call Path – der einzigen Komponente, die jeden Hop unabhängig von Framework oder Cloud sieht, die Identität weiterreicht, die Berechtigungen bei jedem Schritt einschränkt und plattformneutral ist. Entra verwaltet Entra-Agenten, Okta verwaltet Okta-Apps, Bedrock verwaltet Bedrock-Agenten; das Gateway steuert den Pfad über all diese Systeme hinweg, wo die eigentlichen Risiken liegen – ein Punkt, den wir im Artikel über Governing AI Agents Across Multiple Platforms vertiefen. Ein Identity Provider ohne Gateway stellt perfekte Anmeldeinformationen aus, die anschließend wahllos weitergeleitet werden; eine Registry ohne Gateway ist bloße Dokumentation.

Wo Teams Fehler machen

Die Registry als reine Tabellenkalkulation betrachten. Eine Registry, die von Agenten ignoriert werden kann, erfasst nur diejenigen Agenten, von denen Sie ohnehin schon wussten. Sie entfaltet ihre Wirkung erst, wenn sie der Engpass ist: Keine registrierte Identität, kein Aufruf.

Ein einziges mächtiges Token überallhin weiterleiten. Der schnellste Weg, Aufrufe funktionsfähig zu machen, und zugleich der schnellste Weg zu einer Sicherheitsverletzung. Agenten können per Prompt-Injection dazu gebracht werden, beliebige Anmeldeinformationen zu missbrauchen. Daher darf deren Umfang niemals größer sein, als es der nächste Aufruf erfordert.

Konten statt gesamter Ketten überprüfen. Drei Agenten in einem Beschaffungsprozess – einer erstellt Lieferantendaten, einer liest Bankdaten von Lieferanten, einer veranlasst Zahlungen – wirken isoliert betrachtet akzeptabel. Miteinander verkettet bilden sie jedoch einen Zahlungspfad, den kein Prüfer genehmigt hätte: Funktionstrennung (Separation of Duties), durch Software ausgehebelt.

Annehmen, dass der Scope eines Agenten statisch ist. Ein Finanz-Agent, dem Zugriff auf ein neues ERP-Modul gewährt wird, beginnt möglicherweise mit Daten zu arbeiten, die ursprünglich nie von seinem Scope abgedeckt waren – nicht aufgrund eines Fehlers, sondern weil Anpassungsfähigkeit die Natur von Agenten ist. Das Verhalten muss kontinuierlich mit den definierten Befugnissen verglichen werden, nicht nur quartalsweise.

Möchten Sie dies als laufendes System statt als Diagramm umsetzen?

Registrieren Sie einen Agenten, weisen Sie ihm eine Identität zu und gewähren Sie ihm Zugriff auf einen MCP-Server.

Kostenlos starten

Der schwierige Teil: Zwei Antworten auf „Wer hat das getan?“

Wenn der Research Agent Janes Jira-Tickets liest, lautet die ehrliche Antwort auf Wer hat das getan? sowohl Jane als auch der Research Agent. Wenn Sie eines von beidem weglassen, geht ein wesentlicher Teil der Information verloren. Es gibt zwei Möglichkeiten, dies in einem Token zu transportieren – und diese Wahl entscheidet darüber, ob Sie überhaupt einen nutzbaren Audit-Trail haben.

Für Agenten ist Delegation fast immer die richtige Wahl. Das delegierte Token behält den Benutzer als sub bei und benennt den Ausführenden in act; verkettete Aufrufe verschachteln die Claims, wobei der äußerste den jüngsten Ausführenden darstellt:

Zwei zusammengehörige Claims teilen sich die Aufgabe. may_act ist das vorausschauende Gate – darf dieser Ausführende für dieses Subjekt handeln –, das vor der Token-Ausstellung geprüft wird. act zeichnet auf, wer tatsächlich gehandelt hat. Die Autorisierung erfolgt auf Basis des aktuellen Ausführenden plus Subjekt plus Richtlinie; die verschachtelte Kette bleibt für die Forensik erhalten.

Der zugrundeliegende Mechanismus ist der Token Exchange. RFC 8693 definiert ihn: Ein Subject-Token und optional ein Actor-Token vorlegen und ein neues Token erhalten, das auf eine Ziel-Audience zugeschnitten ist. Anbieter nennen dies On-Behalf-Of. Eine Eigenschaft ist besonders wichtig: Ein Token Exchange erweitert niemals die Befugnisse. Das ausgestellte Token gewährt die Schnittmenge dessen, was der Benutzer tun darf, was der Agent tun darf und was das Ziel akzeptiert, sodass jeder Hop stärker eingeschränkt ist als der vorherige. Über Vertrauensdomänen hinweg übernimmt der ID-JAG-Grant der IETF (Oktas Cross App Access), der ein kurzlebiges Grant bei Ihrem IdP ausstellt, das vom eigenen Authorization Server des Ziels eingelöst wird.

Wie das in TrueFoundry funktioniert

TrueFoundry bildet die fünf Säulen auf Produktfunktionen ab. Transparenz über den aktuellen Funktionsumfang ist wichtiger als eine vollkommen wirkende Tabelle, daher wird die Verfügbarkeit ehrlich ausgewiesen.

Die Registry

Jeder Agent erhält einen Eintrag, unabhängig davon, worauf er läuft – Bedrock, Vertex, LangGraph, ein eigener HTTP-Dienst, ein A2A-Agent oder ein Copilot in der SaaS-Lösung eines Drittanbieters. Nichts muss verschoben oder umgeschrieben werden.

Die Registrierung erfolgt über einen Assistenten mit vier Schritten: Metadata, Agent Identity, Config, Access Control.

Identität

Der zweite Schritt bestimmt, wie der Agent seine Identität nachweist. TrueFoundry-backed bedeutet, dass TrueFoundry das Token ausstellt und signiert – der Standard für selbst betriebene Agenten. Identity provider-backed bedeutet, dass der Agent ein Token von Okta, Entra, einem beliebigen OIDC-Provider oder einem SPIFFE/SPIRE-Endpunkt vorlegt, wobei die Claim-Werte dem Agenten zugeordnet werden.

Der Config-Schritt legt fest, ob das Agent Gateway vorgeschaltet wird. Proxy via Gateway bedeutet, dass Aufrufer eine TrueFoundry-URL ansteuern und das Gateway authentifiziert, durchsetzt sowie weiterleitet. Embedded steht für eine reine Governance-Einbindung: eine Identität und Berechtigungen ohne eingehendes Proxying. So steuern Sie einen Copiloten innerhalb eines Drittanbieter-Produkts – Sie können dessen Eingang nicht kontrollieren, aber seine ausgehenden Aufrufe passieren weiterhin Ihre Gateways.

Agent Access Control

Zugriff basiert auf einer Allowlist; es gibt keine Deny-Einstellung, da das Fehlen eines Eintrags die Verweigerung darstellt. Collaborator können Benutzer, Teams oder andere Agenten sein, jeweils mit der Rolle Agent Manager (Anzeigen und Bearbeiten) oder Agent Access (Ausführen und im Auftrag handeln lassen). Der Owner ist ein separates, optionales Feld, das einem Team zugewiesen werden muss – der Anker für die Verantwortlichkeit.

Beachten Sie die Wirkung dieser einen Liste: Sie definiert sowohl, wer den Agenten aufrufen darf, als auch, in wessen Auftrag der Agent handeln kann. Die Zuweisung an das vordefinierte Team „Everyone“ verleiht dem Agenten mandantenweite Delegationsrechte – mehr als die meisten Agenten benötigen.

Die Gegenrichtung funktioniert identisch: Fügen Sie den Agenten als Collaborator zu jedem MCP-Server oder Modell hinzu (Subjekt agent:<name>), im selben Auswahlfeld wie für Benutzer und Teams.

Um einen Agenten auf eine Teilmenge der Tools eines Servers zu beschränken, konfigurieren Sie diese Teilmenge als Virtual MCP Server und gewähren Sie stattdessen darauf Zugriff. Eine feingliedrigere Tool-Einschränkung pro Agent innerhalb der Berechtigung folgt in Kürze.

Guardrails bei jedem Hop

Zugriffskontrollen entscheiden darüber, ob ein Aufruf stattfindet. Guardrails entscheiden darüber, was er enthalten darf, und sind unabhängig davon, wer aufruft. Agenten erhöhen das Risiko aus einem einfachen Grund: Ein Chatbot mit einer schlechten Antwort ist peinlich, ein Agent mit einer schlechten Antwort führt sie aus. Jedes Tool-Ergebnis fließt erneut in den Kontext des Modells ein und kann eine Injection enthalten, weshalb Eingaben auch bei vertrauenswürdigen Benutzern geprüft werden müssen.

Eine solide Basis: PII-Schwärzung (personenbezogene Daten) und Prompt-Injection-Erkennung bei LLM-Eingaben, Secrets-Erkennung bei Ausgaben, SQL-Sanitizer und Code-Safety-Linter vor der Tool-Ausführung sowie Schwärzungen nach der Ausführung. Starten Sie jede Regel zunächst im Audit-Modus, bevor Sie sie aktivieren – ein blockierter Hop kann die gesamte Kette unterbrechen.

Audit

Da Durchsetzung und Überwachung an derselben Stelle stattfinden, ist der Audit-Trail konstruktionsbedingt vollständig. Jeder Trace zeichnet auf, welcher Agent den Aufruf getätigt hat und für welchen Benutzer er gehandelt hat – beide Teile der zwei Antworten auf die Urheberfrage.

Jede ausgeführte Guardrail erscheint als eigener Span: Was geprüft wurde, ob der Test erfolgreich war, was gefunden oder geschwärzt wurde. Blockierte Anfragen werden ebenfalls protokolliert – ein verweigerter Hop ist ein Nachweis, keine Lücke.

Über den Traces fasst ein Dashboard alle registrierten Agenten zusammen, unabhängig davon, wo sie laufen: Anzahl der Anfragen, Latenz-Perzentile, Fehlerraten, Nutzung im Zeitverlauf. Drift Detection und Anomalie-Benachrichtigungen bauen darauf auf und stehen demnächst zur Verfügung.

Ein praktisches Beispiel

Steuerung des Rückerstattungs-Copiloten vom Anfang dieses Beitrags.

Agenten registrieren. Planner, Research und Billing erhalten jeweils einen Eintrag mit Beschreibung und einem Owner-Team. Der Drittanbieter-Copilot wird als Embedded registriert – keine URL, reine Governance, aber seine ausgehenden Aufrufe werden ab sofort gesteuert.

Jedem Agenten eine Identität zuweisen. TrueFoundry-backed für die drei selbst betriebenen Agenten; der Embedded-Copilot verweist auf Ihren IdP mit zugewiesenem Claim-Wert.

Least Privilege in beide Richtungen gewähren. Fügen Sie beim Research Agent das Support-Team mit Agent Access hinzu – dies regelt, wer ihn aufrufen darf und in wessen Auftrag er handeln kann. Fügen Sie dann agent:research-agent als Collaborator zu den Zendesk- und Jira-MCP-Servern hinzu und sonst nirgendwo. Billing erhält Zugriff auf Stripe. Keiner der Agenten kann auf die Tools des anderen zugreifen, da das Fehlen einer Berechtigung zu einem 403-Fehler führt.

Identität bei jedem Aufruf mitführen. Ein delegierter Aufruf überträgt zwei Bearer-Tokens: den Benutzer im Authorization-Header, den Agenten im x-tfy-agent-authorization-Header. Jeder Agent fügt seinen eigenen Agenten-Header ein und leitet das Benutzer-Token weiter, sodass das Gateway jeden Hop gegen den aktuell aufrufenden Agenten prüft.

Guardrails aktivieren und überwachen. Verknüpfen Sie Prompt-Injection-Erkennung mit den Modellen und Post-Tool-Schwärzung mit den Servern. Überprüfen Sie anschließend in den Request Traces, dass ein Aufruf des Research Agents den research-agent als Aufrufer und Jane als den Benutzer ausweist, in dessen Auftrag gehandelt wurde.

Einschränkung im aktuellen Stand: Derzeit wird das Benutzer-Token zusammen mit dem Agenten-Header weitergeleitet, anstatt bei jedem Hop gegen ein neues Token mit passender Audience eingetauscht zu werden. Ein vollständiger Exchange pro Hop wird demnächst verfügbar sein.

Bereit, einen Agenten hinter einen echten Durchsetzungspunkt zu stellen?

Registrieren Sie ihn, beschränken Sie den Scope auf einen MCP-Server und analysieren Sie den Trace.

Kostenlos starten auf TrueFoundry

Fallstricke, die Sie kennen sollten

Ein Agent kann keinen OAuth2 Authorization Code Flow durchlaufen. Es gibt keinen Menschen, der den Zustimmungsbildschirm bestätigen könnte, und das Token würde ohnehin dieser Person gehören. Ein solcher Server gibt MCP server authentication required für ein Agenten-Token zurück, selbst wenn der Agent als Collaborator eingetragen ist. Verwenden Sie stattdessen Client Credentials.

Output Guardrails werden bei gestreamten Antworten übersprungen. Zur Auswertung wird die vollständige Antwort benötigt. Für Agentenschritte, deren Ausgabe in einen Tool-Aufruf fließt, sollte daher stream: false bevorzugt werden.

Das Token des Agenten repräsentiert den Agenten. Halten Sie es fern von Quellcodeverwaltung und allen Inhalten, die vom Modell ausgelesen werden können. Ein Agent, der per Prompt dazu gebracht werden kann, sein eigenes Token preiszugeben, kann impersoniert werden.

Verwandte Artikel

• Governing AI Agents Across Multiple Platforms – Wenn Governance an den Grenzen der jeweiligen Plattform endet
• Graph Engineering for AI Agents – Bewertung von Knoten versus Steuerung von Kanten
• MCP Access Control with an MCP Gateway – Berechtigungen auf Tool- und Server-Ebene
• RBAC vs ABAC for AI Agents – Das Zugriffsmodell hinter den Berechtigungen
• Building an AI Governance Framework – Die übergeordnete strategische Perspektive

Fazit

Die meisten Publikationen zum Thema Enterprise AI Agent Management behandeln Governance als rein dokumentarische Aufgabe: Richtlinien zur angemessenen Nutzung definieren, ein Komitee benennen, den Standard veröffentlichen. Nichts davon hält dem dritten Hop eines Call Paths stand, bei dem die Frage nicht lautet, ob eine Aktion angemessen war, sondern ob Ihre Infrastruktur nachweisen kann, wer sie ausgeführt hat.

Die fünf Säulen sind genau deshalb wertvoll, weil jede einzelne ein konkretes System beschreibt statt eines bloßen Prinzips. Discovery ist ein Scanner. Registration ist eine Datenbank, die das Gateway nicht umgehen lässt. Authentication sind zwei Anmeldeinformationen in einer Anfrage. Authorization ist eine Berechtigung, die bei Fehlen einen 403-Fehler zurückgibt. Audit ist ein Trace, der sowohl den Agenten als auch den Benutzer ausweist. Wenn Sie diese Systeme aufbauen, hat die entscheidende Frage – Wer hat das getan und in wessen Auftrag? – eine klare und nachvollziehbare Antwort.

Steuern Sie Ihren ersten Agenten auf TrueFoundry

Kostenlos testen