Context Card
In-Band- und Out-of-Band-Überwachung eines KI-Agenten
Was unterscheidet die In-Band- von der Out-of-Band-Überwachung eines KI-Agenten?
Die kurze Antwort
In-Band-Überwachung eines KI-Agenten läuft innerhalb seiner eigenen Laufzeitumgebung: Systemanweisung, Werkzeug-Allowlists, Sandbox-Profile und die Policy-Instanz, die jeden Werkzeugaufruf beantwortet. Out-of-Band-Überwachung läuft in einem getrennten Ausführungskontext — eigener Prozess, anderer Host, Netzwerk-Chokepoint oder ein eigener Prozessor wie eine DPU — und beobachtet Wirkungen wie Systemaufrufe, DNS-Anfragen oder Schreibzugriffe, ohne auf die Mitwirkung des Agenten angewiesen zu sein. Beide Positionen werden gebraucht: die eine liefert Absicht und Kontext, die andere unabhängige Evidenz und einen Eingriffspfad.
Für: Technische Redaktion und Engineering in Agenten-Projekten
Das Wichtigste
- In-Band-Kontrollen sitzen in der Laufzeit des Agenten und entscheiden Werkzeugaufrufe mit vollem Kontext.
- Out-of-Band-Kontrollen laufen getrennt und sehen Wirkungen, nicht Absichten.
- Eine In-Band-Kontrolle teilt das Schicksal der Komponente, die sie begrenzen soll.
- Unabhängigkeit ist eine Architektureigenschaft, die nachgewiesen werden muss.
- Dokumentiert werden sollten Position, Auslösebedingungen und Änderungsbefugnis jeder Kontrolle.
Der Zusammenhang
Wo eine Kontrolle sitzt
Ein KI-Agent arbeitet in einer Schleife aus Modell- und Werkzeugaufrufen. Jede Begrenzung kann an zwei Stellen ansetzen. In-Band-Kontrollen liegen in der eigenen Laufzeitumgebung des Agenten: Systemanweisung, Werkzeug-Allowlists, Argumentprüfung, Sandbox-Profile, Kontingente und die Policy-Instanz, die jeden Werkzeugaufruf beantwortet. Out-of-Band-Kontrollen laufen in einem getrennten Ausführungskontext — als überwachender Prozess, auf einem anderen Host, an einem Netzwerk-Chokepoint oder auf einem eigenen Prozessor wie einer SmartNIC oder DPU — und beobachten den Agenten von außen: Systemaufrufe, DNS-Anfragen, ausgehende Verbindungen, Nutzung von Zugangsdaten, Schreibzugriffe.
Was jede Position sieht
In-Band-Kontrollen sehen die Absicht. Sie kennen Werkzeug, Argumente, Aufgabe und handelnde Identität, weshalb feingranulare Zugriffskontrolle nur dort entscheidbar ist. Sie liegen aber auch am nächsten an einem manipulierten oder fehllaufenden Agenten, weil sie Prozess, Bibliotheken und teils das Kontextfenster mit dem Verhalten teilen, das sie begrenzen sollen.
Out-of-Band-Kontrollen sehen Wirkungen, nicht Gründe. Sie können nicht beurteilen, ob ein Zugriff zur Aufgabe passte, aber ihr Urteil hängt nicht vom Wohlverhalten des Agenten ab: Sie können eine Sitzung isolieren, eine Route verwerfen oder ein Token entwerten, während der Agent weiterläuft. Zusammen decken beide Schichten die blinden Flecken der jeweils anderen ab.
Was die Dokumentation zeigen muss
Für jede Kontrolle gehören in den Nachweis: ihre Lage zur Systemgrenze, ihre Vertrauensannahmen, die Ereignisse, die sie in die Protokollierung schreibt, und der Speicherort dieser Einträge, außerdem Auslösebedingungen, erwartete Reaktionszeit, Änderungsbefugnis und die geprüften Fehlerszenarien. Herstellerangaben zur Isolationszeit beschreiben eine Konfiguration unter Testbedingungen; sie sind in der Zielumgebung zu messen und keine Produkteigenschaft. Eine Überwachung, die Policy, Zeitbasis oder Log-Speicher von der überwachten Laufzeit bezieht, ist faktisch In-Band und sollte so beschrieben werden.
Fragen, die sich daran anschließen
- Ersetzt eine Out-of-Band-Überwachung die In-Band-Policy?
- Nein. Nur die Agentenlaufzeit kennt den Aufgabenkontext für feingranulare Werkzeugentscheidungen. Die Out-of-Band-Schicht ergänzt unabhängige Beobachtung und einen Abbruchpfad; keine der beiden Schichten deckt beides ab.
- Warum wird für die Überwachung teils eigene Hardware genutzt?
- Läuft die Überwachung auf einem separaten Prozessor, liegt sie außerhalb der Rechen- und Speicherdomäne des Agenten, was Manipulation erschwert und Rückwirkungen auf die Performance verringert. Der Nutzen hängt von der Konfiguration ab und ist zu validieren.
- Wie lässt sich Unabhängigkeit belegen?
- Durch dokumentierte Trennung von Policy-Quelle, Ausführungskontext, Zeitbasis und Log-Speicher sowie durch Nachweise, dass die Überwachung auch dann handelt, wenn die Agentenlaufzeit nicht mehr reagiert.
Quellen
- Agentic AI – Threats and Mitigations — OWASP Gen AI Security Project, 5. Oktober 2026
- Technical Blog: Strengthening AI Agent Hijacking Evaluations — NIST, 17. Januar 2025
- CAISI's AI Agent Security Agenda — Cloud Security Alliance Labs, 14. April 2026
Prüfprotokoll und Änderungen
Jede Context Card wird vor der Veröffentlichung und bei jeder Änderung erneut anhand ihrer Quellen geprüft; das Datum unter der Autorenzeile ist die letzte Prüfung. Korrekturen (etwas war falsch) und Ergänzungen (etwas fehlte) stehen unten mit Datum und Uhrzeit (deutsche Zeit). Tippfehler, Formatierung und Link-Korrekturen werden nicht aufgeführt.
Geprüft
Seit der Veröffentlichung keine Korrekturen oder Ergänzungen.