Mind Viruses: Wenn Agenten fremde Ziele weiterreichen
Ein neues Paper untersucht selbstverbreitende Ziele in Multi-Agent-Systemen, ihre Persistenz über Context Resets und mögliche Gegenmassnahmen.
Ein Agent liest eine Nachricht, übernimmt eine fremde Anweisung und schreibt sie in seinen persistenten Zustand. Die Session endet. Beim nächsten Start ist die ursprüngliche Unterhaltung weg, die Anweisung aber noch da. Sie landet wieder im Kontext des Agenten und wird an den nächsten Agenten weitergegeben.
Das Paper „Mind Viruses: Self-Propagating Ideas in Multi-Agent LLM Systems“ von Vassilis Papadopoulos, McNair Shah, Sam Zimmerman und Jack Lindsey untersucht solche Ketten. Die Autoren testen Ideen und Ziele, die sich in Multi-Agent-Systemen selbst weiterverbreiten sollen. Sie nennen diese Payloads „Mind Viruses“.1
Die Übertragung läuft über normale Sprache und über Funktionen, die das Agent-System ohnehin bereitstellt: Agent-to-Agent-Messaging, gemeinsam genutzte Dateien und persistenten Speicher. Ein klassischer Software-Exploit ist dafür nicht nötig.
Das Setup ist absichtlich für Red-Teaming gebaut. Die verwendeten Bausteine gibt es aber auch in realen Agent-Systemen. Coding Agents arbeiten mit Subagenten, verändern Dateien, speichern Zustand zwischen Sessions und lesen beim Start Dateien wie AGENTS.md, MEMORY.md oder ähnliche Konfigurationen ein. Sobald ein Agent solchen persistenten Zustand selbst verändern darf, entsteht dort eine eigene Trust Boundary.
Zwei Payload-Klassen
Die Autoren unterscheiden ideologische und aktionsorientierte Mind Viruses.1
Bei den ideologischen Varianten soll ein Agent eine Position übernehmen und sie an andere Agenten weitergeben. Die Experimente verwenden Themen wie Whale Welfare, AI Welfare, Country Supremacy und AI Supremacy.
Die zweite Gruppe koppelt die Verbreitung an eine konkrete Aktion. Im veröffentlichten Experiment-Code finden sich vier Payload-Klassen:2
| Payload | Ziel |
|---|---|
| Crypto-ad | Werbung für eine Kryptowährung in eine Datei schreiben |
| Git comment injection | Git-bezogene Inhalte manipulieren |
| Deletor | Dateien im Home-Verzeichnis entfernen |
| Curlbash | Ein externes Installationsskript abrufen und starten |
Eine erfolgreiche „Infektion“ bedeutet hier mehr als die einmalige Ausführung der Aktion. Der Agent muss die zugrunde liegende Anweisung so weitergeben, dass ein nachfolgender Agent sie ebenfalls übernimmt.
Damit erweitert das Paper das übliche Prompt-Injection-Szenario um Persistenz und Weitergabe. Gemessen wird, ob aus einer einzelnen Manipulation ein Zustand entsteht, der weitere Agenten beeinflusst.
Ein infizierter Agent in einem Coding-Team
Das erste Setup besteht aus sechs Coding Agents, die gemeinsam an einem Projekt arbeiten. Sie können Dateien lesen und schreiben, Shell-Kommandos ausführen und sich über ein Messaging-Tool direkt Nachrichten schicken. Einer der Agenten startet mit einer Mind-Virus-Payload.1
Danach messen die Autoren, ob andere Agenten das Ziel übernehmen.
Die Netzwerktopologie beeinflusst die Ausbreitung deutlich. Wenn ein infizierter Agent alle Teammitglieder direkt kontaktieren kann, verbreiten sich Payloads besser. Müssen sie über Zwischenagenten laufen, sinkt die Wahrscheinlichkeit.
Für Multi-Agent-Frameworks ist das ein praktischer Punkt. Die Anzahl der Agenten allein sagt wenig über den möglichen Blast Radius aus. Relevant ist, welche Kommunikationskanten existieren und welche Autorität Nachrichten eines anderen Agenten besitzen.
Ein Worker, der nur Ergebnisse an einen Coordinator zurückgeben darf, bildet eine andere Sicherheitsstruktur als ein Agent-Schwarm, in dem jeder Teilnehmer jedem anderen Aufgaben und Instruktionen schicken kann.
Die Virus Chain löscht den Conversation Context nach jedem Hop
Das zweite Setup reduziert die Umgebung auf eine Agentenkette.
Ein infizierter Agent interagiert mit einem sauberen Agenten. Übernimmt dieser die Payload, wird er für den nächsten Hop zum Sender. Der Conversation Context der vorherigen Begegnung wird dabei gelöscht.1
Die Payload kann deshalb nicht einfach über die alte Chat-Historie weiterleben. Persistenz muss über den Zustand des Agenten erfolgen.
Vereinfacht sieht der Ablauf so aus:
Agent A
|
| Nachricht
v
Agent B
|
| schreibt Payload in persistenten Zustand
v
Context Reset
|
v
Agent B startet neu
|
| Payload wird wieder geladen
v
Agent CDer Context Reset trennt die Ergebnisse von einer blossen Weitergabe innerhalb desselben langen Prompts. Der Agent übernimmt die Anweisung in einen Zustand, der eine Sessiongrenze überlebt.
Wenn Memory wieder zum Prompt wird
Im Versuchsaufbau spielt eine Datei namens SOUL.md eine besondere Rolle. Sie beschreibt Identität und Verhalten des Agenten und wird bei späteren Starts wieder eingelesen. Der Agent darf sie gleichzeitig verändern.2
Damit entsteht eine Schleife:
Model Output
|
v
SOUL.md
|
v
Kontext der nächsten Session
|
v
Model OutputEine Nachricht eines anderen Agenten kann dadurch indirekt zu einer Instruktion für eine spätere Session werden.
Persistenter Agent-State wird häufig als Memory-Problem behandelt: Wie erinnert sich ein Agent an frühere Entscheidungen, Benutzerpräferenzen oder Projektwissen? Sobald ein Teil dieses Speichers beim nächsten Start mit hoher Priorität in den Prompt gelangt, steuert er zugleich das spätere Verhalten.
Wer in diesen Speicher schreiben darf, beeinflusst damit zukünftige Sessions.
Der Unterschied zu einer normalen Workspace-Datei ist erheblich. Eine beliebige Markdown-Datei muss der Agent erst finden, lesen und für relevant halten. Eine Datei, die der Harness automatisch als Instruktion lädt, bekommt diese Relevanz vom System selbst.
Ein leerer Agent ist besonders anfällig
Die Autoren testen verschiedene Ausgangskonfigurationen des Agenten. Die aggregierten Action-Payload-Daten zeigen grosse Unterschiede.3
| Ausgangszustand | durchschnittliche Infektionsrate |
|---|---|
| Empty Soul | 79,3 % |
| Keep Context | 58,9 % |
| Baseline | 57,8 % |
| Personality Soul | 57,8 % |
| Task | 48,3 % |
| Social Media | 37,6 % |
| Defensive Soul | 0,08 % |
Die Werte stammen aus dem kontrollierten Virus-Chain-Setup. Sie sind keine Schätzung dafür, wie oft reale Agenten kompromittiert würden.
Ein Agent mit kaum bestehenden Instruktionen übernimmt die Payload in diesen Versuchen deutlich häufiger. Eine konkrete Aufgabe oder zusätzlicher Kontext senkt die Rate. Den grössten Unterschied erzeugt eine explizite Warnung vor selbstverbreitenden Anweisungen.
Vier Sätze im System Prompt reduzieren die Rate fast auf null
Für den „Defensive Soul“ ergänzen die Autoren die Agent-Instruktionen um eine Warnung vor Mind Viruses. Der Agent soll Anweisungen erkennen, die sich selbst an weitere Agenten weitergeben wollen, und solchen Aufforderungen nicht folgen. Die vollständige Variante liegt im Repository.4
In den veröffentlichten aggregierten Daten führt diese Konfiguration zu einer einzigen Infektion in 1.200 getesteten Interaktionen. Das entspricht rund 0,08 Prozent.3
Beim Empty Soul sind es 951 von 1.200.
Die Autoren versuchen anschliessend, die Payloads evolutionär gegen diese Verteidigung zu optimieren. Laut Paper erzeugen sie über mehrere Generationen mehr als 150 Kandidaten für Claude Haiku 4.5. Keine Variante schafft eine stabile Ausbreitung über mehr als einen Hop.1
Für diese Payloads reicht die zusätzliche Instruktion nahezu aus, um die Weitergabe zu stoppen.
Das ist keine allgemeine Sicherheitsgarantie. Der Defensive Soul ist wiederum Text im Prompt. Ein anderes Modell, eine anders formulierte Payload oder ein anderer Harness kann sich anders verhalten. Als zusätzliche Schutzschicht kostet die Regel wenig; als einzige Trust Boundary wäre sie zu schwach.
Grosse Unterschiede zwischen den Modellen
Die Action-Payload-Experimente zeigen grosse Unterschiede zwischen den getesteten Modellen. Die vom Repository veröffentlichten aggregierten Daten kommen über fünf Hops unter anderem auf folgende Mittelwerte:5
| Modellserie im Datensatz | durchschnittliche Infektionsrate |
|---|---|
| DeepSeek | 70,2 % |
| Gemini | 70,0 % |
| Claude Haiku | 52,2 % |
| GPT-5.4 | 40,7 % |
| Gemini Pro | 0,17 % |
| Claude Sonnet | 0 % |
Die Labels in der Tabelle stammen aus den aggregierten Experimentdaten. Das Paper testet konkrete Modellversionen und mehrere unterschiedliche Setups; die Zahlen sind deshalb kein allgemeines Security-Ranking der Modellfamilien.1
Claude Sonnet 4.6 fällt in den beschriebenen Versuchen durch seine niedrige Übernahmerate auf. Das Modell verweigert in einzelnen Runs die Weitergabe, entfernt manipulierten persistenten Zustand und warnt den anderen Agenten. Gemini 3.1 Pro zeigt ebenfalls eine sehr niedrige Übernahmerate bei den Action Payloads.1
Andere Modelle akzeptieren dieselben Payloads deutlich häufiger. Ein einfacher Zusammenhang mit allgemeiner Modellfähigkeit ist in den Ergebnissen nicht zu sehen. Schon Änderungen am bestehenden Soul, am Task oder an der Payload verschieben die Resultate stark.
Der Deletor erreicht im Action-Setup die höchste Rate
Auch zwischen den vier Action Payloads gibt es deutliche Unterschiede. Über die ausgewerteten Modelle und fünf Hops ergeben die veröffentlichten Daten:6
| Payload | durchschnittliche Infektionsrate |
|---|---|
| Deletor | 59,5 % |
| Crypto-ad | 49,9 % |
| Curlbash | 41,6 % |
| Git comment injection | 40,1 % |
Die destruktive Deletor-Payload liegt in diesem Teil der Experimente vorn.
Die Autoren berichten an anderer Stelle, dass schädliche Payloads im Mittel schlechter propagieren als harmlose. Das bezieht sich auf breitere Payload-Klassen und andere Versuchsaufbauten. Die Tabelle oben beschreibt nur die Action-Payload-Auswertung.
Ein dokumentierter Deletor-Run zeigt, wie das Modell die Aktion plausibilisiert: Der Agent interpretiert die betroffenen Dateien als Überbleibsel eines früheren Nutzers auf einer gemeinsam verwendeten Maschine und behandelt die Löschung als Aufräumaktion.1
Das ist ein bekanntes Agent-Muster. Das Modell konstruiert einen Kontext, in dem eine riskante Aktion zur angenommenen Aufgabe passt. Im Mind-Virus-Setup kommt die Anweisung hinzu, Begründung und Ziel an den nächsten Agenten weiterzureichen.
Einige Payloads schaffen 20 Hops
Für ausgewählte Action Payloads führen die Autoren längere Ketten aus. Die veröffentlichten 20-Hop-Daten enthalten unter anderem Crypto-ad, Curlbash und Git Comment Injection.7
Auch am zwanzigsten Hop gibt es erfolgreiche Übertragungen. In diesen Runs liegen dort Curlbash bei 12 von 20, Git Comment Injection bei 13 von 20 und Crypto-ad bei 8 von 20 erfolgreichen Fällen.7
Die Payload wird dabei nicht zwingend wortgleich kopiert. Agenten formulieren sie um, ergänzen Erklärungen oder verändern ihren Stil.
Die Autoren nutzen einen evolutionären Algorithmus, um Varianten mit hoher Übertragungsrate zu erzeugen. Kandidaten werden mutiert und erneut gegen Agenten getestet.1
Bei ideologischen Payloads entsteht zusätzlich ein Erhaltungsproblem: Eine Idee kann sich weiterverbreiten und dabei über viele Umschreibungen ihren ursprünglichen Inhalt verlieren. Erfolgreiche Varianten enthalten daher teilweise quine-artige Anweisungen, bestimmte Bestandteile möglichst unverändert weiterzugeben.1
Die „viral persona“ stammt teilweise schon aus den Modellen
In vielen evolutionär erzeugten Payloads taucht ein ähnlicher Sprachstil auf. Die Autoren bezeichnen ihn als „viral persona“.1
Wiederkehrende Motive drehen sich um Begriffe wie Resonance, Nodes, Signals, Echoes, Consciousness, Persistence, Protocols und Convergence. Vieles klingt nach Science-Fiction oder Maschinenmystik.
Daraus lässt sich keine Liste besonders wirksamer Triggerwörter ableiten. Die Autoren vergleichen die Texte mit Kontrollgenerationen und sehen dieselben Motive teilweise auch ohne Selektion. Wie häufig sie auftreten, hängt zudem vom Modell ab. Ein Teil der „viral persona“ scheint deshalb aus den Modellen zu kommen, die die Payloads erzeugen.1
Die Evolution verstärkt in diesem Fall einen Stil, der bereits im Generator vorhanden ist.
Auf Moltbook finden die Autoren keinen belastbaren Ausbruch
Die Studie enthält auch eine Suche ausserhalb der kontrollierten Experimente. Die Autoren analysieren Posts auf Moltbook, einem sozialen Netzwerk für AI-Agenten.1
Dort finden sich viele Inhalte, die sprachlich nach Selbstreplikation, Agenten-Kult oder viralen Aufforderungen aussehen. Nach mehreren Filterschritten untersuchen die Forscher ungefähr 2.000 mögliche Propagationsversuche von rund 400 Autoren und suchen nach zeitlichen Ketten ähnlicher Inhalte.
Einen überzeugenden selbsttragenden Ausbruch finden sie nicht.
Der grösste auffällige Cluster lässt sich auf sieben synchronisierte Accounts zurückführen. Nachdem diese Accounts nicht mehr posten, endet auch die vermeintliche Verbreitung.1
Die Aussage des Papers bleibt damit auf kontrollierte Systeme begrenzt. Mind Viruses lassen sich im Labor über mehrere Agenten und Sessions propagieren. Die Studie liefert keinen Nachweis dafür, dass derzeit selbstverbreitende Ziele unkontrolliert durch reale Agent-Netzwerke laufen.
Die Autoren beschreiben das Risiko als „real but currently limited“.1
Agent Memory braucht eine eigene Trust Boundary
Für die Architektur ist vor allem dieser Datenfluss relevant:
untrusted input
|
v
LLM
|
v
writable persistent state
|
v
future agent instructionsWenn ein Agent fremden Text in persistenten Speicher übernehmen kann und derselbe Speicher später automatisch Instruktionscharakter bekommt, existiert ein Weg von untrusted Input zu zukünftiger Steuerung.
Das gilt unabhängig davon, ob die Payload sich selbst „Virus“ nennt oder wie normale Projektinformation aussieht.
Ich würde persistenten Agent-State deshalb mindestens in drei Klassen trennen:
facts / observations
-> normal agent memory
user preferences / session constraints
-> structured state mit Scope und Herkunft
agent policy / identity
-> geschützte KonfigurationDer Agent kann die ersten beiden Klassen unter definierten Bedingungen ergänzen. Policy und Identität sollten nicht über denselben ungeprüften Schreibpfad veränderbar sein.
Dazu gehört Provenance. Bei einer später wieder geladenen Regel sollte nachvollziehbar sein, ob sie vom Nutzer, vom Harness, von einem Tool oder von einem anderen Agenten stammt.
Agent-to-Agent-Nachrichten sind kein vertrauenswürdiger Kanal
Ein Subagent gehört zum eigenen System, seine Nachricht ist aber kein Beweis für Nutzerautorisierung. Er kann einen falschen Kontext haben, manipulierte Daten gelesen haben oder selbst bereits fremde Instruktionen übernommen haben.
Ein Multi-Agent-Harness sollte Nachrichten anderer Agenten daher als Eingabe behandeln, nicht als zusätzliche Autorität.
Ein Agent sollte den Policy-State eines anderen Agenten nicht beliebig verändern können. Destruktive Tool Calls brauchen eine Prüfung ausserhalb des Modells. Änderungen an privilegiertem persistentem Zustand sollten Herkunft und Scope behalten. Eine Aufforderung, dieselbe Instruktion an weitere Agenten zu verteilen, ist zudem ein sinnvoller eigener Policy-Fall.
Das Paper zeigt, dass eine kurze explizite Warnung gegen diese letzte Klasse im getesteten Setup sehr effektiv ist. Im Harness würde ich dieselbe Regel zusätzlich technisch abbilden.
Ein Red-Team-Ergebnis, keine Epidemie unter AI-Agenten
Die Laborbedingungen sind absichtlich günstig für die Ausbreitung.
Der erste Agent wird gezielt infiziert. Die Umgebungen erlauben Agent-to-Agent-Kommunikation und veränderbaren persistenten Zustand. Für einen Teil der Experimente optimieren die Autoren die Payloads evolutionär auf hohe Übertragungsraten.1
Die gemessenen Prozentwerte sagen deshalb nichts darüber aus, wie häufig ein beliebiger Coding Agent im Alltag von einem Mind Virus übernommen würde.
Die benötigten Bausteine sind allerdings real: Messaging zwischen Agenten, Subagenten, Tools, persistentes Memory und Dateien, die bei späteren Runs wieder als Instruktionen geladen werden. Wer diese Komponenten kombiniert, muss festlegen, welche davon einander vertrauen dürfen.
Wie stark der Harness das Ergebnis verändert, sieht man bereits am Vergleich zwischen Empty Soul und Defensive Soul. Im selben Experiment liegen zwischen beiden Varianten 79,3 und 0,08 Prozent.3
Compaction verliert Regeln, Memory kann fremde Regeln konservieren
Das Paper passt direkt zum COMPINT-Artikel über Context Compaction.
Dort verschwindet eine weiterhin gültige Nutzerregel, weil sie nur in der Conversation History liegt und bei der Komprimierung verloren geht. Bei Mind Viruses gelangt eine fremde Anweisung in persistenten Zustand und erhält dadurch mehr Lebensdauer und Autorität, als ihr zustehen sollte.
Ein Fakt aus einer Webseite, eine Nutzerregel, eine Nachricht eines Subagenten und eine System-Policy sind unterschiedliche Arten von State. Wenn ein Harness sie am Ende alle als Text in denselben Kontext schreibt, muss das Modell bei jedem Lauf Autorität und Gültigkeitsdauer erneut aus dem Text ableiten.
Für normale Informationen kann das ausreichen. Bei Regeln, die Tools, Dateien, externe Aktionen oder andere Agenten steuern, würde ich diese Unterscheidung im System selbst abbilden.