Agenten regieren — nicht nur ausführen lassen.

Warum Agenten Governance brauchen

Ein LLM, das Tools aufruft, ist kein Agent — es ist eine Pipeline. Ein Agent ist eine Pipeline plus die Erlaubnis, eigenständig zu entscheiden, welcher Tool-Call als Nächstes kommt. Genau diese Eigenständigkeit ist der Punkt, an dem Compliance, Audit und Risikomanagement andocken müssen. Wer einen Agenten ohne Permission-Scope deployt, bekommt einen schnellen ersten Erfolg und einen unhaltbaren Audit-Befund im Quartal danach.

Sechs Säulen der Agent Governance

• Tenant-Scope — jeder Run-Token ist an (tenant_id, agent_id, run_id) gebunden. Cross-Tenant-Reads werden auf DB-Ebene durch RLS verworfen, nicht nur durch App-Logik.
• Permission-Vocabulary — eine einheitliche Capability-Sprache (graph:read, graph:propose, evidence:write, integration:write:ticket, ...) statt ad-hoc Boolean-Flags pro Agent.
• Approval-Gates — der Orchestrator suspendiert den Run am Gate, persistiert den Zustand, und resumed auf approved, rejected oder timeout. SLA-Bewachung pro Gate.
• Risk-Budgets — jeder Run hat Token-, Tool-Call-, Wall-Clock- und Money-Budget. Über-Budget-Runs werden gekillt mit agent.run.budget_exceeded event.
• Trace + Replay — jeder Step (plan, tool_call, llm_call, proposal, escalation, approval, commit) wird in agent_runs.tool_calls persistiert. SHA-keyed Payloads ermöglichen Replay ohne PII-Re-Materialisierung.
• Meta-Agent — die Agent-Governance-Agentin beobachtet alle anderen Agents, flaggt Eskalations-Raten, Approval-Quoten und Tool-Call-Loops, und kann individuelle Agents pausieren.

Trust-Stufen

Agenten haben drei mögliche Trust-Stufen. Read-only Agents dürfen lesen und vorschlagen — niemals committen. Propose-with-approval Agents dürfen Mutations-PRs in den Graph oder in externe Systeme (Jira, GitHub) entwerfen, brauchen aber eine menschliche Bestätigung. Auto-commit Agents (bisher nur Evidence-Generation für nicht-PII-Inhalte) dürfen ohne Mensch in der Loop committen, aber jede Aktion ist signiert und in der Hash-Chain verankert.

Wenn Agenten miteinander reden

Agenten können andere Agenten triggern via orchestrator.chain(target_agent, payload). Chains haben eine maximale Tiefe (default 4) und ein Budget von 16 Agent-Runs pro Chain. Beispiel-Kette nach einem kritischen Policy-Violation-Event:

• Runtime Telemetry Agent erkennt das Event
• → AI Risk Classification Agent re-klassifiziert die Usecase
• → Evidence Generation Agent sealed einen Snapshot
• → Remediation Agent öffnet Jira + Slack-Alert
• → Workflow Engine startet den Incident-Workflow

Der Meta-Agent beobachtet die Chain. Überschreitet ein Agent sein Tool-Call-Budget, wird die ganze Chain pausiert. Der Orchestrator bietet ein UI, in dem der zuständige DPO die Chain manuell weiter durchwinken oder abbrechen kann.

Kill-Switch + Forensik

Jeder Agent kann individuell von der Plattform-Seite und vom Tenant-Owner pausiert werden. Pausierung gilt sofort: bereits laufende Runs werden mit outcome=cancelledbeendet, neue Trigger landen in der Deferred-Queue. Forensik ist über die Trace persistent: Prompt-Hash + Completion-Hash + Tool-Output-Hash lassen sich aus S3 re-materialisieren, solange die Retention nicht abgelaufen ist (default 90 Tage, konfigurierbar).

Was bewusst nicht passiert

Agenten genehmigen keine Hochrisiko-AI-Systeme. Sie produzieren auch keine AVV-Verträge automatisch und schreiben keine DPIA-Inhalte ohne menschlichen Review. Diese Trennung ist nicht technisch limitiert, sondern bewusst gesetzt: Rechtsakte und Compliance-Entscheidungen müssen von einem identifizierbaren Menschen mit Auditspur verantwortet werden.