Agent Governance: Kontrolle und Steuerung von KI-Agenten in Production

Idee in 30 Sekunden

Agent governance ist eine Kontrollschicht über der Runtime, die jeden Agenten-Schritt prüft: Zugriff auf Tools, Limits, Budgets und Policy-Entscheidungen vor der Ausführung von Aktionen.

Wann das nötig ist: wenn der Agent Zugriff auf Tools, APIs hat oder reale Aktionen in Production ausführt.

Problem

Ohne governance wirkt ein Agent in Production oft "fast normal", bis ein Ausfall passiert. Er kann Tools vielfach aufrufen, Budget ohne Fortschritt verbrauchen und Aktionen ausführen, die niemand explizit erlaubt hat.

Das Gefährlichste: Das ist nicht sofort sichtbar. Von außen läuft der Run noch, innen wachsen bereits Risiken, Kosten und Log-Rauschen. Ohne governance ist ein Agent eine unkontrollierte Schleife mit Tool-Zugriff.

Analogie: Das ist wie ein Autopilot im Auto ohne Geschwindigkeitslimit, Bremsen und Ereignisprotokoll. Solange die Straße gerade ist, wirkt alles gut. Wenn etwas schiefgeht, ist Stoppen und Verstehen deutlich schwerer.

Genau dafür braucht man governance: damit das System Grenzen vor dem Incident hat, nicht erst danach.

Lösung

Die Lösung ist, in die Runtime eine eigene Policy Layer einzubauen, die vor jeder Aktion eine technische Entscheidung trifft. Die Policy Layer trifft eine von drei Entscheidungen: allow, deny oder approval_required. Das ist ein separater System-Layer und nicht Teil von Prompt oder Modelllogik. Wie bei RBAC laufen diese Prüfungen vor jeder Agentenaktion.

Governance ist das, was zwischen Agent und echten Aktionen steht. Mit anderen Worten: der Control Plane für KI-Agenten.

👉 Governance zwingt den Agenten nicht zu "richtigem" Verhalten, sondern begrenzt, was er überhaupt tun darf.

Umgesetzt wird das als Middleware / Policy Layer (zum Beispiel in LangGraph oder in einem eigenen Tool Gateway). In diesem Artikel ist die Policy Layer (Tool Gateway) die Komponente, die alle Tool-Aufrufe prüft und steuert.

Governance != Safety

Das sind zwei verschiedene Kontroll-Ebenen:

• Safety: ob der Agent die richtige Entscheidung vorschlägt.
• Governance: ob der Agent diese Aktion in Runtime ausführen darf.

Wenn Safety sich irrt, begrenzt Governance den Schaden trotzdem auf Runtime-Ebene.

Beispiel

Ein Support-Agent ohne governance kann durch Halluzination die Refund API dutzende Male aufrufen.

Mit governance:

• max_tool_calls = 3
• max_usd = 100 → der Agent stoppt beim Limit, nicht erst beim Geldverlust.

Governance stoppt den Incident auf Ausführungsebene und verlässt sich nicht darauf, dass das Modell sich korrekt verhält.

Kontroll-Ebenen (governance layers)

Diese Ebenen arbeiten bei jedem Agenten-Schritt zusammen.

Beispiel für einen Alert:

Slack alert: 🛑 Agent Support-Bot hit max_usd limit ($100). Run stopped at step 12.

In Production sieht das meist wie ein Dashboard mit Metriken aus: runs, tool calls, cost, errors.

So sieht das in der Architektur aus

Agent governance wird zwischen Agent Runtime und Außenwelt eingebaut:

Kein Tool call wird ausgeführt, ohne durch die Policy Layer zu gehen.

Die Policy Layer (Tool Gateway) agiert als Gateway / Middleware zwischen Runtime und Tools.

Jeder Tool-Aufruf geht durch:

• Policy Layer -> Zugriff- und Limit-Prüfung
• Execution -> Ausführung nur bei allow
• Logs -> Eintrag in audit / trace

Minimaler Governance-Stack

• allowlist (default deny) — begrenzt Tool-Zugriff
• max_steps — stoppt Schleifen
• Budgets — begrenzen Kosten
• retry policy — verhindert Retry-Chaos
• audit logs — ermöglichen Incident-Analyse
• stop reasons — erklären, warum der Agent gestoppt wurde
• kill switch — erlaubt Not-Stopp während eines Incidents

Das ist das Minimum, ohne das ein Agent kein Production-System ist.

Beispiel

Agent ruft ein Tool auf:

• allowlist wird geprüft
• RBAC wird geprüft
• Budget wird geprüft
• Approval wird geprüft

→ erst danach wird die Aktion ausgeführt.

Minimaler Policy-Flow:

if not policy.allow(tool, args):
    return deny("tool_not_allowed")
if not limits.steps_ok():
    return stop("max_steps_exceeded")
if not budget.ok():
    return stop("budget_exceeded")
result = tool.execute(args)
audit.log(tool, args, result)
return result

Typische Fehler

• sich nur auf Prompt verlassen statt auf Runtime-Kontrolle
• keine zentrale Policy Layer
• keine default-deny allowlist
• keine Budgets und Limits
• Retry-Logik über mehrere Layer verteilt
• fehlende audit logs
• keine Möglichkeit, den Agenten zu stoppen

Als Ergebnis wirkt das System kontrolliert, ist es aber nicht.

Selbst-Check

Schneller Check vor Production-Start:

FAQ

Q: Warum kann governance nicht durch einen einzigen System-Prompt ersetzt werden?
A: Der Prompt beschreibt gewünschtes Verhalten. Governance erzwingt reale Aktionsgrenzen in Runtime.

Q: Was ist das Minimum an governance vor Production?
A: Minimum: default-deny allowlist, Limits (max_steps, Budgets), stop reason, audit logs und kill switch. Ohne das bleibt der Agent unter Last unkontrolliert.

Q: Was zuerst einführen: approval oder budgets?
A: Zuerst Runtime-Limits und Budgets, damit das Basisrisiko pro Run sofort begrenzt ist. Danach approval für riskante und irreversible Aktionen (write-Operationen, Finanzänderungen, Datenlöschung).

Q: Reicht ein kill switch für Sicherheit aus?
A: Nein. Kill switch ist die Notbremse, ersetzt aber keine dauerhafte Zugriffskontrolle, Budgets, rate limits und Auditierung von Aktionen.

Q: Wie wird kill switch technisch umgesetzt?
A: Meist als simples globales Flag (zum Beispiel in Redis), das die Policy Layer vor jedem Schritt prüft und die Ausführung stoppt.

Verwandte Seiten

Weiter zum Thema:

• Access Control (RBAC) — wie man begrenzt, was der Agent tun darf.
• Budget Controls — wie man Token-, Tool-Call- und Dollar-Kosten begrenzt.
• Rate Limiting für Agenten — Schutz vor Tool-Spam und Lastspitzen.
• Human approval — wo menschliche Bestätigung für kritische Aktionen nötig ist.
• Audit Logs für Agenten — wie man Ereignisketten rekonstruiert und Incidents analysiert.