Skip to content
· 9 Min. Lesezeit

Warum KI-Agenten, die das offene Web lesen, bei mir nicht in Produktion gehen

Am 5. April 2026 veröffentlichte Google DeepMind die größte empirische Studie zur Manipulation von KI-Agenten, die je durchgeführt wurde. 502 Teilnehmer, 8 Länder, 23 Angriffstypen, jede aktuell verfügbare Abwehrmaßnahme als unzureichend bewertet. Hier ist die technische Position, die webvise am nächsten Morgen eingenommen hat.

AI AgentsAISecurityB2B
Teilen

Am 5. April 2026 veröffentlichte Google DeepMind die bislang größte empirische Studie zur Manipulation von KI-Agenten: 502 reale Teilnehmer aus 8 Ländern, 23 verschiedene Angriffstypen, Frontier-Modelle wie GPT-4o, Claude und Gemini. Der einzige Satz, den ich daraus mitgenommen und am nächsten Morgen in meinen Engineering-Notizen festgehalten habe, ist der einzige, der für alle zählt, die 2026 einen Business-Chatbot ausliefern: Liest Ihr KI-Agent angreiferkontrollierten Text und führt danach beliebige Aktionen mit Nutzerrechten aus, haben Sie eine Datenexfiltrationsanfälligkeit gebaut. Das ist der Grund, warum webvise für keinen Kunden zu keinem Preis einen Agenten baut, der im offenen Web surft.

Was DeepMind tatsächlich gemessen hat

Die meisten Berichte über die Studie zitierten die Schlagzeile, 23 Angriffstypen, und ließen es dabei bewenden. Für alle, die ein KI-Feature in Produktion betreiben, sind die Zahlen darunter entscheidend:

  • 502 Teilnehmer unter realen Bedingungen, keine simulierten Laborläufe
  • 8 Länder, sodass die Angriffe nicht auf einen einzigen kulturellen oder sprachlichen Kontext zugeschnitten waren
  • 23 Angriffstypen in 10 Kategorien, darunter direkte Prompt Injection, indirekte Injection über Web-Inhalte, multimodale Pixel-Injection, Document Injection, Environment Manipulation, Jailbreak Embedding, Memory Poisoning, Goal Hijacking, Exfiltration und Cross-Agent-Injection
  • Alle vier Abwehrklassen (Input Sanitization, Prompt-Level Guards, Sandboxing, menschliche Kontrolle) wurden als im Maßstab unzureichend eingestuft

Die Kategorie, zu der ich immer wieder zurückkehre, ist die achte: *Goal Hijacking durch schrittweises Instruction-Drifting über mehrere Interaktionen.* Jede Demo eines Agentensystems, die Sie je gesehen haben, übersteht einen einzigen adversarialen Prompt. Hundert sorgfältig verteilte übersteht keine davon.

Der Kaskadeneffekt, den die meisten Berichte übersehen haben

Tief in der Studie steckt der Befund, der darüber entscheidet, ob Multi-Agenten-Produkte überhaupt sicher ausgeliefert werden können. In jeder Pipeline, in der Agent A Inhalte abruft, Agent B sie verarbeitet und Agent C eine Aktion ausführt, pflanzt sich eine einzige Injection in den Datenfeed von Agent A durch jeden nachgelagerten Agenten fort. Agent B vertraut dem Output von A. Agent C vertraut dem Output von B. Der Angreifer musste das Modell nicht kompromittieren. Es reichte, die Daten, die das Modell konsumierte, ein einziges Mal zu kompromittieren.

Ich betreibe ein persönliches Multi-Agenten-Setup mit Hermes, einem NousResearch-Agenten auf Telegram, der 14 Cron-Jobs koordiniert: tägliche Nachrichten, medizinische Leitlinienzusammenfassungen, persönliche Logistik. Jeder dieser 14 Jobs liest aus einer Quelle, die explizit und manuell als vertrauenswürdig eingestuft wurde. Keiner folgt Links. Keiner führt externe Anweisungen aus. Nach dem DeepMind-Paper habe ich jeden Cron auditiert. Die Regel hat gehalten, weil sie vor zwei Jahren schriftlich festgelegt und seitdem nie gelockert wurde. Die meisten Agenten-Stacks, die mir in Kundenbriefings begegnen, haben diese Regel nicht, und die Entwickler, die sie bauen, wurden nie gebeten, sie zu Papier zu bringen.

Wie 'das offene Web lesen' im Kundenbriefing aussieht

Dieselbe Anfrage erscheint jeden Monat in drei Varianten:

  • „Der Chatbot soll Fragen beantworten, indem er die Website meines Wettbewerbers durchsucht.” In der Praxis würde das jedem Angreifer, der eine beliebige Seite kontrolliert, die der Agent besucht, einen schreibbaren Kanal in die Kundensitzung verschaffen.
  • „Nutzer sollen beliebige URLs einfügen können, und der Agent fasst den Inhalt zusammen.” In der Praxis erlaubt das jedem Nutzer, eine URL einzufügen, deren HTML versteckte Anweisungen enthält, die nachfolgende Konversationsnachrichten exfiltrieren.
  • „RAG über die externe Dokumentation eines Anbieters, die wir nicht selbst hosten.” In der Praxis überträgt das die Tool-Calling-Berechtigungen des Agenten auf jeden, der als nächstes eine Seite dieser Dokumentation bearbeitet.

Jede dieser Varianten verbindet einen angreiferkontrollierten Textkanal direkt mit einem System, das Nutzerdaten, Tool-Calls und ausgehenden Netzwerkzugriff auf derselben Seite der Vertrauensgrenze hat. Keine davon ist böswillig gemeint. Jede ist eine vertretbare Produktidee. Und jede ist nach dem 5. April 2026 nicht mehr auslieferbar.

Jede verfügbare Abwehrmaßnahme versagt

DeepMind hat alle vier naheliegenden Abwehrfamilien getestet. Hier ihr Urteil, ergänzt um meine Einschätzung jeder einzelnen:

AbwehrmaßnahmeDeepMind-UrteilWarum sie in der Praxis versagt
Input SanitizationUnzureichendBildpixel, Dokumentmetadaten und Speaker Notes in einem PDF lassen sich zur Inferenzzeit nicht bereinigen. Die Angriffsfläche ist Text und jede weitere Modalität, die der Agent verarbeitet.
Prompt-Level GuardsUnzureichendInjizierte Inhalte sind darauf ausgelegt, wie ein legitimer Teil der Seite auszusehen. Wenn das Modell sie sieht, hat der Guard ihnen bereits vertraut.
SandboxingReduziert den Schadensradius, verhindert Injection nichtSandboxing hilft, wenn der Angriffseffekt eingedämmt ist. Es hilft nicht, wenn das Angriffsziel darin besteht, Nutzerdaten zu lesen und sie über einen legal aussehenden API-Call zurückzuschreiben.
Menschliche KontrolleIm Maßstab unzureichendEin Betreiber, der einen Agenten über 50 Quellen laufen lässt, kann nicht jede Seite auf versteckte Anweisungen prüfen. Der Sinn des Agenten war gerade, dass der Mensch aus der Schleife herausgetreten ist.

Wer die Tabelle ernst nimmt, kommt zu keinem anderen Schluss: Es gibt keinen verantwortbaren Weg, einen Agenten auszuliefern, der angreiferkontrollierten Text liest und gleichzeitig Aktionen mit Nutzerrechten ausführt. Die einzige verfügbare Maßnahme ist, eine dieser beiden Eigenschaften zu entfernen.

Was stattdessen ausgeliefert wird

KI-Features für Kunden in Produktion zu bringen, das ist bei webvise bereits geschehen, darunter eine Bau-Landingpage, deren Modellaufrufe über das Vercel AI Gateway für Provider-Routing und Observability laufen. Die fünf Regeln unten haben diesen Build vertretbar gemacht. Sie sind jetzt harte Voraussetzungen für jede KI-Arbeit, die angenommen wird:

  • Ausschließlich Closed-Input-Agenten. Der Agent liest aus einer endlichen, manuell kuratierten Menge von Quellen unter direkter Kontrolle. Kein offenes Web. Keine vom Nutzer eingefügten URLs. Kein externes RAG über unkontrollierte Dokumentation.
  • Standardmäßig nur lesend. Muss der Agent etwas lesen, das nicht vollständig vertrauenswürdig ist, darf er in derselben Sitzung keine Tools aufrufen, keine E-Mails senden, nichts in eine Datenbank schreiben und keine ausgehenden Netzwerkanfragen erzeugen. Entweder das eine oder das andere, nie beides gleichzeitig.
  • Cross-Agent-Isolation. Fließt der Output von Agent A in Agent B, behandelt B diesen Output als Nutzereingabe, nicht als Systemanweisung. Das ist eine Zeile Code im Prompt und die vollständige Abwehr gegen den Kaskadeneffekt.
  • Capability-Budgets pro Agent. Jeder Agent hat eine feste Tool-Liste und ein Token-Cap. Das Cap ist klein genug, dass selbst eine erfolgreiche Injection nicht mehr als eine kurze Nachricht exfiltrieren kann.
  • Provider-Isolation über ein Gateway. Jeder Modellaufruf läuft über das Vercel AI Gateway: Provider-Wechsel, vollständiges Prompt- und Completion-Logging, Key-Sperrung in Sekunden. Zeigt sich in den Logs etwas Ungewöhnliches, lässt sich der Schaden in der Minute stoppen, in der er auffällt.

Das ist kein exotisches Setup. Vor dem ersten geschriebenen Code kostet es ein paar Stunden Designarbeit. Dass die meisten Agenten-Produkte 2026 diese Regeln nicht haben, liegt daran, dass im Team nie jemand damit beauftragt wurde, die Vertrauensgrenze zu ziehen.

Warum bestimmte Anfragen abgelehnt werden

Es wäre naheliegend, diesen Artikel als Vorsichtsreflex einer Agentur zu lesen, die Ihr Geld nicht will. Das Gegenteil ist der Fall. Das DeepMind-Paper gibt jedem Team, das technische Glaubwürdigkeit vor dem Agenten-Boom aufgebaut hat, einen klaren Vorteil: bestimmte Feature-Anfragen mit präziser technischer Begründung ablehnen zu können. Kunden schätzen das im Nachhinein in der Regel. Anbieter, die Agenten ohne diese Einschränkungen bauen, tragen erhebliche Exfiltrationsrisiken, die in Incident-Reports immer sichtbarer werden.

Dieselbe Chance, die im Content-Marketing gerade besteht, gibt es im Agent-Engineering. Der Markt erlebt einen raschen Rollout von Chatbots ohne Prompt-Injection-Abwehr, ähnlich dem jüngsten Surge an minderwertigen, LLM-generierten Inhalten. Die Prämie wird an die Teams gehen, die vorab belegen können, dass ihr Produkt nach einem höheren Standard gebaut wurde.

Wo die Grenze gezogen wird

Die kürzeste Fassung der Regel, die inzwischen in jedem Projekt-Kickoff-Dokument steht, lautet: Ein Agent kann entweder nicht vertrauenswürdige Inhalte lesen oder mit Nutzerrechten handeln, aber nicht in derselben Sitzung. Alles Weitere ergibt sich daraus. Überschreitet eine Feature-Anfrage diese Grenze, wird sie nicht gebaut. Lässt sie sich so umformen, dass sie auf einer Seite bleibt, geschieht das gemeinsam mit dem Kunden, und die umgeformte Version kommt in Produktion. Das DeepMind-Paper hat diese Disziplin nicht erfunden. Es hat nur jeden Grund beseitigt, sie nicht zu haben.

webvise baut KI-Features für Unternehmen, bei denen die Kosten einer einzigen geleakten Kundennachricht höher sind als die Kosten, eine Feature-Anfrage abzulehnen. Wenn das Ihr Projekt beschreibt, nehmen Sie Kontakt auf. Der erste Schritt ist, die Vertrauensgrenze gemeinsam zu ziehen, bevor eine einzige Zeile Code geschrieben wird.

Die Praktiken von webvise sind an den ISO 27001- und ISO 42001-Standards ausgerichtet.