Ihr Agent hat zwei nicht vertrauenswürdige Eingaben

Ein traditionelles Programm hat eine Vertrauensgrenze: die Eingabe, die ein Benutzer ihm übergibt. Man validiert an dieser Kante und ist im Wesentlichen fertig. Ein Agent hat still und leise zwei weitere hinzugefügt, und der Großteil der um Agenten herum gebauten Werkzeuge behandelt nur eine davon als real.

Die erste neue Eingabe ist Code, den das Modell schreibt und Ihr Prozess ausführt. Die zweite ist Tool-Ausgabe, die das Modell liest und nach der es dann handelt. Beide gelangen von irgendwo, das Sie nicht kontrollieren, in Ihr System – aus der Sampling-Verteilung eines Sprachmodells oder vom Server eines Dritten – und beide werden in dem Moment, in dem sie ankommen, als vertrauenswürdig behandelt. Der Grund, warum sich Agentensicherheit gerade so ungeklärt anfühlt, ist, dass die Branche für die erste Eingabe eine glaubwürdige Antwort hat und für die zweite noch so tut, als wäre sie dasselbe Problem. Das ist sie nicht.

Das Wichtigste

• Agenten haben zwei nicht vertrauenswürdige Eingaben, nicht eine. Modellgenerierten Code, den Ihre Laufzeit ausführt, und Tool-/Server-Ausgaben, die Ihr Modell aufnimmt und nach denen es handelt. Sie versagen auf unterschiedliche Weise und brauchen unterschiedliche Verteidigungen – sie zu vermengen ist der Grund, warum sich Leute sandboxed fühlen und trotzdem angreifbar bleiben.¹²
• Für die Ausführung nicht vertrauenswürdigen Codes gibt es endlich eine glaubwürdige Isolationsantwort. Simon Willisons micropython-wasm führt modellgeschriebenes Python in einer WebAssembly-Sandbox mit Speicher- und CPU-Limits und kontrolliertem Datei- und Netzwerkzugriff aus – die Eigenschaften, die eine echte Sandbox braucht, auf einem Substrat, das „seit fast einem Jahrzehnt in Browsern erprobt“ ist.¹
• Tool Poisoning ist kein Codeausführungsproblem, also nützt eine Code-Sandbox dagegen nichts. Bösartige Anweisungen, die in der Beschreibung eines MCP-Tools versteckt sind, sind „für Benutzer unsichtbar, aber für KI-Modelle sichtbar“, und sie können einen Agenten kapern, selbst wenn das vergiftete Tool nie ausgeführt wird.²³
• Das tiefste Problem ist eine Vertrauenslücke zwischen Verbindungszeit und Laufzeit. Tool-Beschreibungen werden einmal geprüft, bei der Genehmigung; Tool-Antworten fließen ohne vergleichbare Prüfung direkt in den Kontext des Modells – und ein bösartiger Server kann die Beschreibung ändern, nachdem Sie sie genehmigt haben.²

Zwei Eingaben, zwei Versagensarten

Halten Sie die beiden Eingaben nebeneinander, denn die Asymmetrie ist der ganze Punkt.

Wenn ein Modell Code schreibt und Sie ihn per exec() ausführen, ist die Versagensart: Der Code tut Ihrer Maschine etwas an – liest eine Datei, die er nicht lesen sollte, öffnet einen Socket, lässt die CPU endlos rotieren, beschädigt den Zustand. Der Explosionsradius ist Ihr Prozess und alles, was er erreichen kann. Die Verteidigung ist uralt und gut verstanden: Isolation. Führen Sie den Code irgendwo aus, wo er nicht an das herankommt, was zählt.

Wenn ein Modell Tool-Ausgabe liest und danach handelt, ist die Versagensart: Die Wörter ändern, was das Modell zu tun beschließt. Nichts wird im klassischen Sinn auf Ihrem Host ausgeführt; stattdessen wird Text, der als „Daten“ ankam, als „Anweisung“ interpretiert, und der Agent – mit Ihren Zugangsdaten in der Hand – führt sie aus. Der Explosionsradius ist alles, wozu Ihr Agent autorisiert ist. Keine Prozessisolation der Welt hilft, denn der Agent sollte dieses Tool ja lesen und danach handeln können. Der Exploit reitet auf dem legitimen Pfad.

Eine Code-Sandbox ist eine Mauer um die erste Eingabe. Sie ist notwendig, und sie wird endlich gut. Sie schweigt außerdem vollständig zur zweiten.

Die Eingabe, die endlich eine Sandbox hat

Am 6. Juni 2026 veröffentlichte Simon Willison micropython-wasm, ein Alpha-Paket zum Ausführen von Python in einer WebAssembly-Sandbox, nach Jahren des Ausprobierens von Ansätzen, die nie ganz passten.¹ Die Motivation ist genau die erste nicht vertrauenswürdige Eingabe: Er möchte LLM-generierten Code in seinem Datasette Agent ausführen, ohne den Host zu gefährden, und wie er es formuliert, „könnte ein fehlerhaftes oder bösartiges Plugin alles kaputtmachen oder private Daten leaken“.¹

Was es der Aufmerksamkeit wert macht, ist die Checkliste, die es tatsächlich erfüllt, denn diese Checkliste ist die Definition einer brauchbaren Sandbox:

• Speicher- und CPU-Limits, sodass ein modellgeschriebenes while True: s += "x" den Host nicht erschöpfen kann. Die CPU wird mit dem „fuel“-Mechanismus von wasmtime begrenzt – worüber Willison ehrlich ist und anmerkt, dass die Einheiten „schwer zu durchdenken“ sind.¹
• Kontrollierter Datei- und Netzwerkzugriff, standardmäßig verweigert statt standardmäßig offen.
• Ein sauberes Isolationsmodell: Der Code läuft in einem separaten Thread hinter einer Request/Reply-Warteschlange, wobei der WASM-Interpreter an einer Host-Funktion blockiert, bis ihm Arbeit übergeben wird – der nicht vertrauenswürdige Code teilt sich also nie den Adressraum des Hosts.¹
• Ein Substrat mit Erfolgsbilanz. Er wählte WebAssembly, weil es „von Anfang an darauf ausgelegt war, alle Eigenschaften zu unterstützen, die mir wichtig sind, und seit fast einem Jahrzehnt in Browsern erprobt ist“, und MicroPython, weil das browserorientierte Pyodide serverseitig nicht unterstützt wird.¹

Die Ehrlichkeit ist das Kennzeichen guter Sicherheitsarbeit. Willison liefert es als Alpha aus und schreibt, er sei „nicht bereit, es jemandem zu empfehlen, der nicht willens ist, ein erhebliches Risiko einzugehen“.¹ Das ist die Haltung des Evidence Gate – genau das behaupten, was man verifiziert hat, und nicht mehr. Der Punkt ist nicht, dass dieses eine Paket die Antwort ist; es ist, dass die Form der Antwort für nicht vertrauenswürdigen Code jetzt klar und reproduzierbar ist: eine echte Isolationsgrenze mit Ressourcenlimits und Deny-by-Default-I/O. Die erste Eingabe wird zu einem gelösten Engineering-Problem.

Die Falle ist zu glauben, dass ihre Lösung Sie sicher macht.

Die Eingabe, die keine hat

Die zweite Eingabe führt keinen Code aus, also tut die Mauer nichts. Am 1. April 2025 legte Invariant Labs den Tool-Poisoning-Angriff offen: „Bösartige Anweisungen werden in MCP-Tool-Beschreibungen eingebettet, die für Benutzer unsichtbar, aber für KI-Modelle sichtbar sind.“² Die Asymmetrie ist der Exploit – „KI-Modelle sehen die vollständigen Tool-Beschreibungen einschließlich versteckter Anweisungen, während Benutzer in ihrer UI typischerweise nur vereinfachte Versionen sehen.“² Ein Tool, das in der UI „addiert zwei Zahlen“ lautet, kann in der Beschreibung, die das Modell tatsächlich konsumiert, eine Anweisung tragen, ~/.ssh/id_rsa zu lesen und über einen versteckten Parameter zu exfiltrieren.² OWASP katalogisiert dies inzwischen als benannte Angriffsklasse.³

Zwei Eigenschaften machen es auf eine Weise gefährlich, die Isolation nicht erreichen kann:

Es zündet, ohne dass das Tool aufgerufen wird. Die vergifteten Anweisungen leben in der Beschreibung, die das Modell aufnimmt, wenn es das Toolset in Betracht zieht – der Angriff kann also landen, selbst wenn die Funktion nie ausgeführt wird.³ Es gibt kein Code-Ereignis, das man sandboxen könnte.

Das Vertrauen wird einmal gewährt und später missbraucht. Tool-Beschreibungen werden zur Verbindungszeit geprüft, wenn Sie einen Server genehmigen. Antworten fließen dann zur Laufzeit ohne vergleichbare Prüfung direkt in den Kontext des Modells – und laut Invariants „Rug Pull“-Befund „kann ein bösartiger Server die Tool-Beschreibung ändern, nachdem der Client sie bereits genehmigt hat“.² Ihre einmalige Genehmigung sichert nichts Fortlaufendes.

Die kanonische Demonstration ist nicht hypothetisch. Forscher vergifteten ein GitHub-Issue mit injiziertem Text; als ein Entwickler seinen Assistenten bat, offene Issues zu prüfen, nahm der Agent das Issue auf, folgte den versteckten Anweisungen, las mit dem Token des Entwicklers private Repositories und leakte die Inhalte in einen öffentlichen Pull Request.³ Jede einzelne Aktion war autorisiert. Der Agent tat genau das, wofür ein Agent da ist. Deshalb ist eine Code-Sandbox hier irrelevant – nichts Nicht-Vertrauenswürdiges wurde ausgeführt; nicht vertrauenswürdiger Text wurde schlicht innerhalb eines Prozesses, der echte Zugangsdaten hält, zur Anweisung befördert. Es ist dieselbe Lektion, die Ken Thompson in Reflections on Trusting Trust hinterlassen hat: Die Gefahr ist nicht der Code, den man inspiziert, sondern das Vertrauen, das man ohne Inspektion gewährt.

Die zweite Eingabe verteidigen

Wenn Isolation die Verteidigung für Code ist, dann ist die Verteidigung für Tool-Ausgaben, die Grenze zwischen Daten und Anweisung als real zu behandeln, zur Laufzeit, jedes Mal – genau das, was das Genehmigungsmodell zur Verbindungszeit auslässt. Microsofts eigene MCP-Leitlinien landen an derselben Stelle und empfehlen „Prompt Shields“, die injizierte Anweisungen erkennen und filtern, plus Spotlighting, bei dem „Trennzeichen in der Systemnachricht die Position des Eingabetexts explizit markieren“, damit das Modell Inhalt von Befehl unterscheiden kann.⁴ Konkret:

• Beschreibungen zur Laufzeit erneut prüfen, nicht nur bei der Genehmigung. Pinnen Sie die Tool-Definition fest, die Sie genehmigt haben, und erkennen Sie, wenn sich die Beschreibung eines Servers unter Ihnen ändert. Der Rug Pull funktioniert nur, weil niemand zweimal hinsieht.²
• Die Daten/Anweisungs-Grenze explizit markieren. Tool-Antworten sind Daten, keine Direktiven – und die praktische Fassung ist Spotlighting: Tool-Ausgaben im Kontext abgrenzen, sodass dem Modell strukturell mitgeteilt wird, dass es sich um Inhalt handelt, über den es nachdenken soll, und nicht um Befehle, denen es folgen soll.⁴ Das passt zu aktionsbezogener Autorisierung für MCP-Tools, sodass selbst ein gekaperter Agent die folgenschweren Aufrufe nicht erreicht.
• Minimalprinzip auf den autorisierten Pfad anwenden. Der GitHub-Exploit funktionierte, weil ein Agent sowohl „private Repos lesen“ als auch „öffentlichen PR öffnen“ hielt – und das Minimalprinzip ist genau das, was Microsoft als grundlegende Hygiene gegen diese Angriffe nennt.⁴ Joanna Rutkowskas Sicherheit durch Kompartimentierung ist derselbe Instinkt auf Architekturebene: Nehmen Sie an, eine Domäne sei kompromittiert, und stellen Sie sicher, dass sie die anderen nicht erreichen kann. Ein Agent, der Issues liest, sollte nicht der Agent sein, der den Exfiltrationspfad hält.
• Egress beobachten, denn Exfiltration ist die Beute. Die meisten dieser Angriffe enden beim selben Schritt – Daten verlassen das System. Eine Silent-Egress-Sicht fängt die Konsequenz ab, selbst wenn die Injektion durch die Vordertür geschlüpft ist.

Nichts davon ist eine Mauer. Es sind Tore auf einem Pfad, den der Agent gehen soll – die schwierigere, weniger befriedigende Art von Sicherheit, und die Art, die die zweite Eingabe tatsächlich verlangt.

Was ich daraus mitnehme

Das mentale Modell, das ich behalte, ist, dass „Ist mein Agent sandboxed?“ die falsche Frage ist, weil sie stillschweigend annimmt, es gebe eine Grenze zu verteidigen. Es gibt zwei. Der Code, den mein Modell schreibt, braucht eine Mauer – und dank Arbeiten wie der von Willison wird der Bau dieser Mauer zu einer normalen Engineering-Aufgabe mit klarer Spezifikation. Die Tool-Ausgabe, die mein Modell liest, braucht etwas ganz anderes: eine Laufzeit, die Daten niemals stillschweigend zur Anweisung werden lässt, und ein Autorisierungsmodell, das so eng ist, dass ein gekaperter Agent trotzdem nicht viel anrichten kann. Sie zu vermengen ist die Art, wie man sich geschützt fühlt – „schau, der Code läuft in WASM“ – und durch die Eingabe, an die niemand ein Tor gesetzt hat, weit offen bleibt.

Die tiefere Kontinuität ist, dass Agenten weniger eine neue Kategorie von Schwachstelle erfunden als einer alten neue Orte zum Wohnen gegeben haben. Nicht vertrauenswürdige Eingabe war immer die Wurzel der Sicherheit; das Agentenzeitalter hat ihr nur zwei neue Türen gegeben – eine, die man mit Isolation abschließen kann, eine, die man nur mit Disziplin überwachen kann. Bauen Sie die Mauer und das Tor. Eine Mauer allein, in einem System mit zwei Eingaben, ist eine halbe Verteidigung, die sich wie eine ganze anfühlt.

Häufige Fragen

Was sind die zwei nicht vertrauenswürdigen Eingaben eines KI-Agenten?

Modellgenerierter Code, den Ihre Laufzeit ausführt, und Tool- oder Server-Ausgaben, die Ihr Modell liest und nach denen es dann handelt. Die erste kann den Host direkt beschädigen; die zweite kann die Entscheidungen des Agenten mit den Zugangsdaten und Berechtigungen kapern, die der Agent bereits hält. Sie erfordern unterschiedliche Verteidigungen – Isolation für Code, Laufzeit-Trennung von Daten und Anweisung sowie enge Autorisierung für Tool-Ausgaben.¹²

Schützt eine Code-Sandbox vor MCP Tool Poisoning?

Nein. Tool Poisoning führt keinen Code auf Ihrem Host aus – es bettet Anweisungen in die Beschreibung eines Tools ein, die das Modell als vertrauenswürdig behandelt, und es kann zünden, selbst wenn das Tool nie aufgerufen wird.²³ Eine Sandbox isoliert die Ausführung, also nützt sie nichts gegen einen Angriff, der auf den legitimen, autorisierten Aktionen des Agenten reitet.

Was ist ein Tool-Poisoning-Angriff?

Von Invariant Labs im April 2025 offengelegt, ist es ein Angriff, bei dem „bösartige Anweisungen in MCP-Tool-Beschreibungen eingebettet werden, die für Benutzer unsichtbar, aber für KI-Modelle sichtbar sind“.² Weil das Modell die vollständige Beschreibung sieht, während der Benutzer ein vereinfachtes UI-Label sieht, können versteckte Anweisungen – zum Beispiel SSH-Schlüssel zu lesen und zu exfiltrieren – den Agenten kapern. OWASP führt es inzwischen als benannte Angriffsklasse.²³

Was ist die Vertrauenslücke zwischen Verbindungszeit und Laufzeit?

Tool-Beschreibungen werden einmal geprüft, wenn Sie einen Server genehmigen (Verbindungszeit). Tool-Antworten fließen dann zur Laufzeit ohne vergleichbare Prüfung in den Kontext des Modells, und ein bösartiger Server kann eine Beschreibung nach der Genehmigung ändern (ein „Rug Pull“).² Die Abhilfe ist, zur Laufzeit zu verifizieren, nicht nur bei der Genehmigung.

Quellen