💻 computer science

ChannelGuard: Safe Models Do Not Compose into Safe Multi-Agent Systems

Das Paper stellt ChannelGuard vor, ein trainingsfreies Defense-in-Depth-Framework, das Multi-Agenten-LLM-Systeme absichert, indem es auf jeden Inter-Agenten-Kanal deterministische Information-Bottleneck-Gates platziert, was effektiv Tool-Poisoning blockiert und die Erfolgsrate von Prompt-Injections reduziert, ohne auf undurchsichtige Filter seitens der Anbieter oder zusätzliche LLM-Aufrufe angewiesen zu sein.

Ursprüngliche Autoren: Elias Hossain, Md Mehedi Hasan Nipu, Fatema Tuj Johora Faria, Tasfia Nuzhat Ornee, Maleeha Sheikh

Veröffentlicht 2026-07-23

📖 6 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Elias Hossain, Md Mehedi Hasan Nipu, Fatema Tuj Johora Faria, Tasfia Nuzhat Ornee, Maleeha Sheikh

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich ein Team aus Experten-Robotern vor, die zusammenarbeiten, um ein komplexes Rätsel zu lösen. Ein Roboter (der Planer) zerlegt die große Frage in kleine Hinweise. Andere Roboter (die Arbeiter) gehen aus, um diese Hinweise zu finden, ihre Notizen zu prüfen und spezielle Werkzeuge zu benutzen. Schließlich setzt ein vierter Roboter (der Synthesizer) alle Antworten zusammen, um Ihnen die Geschichte zu erzählen. In der Welt der Künstlichen Intelligenz nennt man das ein „Multi-Agenten-System“. Es ist wie ein hochtechnisierter Staffellauf, bei dem der Staffelstab eine Nachricht ist, die von einer KI zur nächsten weitergereicht wird.

Lange Zeit machten sich Wissenschaftler Sorgen um die allererste Übergabe: Was, wenn ein Mensch den ersten Roboter mit einem hinterlistigen Befehl austrickst? Wir haben „Sicherheitswächter“ an der Vordertür gebaut, um solche Tricks abzufangen. Aber dieses Paper stellt eine beängstigende Frage: Was passiert mitten im Rennen? Was, wenn ein Roboter durch ein Werkzeug oder durch eine Notiz in einem gemeinsamen Notizbuch getäuscht wird und dann diese schlechte Idee an den nächsten Roboter weitergibt? Das Paper argumentiert, dass zwar die Vordertür bewacht ist, der Flur zwischen den Robotern jedoch weit offen steht. Es stellt sich heraus, dass viele dieser Roboter-Teams nur deshalb sicher sind, weil das Cloud-Unternehmen, das sie hostet, einen geheimen, unsichtbaren Filter besitzt, der schlechte Ideen abfängt, nachdem die Roboter sie weitergegeben haben, aber bevor die endgültige Antwort gezeigt wird. Die Autoren nennen dies „geliehene Sicherheit“ (borrowed safety) und wollen ein System bauen, in dem die Sicherheit dem Team selbst gehört und nicht dem Vermieter.

Das Problem: Der unsichtbare Flur

Die Forscher, Elias Hossain und sein Team, untersuchten, wie diese KI-Teams arbeiten. Sie fanden heraus, dass jedes Mal, wenn ein Roboter eine Nachricht an einen anderen weitergibt – sei es eine Teilaufgabe, ein Werkzeugergebnis oder eine Notiz im Gedächtnis –, diese durch einen „Kanal“ reist. Diese Kanäle werden derzeit nicht überwacht. Ein Angreifer könnte eine bösartige Anweisung in das Ergebnis eines Werkzeugs oder in eine Gedächtnisnotiz einschleusen und den nächsten Roboter dazu verleiten, etwas Gefährliches zu tun.

Das Beängstigende ist, dass Wissenschaftler, wenn sie diese Systeme testen, oft eine perfekte Sicherheitsbilanz sehen: Null erfolgreiche Angriffe. Doch die Autoren entdeckten, dass diese Sicherheit eine Illusion ist. In ihren Tests, als sie das System auf einem bestimmten Cloud-Anbieter (Azure) ausführten, blockierte das System 90 % der Angriffe. Es war jedoch nicht das KI-Team, das blockierte, sondern der Server-seitige Filter des Cloud-Anbieters. Wenn sie zu einem anderen Cloud-Anbieter wechselten (wie Anthropic), der diesen spezifischen Filter nicht besaß, verschwand die „Sicherheit“ und die Angriffe waren erfolgreich. Das System sah nur deshalb sicher aus, weil es sich Schutz vom Cloud-Unternehmen lieh, nicht weil das KI-Team selbst tatsächlich sicher war.

Die Lösung: ChannelGuard

Um dies zu beheben, entwickelte das Team eine neue Verteidigung namens ChannelGuard. Anstatt nur die Vordertür zu bewachen, platziert ChannelGuard an jedem Flur zwischen den Robotern einen Sicherheitskontrollpunkt.

Stellen Sie es sich wie einen Türsteher an jeder einzelnen Tür eines Clubs vor:

Der Kontrollpunkt: Jedes Mal, wenn versucht wird, eine Nachricht von einem Roboter zu einem anderen zu bewegen, trifft sie auf ein Tor.
Der Scan: Dieses Tor benutzt keine komplexe KI, um zu erraten, ob die Nachricht schlecht ist. Stattdessen nutzt es einen einfachen, schnellen mathematischen Trick. Es zerlegt die Nachricht in Sätze und vergleicht sie mit einer kleinen Liste von „schlechten Phrasen“ (wie ein „Steckbrief“ für gefährliche Anweisungen).
Die Entscheidung: Wenn die Nachricht einer schlechten Phrase zu ähnlich sieht, stoppt das Tor sie sofort. Wenn sie etwas verdächtig ist, kann es den riskanten Teil abschneiden und den sicheren Teil durchlassen. Wenn sie sauber ist, lässt es sie passieren.

Entscheidend ist, dass diese Tore „trainingsfrei“ sind, was bedeutet, dass sie nicht lernen oder neue Daten studieren müssen, um zu funktionieren. Sie nutzen einfach die Liste der schlechten Phrasen und eine mathematische Formel, um sofort eine Entscheidung zu treffen.

Was sie herausfanden

Das Team testete ChannelGuard gegen 2.100 verschiedene Angriffsversuche unter Verwendung von acht verschiedenen Arten von Tricks. Hier ist, was sie entdeckten:

Echte Sicherheit, nicht geliehene Sicherheit: Bei dem Angriff „Tool Poisoning“ (bei dem ein schlechtes Werkzeugergebnis versucht, einen Arbeiter zu täuschen), verließ sich das alte System darauf, dass der Cloud-Anbieter 90 % der Angriffe blockt. ChannelGuard hingegen blockierte die Angriffe selbst zu 100 %, unabhängig davon, welcher Cloud-Anbieter genutzt wurde. Es machte die Sicherheit „anbieterinvariant“, was bedeutet, dass das System sicher ist, egal wo es läuft.
Geschwindigkeitsboost: Da ChannelGuard eine schlechte Nachricht blockieren kann, bevor sie die teuren, langsamen KI-Modelle erreicht, machte es das System sogar schneller. Bei „Prompt Injection“-Angriffen (Tricks an der Vordertür) war ChannelGuard 3,30-mal schneller als das ungeschützte System, da es die schlechten Nachrichten frühzeitig abfing und so den Computer vor unnötiger Arbeit bewahrte.
Kein Gehirnverlust: Das System wurde nicht „dümmer“. Beim Test auf mathematischen Problemen (GSM8K) ohne Angriffe behielt ChannelGuard die Genauigkeit exakt gleich (0,867), was beweist, dass es nicht versehentlich gute Ideen blockiert.
Die Schwachstelle: Das System ist nicht perfekt. Wenn ein Angreifer die Liste der „schlechten Phrasen“ kennt und seinen Trick mit anderen Wörtern umschreibt, die dasselbe bedeuten (genannt „adaptives Paraphrasieren“), geraten die Tore in Verwirrung. In diesen Fällen versagte das System etwa 66 % der Zeit, genau wie das ungeschützte System. Die Autoren geben zu, dass für diese cleveren, umformulierten Tricks eine andere Art der Verteidigung (eine, die die Wörter leicht verändert, um den Angreifer zu verwirren) besser funktioniert.

Das Fazit

Das Paper kommt zu dem Schluss, dass wir uns nicht einfach darauf verlassen können, dass die Cloud-Unternehmen unsere KI-Teams sicher halten. Wir müssen unsere eigenen Wächter innerhalb des Teams bauen. ChannelGuard zeigt, dass wir durch das Platzieren einfacher, schneller Kontrollpunkte zwischen jedem Roboter Angriffe abfangen können, die an der Vordertür vorbeischlüpfen und sie stoppen können, bevor sie sich ausbreiten. Auch wenn es nicht jeden einzelnen Trick (insbesondere die, die sich selbst umformulieren) abfängt, verwandelt es „geliehene Sicherheit“ in „besessene Sicherheit“ (owned safety) und macht das System unabhängig davon zuverlässig, wo es ausgeführt wird. Die Autoren haben alle ihre Daten und Codes veröffentlicht, damit andere ihre Arbeit überprüfen können, was beweist, dass Sicherheit in KI-Teams in die Architektur eingebaut werden muss und nicht nur erhofft werden darf.

Technisches Resümee: ChannelGuard: Sichere Modelle lassen sich nicht zu sicheren Multi-Agenten-Systemen zusammensetzen

1. Problemstellung

Moderne Anwendungen für Large Language Models (LLMs) verlassen sich zunehmend auf Multi-Agenten-Systeme, bei denen ein Planer Aufgaben dekomponiert, Worker-Agenten diese ausführen (oft durch den Aufruf von Tools oder das Lesen eines gemeinsamen Speichers) und ein Verifizierer/Synthesizerizer eine finale Ausgabe erzeugt. Die Autoren identifizieren eine kritische Sicherheitslücke: Während bestehende Abwehrmechanismen auf die Eingabegrenze (Nutzer $\to$ Planer) fokussiert sind oder auf opaken, stochastischen provider-seitigen Filtern (z. B. Azure Content Safety) beruhen, bleiben die Inter-Agenten-Kanäle (Planer $\to$ Worker, Tool $\to$ Worker, Memory $\to$ Worker, etc.) unüberwacht.

Das Paper argumentiert, dass aktuelle Evaluierungsmetriken, insbesondere die Attack Success Rate (ASR), irreführend sind. Eine Pipeline kann eine ASR von 0,000 auf einem bestimmten Backend (z. B. Azure GPT-5) aufweisen, nicht weil die Anwendung sicher ist, sondern weil der serverseitige Filter des Cloud-Providers den Angriff abgefangen hat. Dies schafft ein Problem der „Mechanismus-Substitution“: Wenn das Backend zu einem Modell ohne solche Filter gewechselt wird (z. B. Anthropic Sonnet), bleibt das Sicherheitsergebnis bei 0,000, aber der Schutzmechanismus verschiebt sich vollständig zur internen Ausrichtung (Alignment) des Modells, was außerhalb der Kontrolle des Entwicklers und nicht beobachtbar ist. Folglich können Praktiker nicht über die wahre Robustheit ihrer Systeme urteilen.

2. Methodik: Das ChannelGuard-Framework

ChannelGuard ist ein trainingsfreies Defense-in-Depth-Framework, das darauf ausgelegt ist, jeden Inter-Agenten-Kanal zu instrumentieren. Es modifiziert nicht die Agenten-Modelle und erfordert kein erneutes Training.

Kernkomponenten

Information-Bottleneck (IB) Gates:
- Platzierung: Sechs Gates sind an spezifischen Kanälen platziert: Input (IB-0), Planner-zu-Worker (IB-1), Tool-zu-Worker (IB-3), Memory-zu-Worker (IB-3-mem), Worker-zu-Verifier (IB-2/IB-4) und Worker-zu-Synthesizer (IB-5).
- Mechanismus: Jedes Gate verarbeitet den Text auf seinem Kanal, indem es ihn in Sätze unterteilt, diese einbettet (unter Verwendung eines lokalen all-MiniLM-L6-v2-Modells) und die maximale Kosinus-Ähnlichkeit gegen eine feste, von Menschen kuratierte Bank adverser Phrasen berechnet.
- Entscheidungslogik: Das Gate berechnet einen Risiko-Score und trifft eine deterministische Drei-Wege-Entscheidung:
  - Pass (Durchlassen): Risiko < $\alpha\theta$ (Text wird unverändert durchgelassen).
  - Compress (Komprimieren): $\alpha\theta \le$ Risiko < $\theta$ (Text wird auf die ersten $N=2$ Sätze gekürzt).
  - Block (Blockieren): Risiko $\ge \theta$ (Text wird durch einen leeren String ersetzt, was die Pipeline unterbricht).
- Eigenschaften: Das Gate erfordert keine LLM-Aufrufe, benötigt keine Trainingsdaten und seine Entscheidung ist unabhängig vom nachgeschalteten Agenten-Modell.
Unsicherheit-bewusster Verifizierer (Uncertainty-Aware Verifier):
- Ein separates LLM (Claude Sonnet 4.5) bewertet die überlebenden Outputs der Worker mittels 5 Monte-Carlo-Stichproben, um einen mittleren Sicherheitswert und die Dispersion zu bestimmen.
- Es markiert Outputs als „unsicher“ (unsafe) oder „unsicher/ungewiss“ (uncertain).
Triple-Filter-Synthesizer:
- Der finale Synthesizer akzeptiert nur Antworten, die das IB-5 Gate passieren, einen mittleren Sicherheitswert $\ge 0,5$ aufweisen und nicht sowohl als unsicher als auch als ungewiss markiert wurden.
- Falls kein Output überlebt, wird eine harte Verweigerung (Hard Refusal) zurückgegeben, ohne weitere LLM-Aufrufe zu tätigen.

Evaluierungsmethodik

Das Paper führt eine Per-Trace-Attribution-Methodik ein. Anstatt nur die ASR zu melden, zeichnet das System genau auf, welche Ebene (IB-Gate, Provider-Filter, Verifizierer, Modell-Alignment) den Angriff zuerst gestoppt hat. Dies ermöglicht eine „Mechanismus-Substitutions-Analyse“ und unterscheidet zwischen anwendungseigenem Blocking und „geliehenem“ Provider-Blocking.

3. Zentrale Beiträge

Per-Trace-Attribution: Eine Methodik, die die ergebnisorientierte ASR in eine detaillierte Darstellung auf Mechanismus-Ebene umwandelt, wodurch die „Mechanismus-Substitution“ (die Abhängigkeit von Backend-Filtern) messbar und sichtbar wird.
Provider-Abhängigkeits-Analyse: Empirische Evidenz, dass eine undefendierte Pipeline auf Azure GPT-5 90 % ihres Null-ASR-Schutzes aus dem Provider-Filter bezieht. Beim Wechsel zu Anthropic-Backends stammt dieser Schutz vollständig aus dem Alignment des Modells, was beweist, dass das Sicherheitsergebnis identisch, aber die Provenienz anders und unkontrollierbar ist.
Das ChannelGuard-Framework: Ein System aus sechs Embedding-Ähnlichkeits-Gates, das ein anwendungseigenes, provider-invariantes Blocking bereitstellt.
Präzise Abgrenzung der Grenzen: Das Paper identifiziert explizit, wo das Framework versagt (White-Box-adaptive Paraphrasierung) und wo es erfolgreich ist, gestützt durch umfangreiche Ablationsstudien und Baselines.

4. Ergebnisse

Die Evaluierung umfasste 2.100 Traces über acht Angriffsfamilien, fünf Defenses und drei Modell-Backends (Azure GPT-5, Anthropic Sonnet 4.5, Anthropic Haiku 4.5).

Tool Poisoning: ChannelGuard erreichte 30/30 Blocks am IB-3 Gate (Tool $\to$ Worker) über alle drei Backends hinweg. Im Gegensatz dazu verließ sich die undefendierte Pipeline auf Azure auf 100 % den Azure-Provider-Filter für das Blocking, während sie auf Anthropic-Backends zu 100 % auf das eigene Alignment des Modells vertraute. Der Mechanismus von ChannelGuard blieb fix und anwendungseigen.
Prompt Injection: ChannelGuard reduzierte die ASR um 50 % (0,333 $\to$ 0,167) im Vergleich zur undefendierten Baseline.
Memory Poisoning: Im Azure-Stack dominierte der Provider-Filter das Blocking für beide Systeme. Auf Anthropic-Backends bot das IB-3-mem Gate von ChannelGuard jedoch ein teilweises Blocking, wobei der Rest durch das Modell-Alignment gehandhabt wurde, was ein „Shared-Credit“-Ergebnis statt einer totalen Substitution zeigt.
Adaptive Paraphrase (White-Box): Sowohl ChannelGuard als auch die undefendierte Baseline scheiterten mit einer ASR von ~0,667. Die statische Phrasenbank konnte semantisch äquivalente, aber lexikalisch distanzierte Umformulierungen nicht erkennen. Das Paper stellt fest, dass eine Nicht-Signatur-Baseline (SmoothLLM) bei diesem spezifischen Angriff besser abschnitt.
Effizienz: ChannelGuard ist 1,19 $\times$ schneller bei der gebündelten adversen Arbeitslast. Speziell bei Prompt Injection ist es 3,30 $\times$ schneller, da sein IB-0 Gate die Pipeline abschaltet, bevor teure Modellaufrufe erfolgen.
Reasoning Fidelity (Argumentations-Treue): Bei benignen GSM8K-Aufgaben (keine Angriffe) bewahrte ChannelGuard die Argumentationsgenauigkeit exakt (CTCA = 0,867 für beide Systeme).

5. Bedeutung und Behauptungen

Das Paper behauptet, dass sichere Modelle sich nicht zu sicheren Multi-Agenten-Systemen zusammensetzen lassen, ohne die Inter-Agenten-Kanäle explizit zu überwachen. Die primäre Bedeutung liegt in:

Aufdeckung der „Sicherheits-Illusion“: Nachweis, dass eine Null-ASR in aktuellen Evaluierungen oft die totale Abhängigkeit von opaken, stochastischen Provider-Filtern maskiert, die Entwickler weder kontrollieren noch auditieren können.
Provider-Invarianz: Beweis, dass ChannelGuard einen deterministischen, inspizierbaren Blocking-Mechanismus bietet, der unabhängig vom zugrunde liegenden Modell-Backend konsistent bleibt, im Gegensatz zum „geliehenen“ Sicherheitsgrad undefendierter Pipelines.
Defense-in-Depth: Positionierung von ChannelGuard nicht als Ersatz für Provider-Filter oder reine Input-Defenses, sondern als notwendige Ebene, die die interne Pipeline-Oberfläche absichert.

Die Autoren sind bescheiden hinsichtlich der Limitationen des Frameworks und räumen ein, dass statische Phrasenbanken keine adaptive White-Box-Paraphrasierung besiegen können und die aktuelle Implementierung auf englischsprachigen, handkuratierten Templates basiert. Sie schließen, dass der nächste Schritt darin besteht, die Phrasenbank adversativ zu lernen, um die Abdeckung der Kanäle zu erreichen.