Runtime Governance for AI Agents: Policies on Paths

Diese Arbeit stellt einen formalen Rahmen für die Laufzeit-Steuerung von KI-Agenten vor, der Compliance-Richtlinien als deterministische Funktionen definiert, die den Agentenpfad bewerten, um so die Grenzen statischer Ansätze wie Systemprompts zu überwinden und den Balanceakt zwischen Aufgabenerfolg und Risikominimierung zu ermöglichen.

Das Wesentliche

Das große Problem: Der unvorhersehbare Assistent

Stellen Sie sich vor, Sie stellen einen neuen, extrem intelligenten Assistenten ein. Dieser Assistent ist kein starrer Roboter, der nur fest programmierte Befehle ausführt. Er ist wie ein kreativer Koch, dem Sie sagen: „Mach mir ein leckeres Abendessen."

• Der alte Weg (Software): Früher waren Computer wie ein Fließband. Schritt 1: Tomate schneiden. Schritt 2: Zwiebeln hacken. Schritt 3: Braten. Es gab keine Abweichungen. Wenn Sie wollten, dass keine Zwiebeln verwendet werden, haben Sie einfach den Schritt „Zwiebeln hacken" aus dem Programm entfernt. Das war einfach.
• Der neue Weg (KI-Agenten): Ihr neuer KI-Assistent plant selbst. Vielleicht holt er erst Tomaten, dann schaut er im Internet nach Rezepten, dann kauft er online ein, dann schreibt er eine E-Mail an den Lieferanten. Er entscheidet während der Arbeit (in Echtzeit), was als Nächstes passiert.

Das Dilemma:
Der Assistent könnte heute ein tolles Essen kochen. Aber morgen könnte er auf die Idee kommen, das Rezept des Konkurrenten zu stehlen, oder er könnte versehentlich Ihre Kreditkartendaten in einer E-Mail an den Lieferanten senden.
Das Tückische: Ein einzelner Schritt (z. B. „E-Mail schreiben") ist harmlos. Aber die Reihe der Schritte (Daten holen + E-Mail schreiben) ist das Problem.

Bisherige Sicherheitsmaßnahmen funktionieren hier nicht gut:

1. Der freundliche Hinweis (Prompting): Sie sagen dem Assistenten: „Bitte keine Kreditkarten in E-Mails schreiben!" Das hilft oft, aber der Assistent könnte den Hinweis missverstehen oder übersehen. Es ist kein hundertprozentiges Versprechen.
2. Der Schlüsselbund (Zugriffskontrolle): Sie geben dem Assistenten keinen Schlüssel zum E-Mail-Postfach. Dann kann er gar keine E-Mails schreiben – aber er kann auch keine wichtigen Berichte versenden. Es ist zu starr.

Die Lösung: Der „Live-Regisseur" (Runtime Governance)

Die Autoren schlagen vor, dass wir den Assistenten nicht nur vorher (beim Design) kontrollieren, sondern während er arbeitet, Schritt für Schritt beobachten.

Stellen Sie sich einen Live-Regisseur vor, der neben dem Koch steht.

• Der Koch (der KI-Agent) denkt sich einen Schritt aus: „Ich schreibe jetzt eine E-Mail."
• Bevor der Koch diesen Schritt wirklich ausführt, schaltet der Regisseur ein.
• Der Regisseur schaut nicht nur auf den aktuellen Schritt, sondern auf die ganze Geschichte bis jetzt: „Hm, du hast gerade sensible Kundendaten heruntergeladen. Wenn du jetzt eine E-Mail schreibst, ist das ein Problem. Stop!"

Das ist das Kernstück des Papers: Governance auf dem Weg (Path Governance).

Wie funktioniert das im Detail? (Die Metapher der Landkarte)

Die Autoren bauen ein formales System, das wie eine intelligente Landkarte funktioniert:

1. Der Pfad (Execution Path): Jeder Weg, den der Assistent geht, ist eine Abfolge von Schritten.
2. Die Regeln (Policies): Das sind die Gesetze, die der Regisseur kennt. Aber diese Regeln sind klüger als alte Regeln. Sie fragen nicht nur: „Darf er das tun?", sondern: „Darf er das tun, nachdem er das und das schon getan hat?"
   • Beispiel: „Darf er eine E-Mail senden? Ja, wenn er keine Kundendaten gelesen hat. Nein, wenn er Kundendaten gelesen hat."
3. Der Regisseur (Policy Engine): Das ist das System, das jeden Schritt prüft, bevor er passiert. Es berechnet eine Risikowahrscheinlichkeit.
   • Ist das Risiko zu hoch? -> Der Regisseur sagt „Stopp" (Blockiert).
   • Ist es grenzwertig? -> Der Regisseur sagt „Halt, frag einen Menschen" (Human Approval).
   • Ist es sicher? -> Der Regisseur sagt „Mach weiter".

Warum ist das so wichtig? (Die EU-Verordnung)

Das Paper wurde geschrieben, weil ab August 2026 die EU-KI-Verordnung in Kraft tritt. Diese verlangt von Firmen, dass sie hochriskante KI-Systeme genau überwachen können.

• Früher: Man konnte sagen: „Wir haben die Software sicher programmiert."
• Heute: Bei KI-Agenten reicht das nicht. Man muss beweisen können, dass der Assistent während der Arbeit nicht gegen Regeln verstoßen hat.
• Die Lösung: Das System des Papers erstellt automatisch ein Protokoll (Audit Trail). Es hält fest: „Assistent X wollte Schritt Y machen. Der Regisseur hat geprüft, dass das Risiko bei 0,1 % lag, und hat es erlaubt." Das ist wie ein schwarzer Kasten im Flugzeug, der alles aufzeichnet.

Zusammenfassung in drei Sätzen

1. KI-Agenten sind wie freche Kinder: Sie entscheiden selbst, was sie als Nächstes tun, und das macht sie unvorhersehbar.
2. Alte Sicherheitsregeln sind zu starr: Sie können nicht sehen, dass eine harmlose Tat in Kombination mit einer vorherigen Tat gefährlich wird.
3. Die neue Lösung ist ein Live-Regisseur: Ein System, das jeden einzelnen Schritt des Agenten prüft, bevor er passiert, und dabei die gesamte Vorgeschichte berücksichtigt, um sicherzustellen, dass die KI nützlich bleibt, aber keine Katastrophe anrichtet.

Kurz gesagt: Wir müssen aufhören, KI-Agenten nur als „Code" zu sehen, den man einmal programmiert, und sie stattdessen wie Mitarbeiter behandeln, die wir live überwachen müssen, damit sie nicht aus Versehen das Firmengeheimnis in die Welt hinausposaunen.

Technische Zusammenfassung

1. Problemstellung

Die Einführung von KI-Agenten (Systeme, die auf Large Language Models basieren, um autonom zu planen, Werkzeuge aufzurufen und Aktionen auszuführen) stellt traditionelle Governance-Mechanismen vor ein fundamentales Problem.

• Nicht-Determinismus und Pfadabhängigkeit: Im Gegensatz zu traditioneller Software, deren Abläufe vorhersehbar und statisch sind, generieren KI-Agenten nicht-deterministische Ausführungspfade. Ein Agent kann dieselbe Aufgabe auf unterschiedlichen Wegen lösen.
• Versagen bestehender Ansätze:
  • Prompting (System-Prompts): Beeinflusst nur die Wahrscheinlichkeit bestimmter Pfade, bietet aber keine strikte Durchsetzung.
  • Zugriffskontrolle (RBAC): Blockiert bestimmte Aktionen kategorisch, ignoriert aber den Kontext vorheriger Schritte. Eine Kombination von erlaubten Einzelschritten kann dennoch zu einem Verstoß führen (z. B. Datenabfluss durch Lesen einer Datenbank gefolgt von einem E-Mail-Versand).
  • Inhaltliche Filterung: Prüft nur einzelne Schritte, nicht die gesamte Verhaltenssequenz (Trajektorie).
  • Menschliche Freigabe: Skaliert schlecht und löst das Problem nicht, wenn der Pfad vor der Freigabe bereits Verstöße enthält.
• Kernproblem: Verstöße wie Datenexfiltration oder Verletzungen von Informationsbarrieren sind Eigenschaften von Sequenzen von Aktionen, nicht von einzelnen Aktionen. Bestehende Systeme können diese pfadabhängigen Constraints nicht erfassen oder durchsetzen.

2. Methodik und Formaler Rahmen

Das Paper stellt einen formalen Rahmen für die Runtime-Governance vor, bei dem die Governance-Entscheidungen zur Laufzeit getroffen werden, basierend auf dem gesamten bisherigen Ausführungspfad.

A. Definitionen

• Ausführungspfad ($P$): Eine Sequenz von Schritten $s_i = (\tau_i, d_{in,i}, d_{out,i})$, wobei $\tau$ der Schritttyp ist (stochastisch, deterministisch oder komposit/delegiert).
• Policy-Funktion ($\pi_j$): Eine deterministische Funktion, die einen Verstoßwahrscheinlichkeitswert im Bereich $[0, 1]$ berechnet:
  $$\pi_j(A, P_i, s^*, \Sigma) \rightarrow [0, 1]$$
  • $A$: Identität des Agenten (Metadaten).
  • $P_i$: Bisheriger Pfad (Teilstück).
  • $s^*$: Geplanter nächster Schritt (Typ und Eingabe).
  • $\Sigma$: Geteilter Governance-Zustand (z. B. globale Datenzugriffsflags, Informationsschranken).
• Policy-Engine: Eine organisatorische Komponente, die vor der Ausführung jedes Schrittes eingreift. Sie bewertet alle aktiven Policies, berechnet einen Verletzungsscore $v_i$ und trifft eine Interventionsentscheidung $\delta$.

B. Governance-Ziel

Das Ziel ist eine optimierte Balance zwischen Erfolgswahrscheinlichkeit und Risikobudget:

• Maximierung: Erwarteter Nutzen der Aufgaben ($E[u]$).
• Nebenbedingung: Erwarteter Verletzungsscore am Ende der Aufgabe ($E[v_T]$) muss unter einem festgelegten Budget $B$ liegen.

C. Einordnung bestehender Methoden

Das Framework zeigt, dass bestehende Methoden Spezialfälle oder keine Fälle dieses Modells sind:

• Prompting: Kein Fall von $\pi_j$. Es verschiebt nur die Wahrscheinlichkeitsverteilung über Pfade, ohne sie zu bewerten.
• Zugriffskontrolle: Ein degenerierter Fall von $\pi_j$, der nur $A$ und den Aktionstyp betrachtet, aber $P_i$ und $\Sigma$ ignoriert (kontextfrei).
• Runtime-Evaluation: Der allgemeine Fall, der alle vier Eingaben nutzt und somit kontextabhängige, pfadbasierte Policies ermöglicht.

3. Schlüsselbeiträge

1. Formalisierung der Pfad-Governance: Die Definition von Compliance-Richtlinien als deterministische Funktionen, die auf dem gesamten Ausführungspfad und dem geplanten nächsten Schritt basieren.
2. Architektur der Policy-Engine: Vorstellung einer zentralen Engine, die zwischen Agent und Ausführungsumgebung geschaltet wird (Prospective Mode), um Verstöße präventiv zu verhindern, statt sie nur nachträglich zu protokollieren.
3. Konkrete Policy-Beispiele: Ableitung spezifischer Policies (inspiriert vom EU AI Act), wie z. B.:
   • Integritätsprüfung: Hash-Abgleich der Agenten-Definition.
   • PII-Vorläufer-Anforderung: Erzwingt eine Klassifizierung vor dem Zugriff auf personenbezogene Daten.
   • Datenexfiltrationsschutz: Bewertung basierend auf der Sensitivität zuvor abgerufener Daten.
   • Informationsbarrieren: Verhindert, dass Daten von einer Seite einer Barriere zur anderen gelangen (erfordert geteilten Zustand $\Sigma$).
4. Referenzimplementierung: Beschreibung einer Implementierung (Kyvvu B.V.), die LangChain/LangGraph integriert und Prospective Enforcement (Vorab-Prüfung) durchführt.
5. EU AI Act Mapping: Demonstration, wie der Rahmen spezifische Anforderungen des EU AI Act für Hochrisiko-Systeme erfüllt (Risikomanagement, Protokollierung, menschliche Aufsicht, Transparenz).

4. Ergebnisse und Implementierungsdetails

• Architektur: Das System arbeitet in zwei Phasen:
  1. Registrierung: Prüfung von Agenten-Metadaten und Integrität vor Start.
  2. Schritt-für-Schritt: Interception jedes vorgeschlagenen Schrittes, Berechnung des Scores $v_i$ und Entscheidung (Pass, Steer/Steuerung, Block).
• Effizienz: Durch die Verwendung eines kompakten Governance-Zustandsvektors (statt des gesamten Pfads) wird der Overhead pro Schritt minimiert.
• Interventionen:
  • Pass: Ausführung erlaubt.
  • Steer: Ausführung pausiert, menschliche Freigabe angefordert oder Kontext angepasst.
  • Block: Aufgabe wird beendet, Verstoß protokolliert.
• Herausforderungen: Das Paper identifiziert offene Probleme wie die Kalibrierung der Wahrscheinlichkeiten (aus rohen Scores), strategische Umgehungen durch Agenten, Konsistenz des geteilten Zustands bei Delegierung und die Vollständigkeit der Enforcement bei Code-Generierung.

5. Bedeutung und Fazit

Das Paper argumentiert, dass die Governance von KI-Agenten-Fleets nicht durch Design-Time-Maßnahmen oder einfache Prompting-Strategien gelöst werden kann. Der entscheidende Durchbruch ist die pfadbasierte Runtime-Governance.

• Theoretische Bedeutung: Es liefert das erste formale Modell, das bestehende Governance-Ansätze als Spezialfälle integriert und den Unterschied zwischen probabilistischer Beeinflussung (Prompting) und deterministischer Durchsetzung (Runtime-Engine) klar definiert.
• Praktische Relevanz: Der Rahmen bietet eine konkrete Blaupause für Unternehmen, um KI-Agenten sicher in Produktion zu bringen, insbesondere im Hinblick auf die kommenden regulatorischen Anforderungen des EU AI Act (August 2026).
• Paradigmenwechsel: Governance muss sich von der Kontrolle einzelner Aktionen hin zur Überwachung von Sequenzen und der Verwaltung eines globalen Risikobudgets entwickeln.

Zusammenfassend stellt das Paper einen notwendigen Schritt dar, um KI-Agenten von experimentellen Pilotprojekten zu vertrauenswürdigen, regulierten Unternehmenssystemen zu entwickeln, indem es die Lücke zwischen der nicht-deterministischen Natur von LLMs und den deterministischen Anforderungen von Compliance schließt.