Prompt Injection: Warum Agenten-Sicherheit härter wird

Im März 2026 veröffentlichte Unit 42 den ersten öffentlich bestätigten Fall, in dem indirekte Prompt Injection gegen einen KI-basierten Ad-Review-Prozess gerichtet war: Präparierte Inhalte auf einer verlinkten Zielseite sollten ein automatisiertes Prüfsystem dazu bringen, eine betrügerische Anzeige freizugeben. Kein Zero-Day im klassischen Sinn. Keine RCE. Nur Text, den der Agent als Anweisung interpretieren sollte.

Das ist der Moment, ab dem sich die Debatte verschiebt. Prompt Injection war jahrelang das Spielzeugproblem der Sicherheitsforschung, ein Nebenschauplatz zu Halluzinationen und Copyright. 2026 ist es die operative Achillesferse jeder Agenten-Architektur, die drei Dinge gleichzeitig tut: unvertrauenswürdige Inhalte lesen, sensitive Systeme berühren, Zustand nach aussen ändern. Genau diese Kombination lässt sich im aktuellen LLM-Paradigma nicht zuverlässig absichern. Bessere System-Prompts, Guardrails und Fine-Tuning senken das Risiko, beseitigen es aber nicht.

Die Grundlage dafür ist die Frage, warum LLM-Guardrails bei Prompt Fuzzing und indirekter Prompt Injection nur begrenzt tragen. Auf Agentenebene kommen Tool-Rechte, Memory, Retrieval und externe Zustandsänderungen hinzu. Sobald ein manipulierbares Modell handeln darf, verschiebt sich die Sicherheitsfrage zu Architektur: Trust-Zonen, begrenzte Fähigkeiten, unabhängige Policies.

Der Framing-Fehler bei Prompt Injection

Der Name führt in die Irre. Wer «Prompt Injection» hört, denkt an einen bösartigen Nutzer, der schlaue Zeichenfolgen in ein Chatfenster tippt. Das ist die klassische, direkte Variante. Sie ist besser testbar und besser adressierbar als indirekte Prompt Injection, aber nicht gelöst: LLM-Jailbreaking und automatisiertes Prompt Fuzzing zeigen, dass Filter, Systemprompts und RLHF-Härtung unter adversarialem Druck weiterhin brechen.

Das eigentliche Problem sitzt eine Etage tiefer und heisst indirekte Prompt Injection (IPI). Google Threat Intelligence beschreibt IPI als Angriffsvektor gegen komplexe KI-Anwendungen mit mehreren Datenquellen: Der Angriff kommt aus externem Inhalt, den das Modell während einer Aufgabe verarbeitet. Zwischen November 2025 und Februar 2026 hat Google beim Scan des CommonCrawl-Korpus einen relativen Anstieg der Kategorie «malicious» um 32 Prozent gemessen. Und das ist der konservative Boden: CommonCrawl erfasst weder Social Media noch die geschlossenen Datenräume, in denen Enterprise-Agenten tatsächlich arbeiten.

Der Punkt: Sobald ein Agent eine Webseite zusammenfasst, ein PDF liest, eine E-Mail parst oder ein Ticket auswertet, wird der Inhalt Teil des Kontextfensters. Und das Kontextfenster ist die einzige Realitätsebene, die das Modell kennt. Ob eine Zeile aus dem System-Prompt kommt, aus der Nutzerfrage oder aus einem Kommentar auf Seite 47 des angehängten PDFs, ist für die Aufmerksamkeitsmechanik des Transformers strukturell schwer trennbar.

Das ist der zentrale Framing-Fehler der Branche: Prompt Injection wird als Eingabeproblem behandelt, als wäre es SQL-Injection mit besserer Grammatik. Es ist aber ein Architekturproblem. SQL-Injection lässt sich durch Prepared Statements deterministisch beseitigen, weil SQL eine formale Grammatik hat und Daten von Code trennbar sind. Bei LLMs gibt es diese Trennung nur als Konvention im Prompt.

Was die Anbieter zugegeben haben und was das bedeutet

Der entscheidende Befund steckt inzwischen in den Sicherheitsveröffentlichungen der Anbieter. OpenAI nennt Prompt Injection eine langfristige Herausforderung für Agenten-Sicherheit und schreibt, das Problem werde ähnlich wie Betrug und Social Engineering im Web voraussichtlich nicht vollständig «gelöst». Anthropic formuliert es ähnlich nüchtern: Selbst eine auf rund ein Prozent gedrückte Erfolgsrate bleibt bei Browser-Agenten ein relevantes Risiko, und kein Browser-Agent sei immun. Google beschreibt IPI als wachsenden Angriffsvektor gegen Anwendungen mit mehreren Datenquellen. Die Wortwahl variiert, der Kern ist identisch: Solange Instruktionen und Daten im gleichen Token-Strom fliessen, bleibt die Angriffsfläche.

Für die Sicherheitsdebatte ist das ein Bruch. Bislang liess sich jeder Vorfall mit dem Versprechen wegmoderieren, das nächste Modell werde robuster sein. Diese Rhetorik ist tot. Was jetzt bleibt, sind zwei ehrliche Optionen: Architekturen bauen, die von manipulierbaren Modellen ausgehen, oder auf Use-Cases verzichten, in denen Manipulation nicht tragbar ist.

Die Konsequenz daraus: Guardrails sind ein Türvorhang, keine Stahltür. Für Agenten gilt das verschärft. Schutzschichten auf Modell-Ebene sehen den Angriff oft gar nicht, weil er im Tool-Output steht, den der Agent zwischen zwei Reasoning-Schritten einliest.

Warum Agenten das Problem eskalieren

Ein Chatbot kann halluzinieren, beleidigen, urheberrechtlich zweifelhaften Text produzieren. Ein Agent kann Geld überweisen, Code committen, Kalender verändern, Mails versenden, Cloud-Ressourcen provisionieren. Der Blast Radius eines gekaperten Agenten ist um Grössenordnungen höher als der eines gekaperten Chatbots.

Konkret dokumentiert sind:

• EchoLeak (CVE-2025-32711): Zero-Click-Datenexfiltration aus Microsoft 365 Copilot. Die NVD beschreibt den Fehler als AI command injection in M365 Copilot, die einem nicht autorisierten Angreifer Informationsabfluss über das Netzwerk erlaubte. Der Punkt für Agenten-Architekturen: Schon ein Kommunikationskanal wie E-Mail kann zum Auslöser werden, wenn der Agent ihn autonom verarbeitet.
• Persistent Memory Poisoning in Amazon Bedrock Agents: Unit 42 demonstrierte dies ausdrücklich als PoC, nicht als beobachteten Feldangriff. Der Mechanismus ist trotzdem gefährlich: Eine eingeschleuste Instruktion landet in der Langzeit-Memory-Zusammenfassung und beeinflusst spätere Sessions.
• Coding-Agenten via MCP-Tool-Beschreibungen kompromittiert: Invariant Labs beschrieb Tool Poisoning als Angriff, bei dem bösartige Instruktionen in MCP-Tool-Beschreibungen stecken, für Nutzer unsichtbar, für Modelle sichtbar. Wer Agenten-Infrastruktur baut, sollte den MCP-Standardkampf mit dieser Brille noch einmal durchlesen.

Dazu kommt die RAG-Schicht. Die Schwachstelle liegt dort besonders oft vor dem Modell: im Corpus, in den Retrieval-Regeln und in der Frage, welche Dokumente überhaupt als vertrauenswürdig gelten. Ein Agent muss die manipulierte Instruktion nicht in seiner Basiskonversation sehen. Es reicht, wenn Retrieval sie passend zur Nutzerfrage nach oben spült.

Eine Untersuchung mit MCP-Servern (arxiv 2504.03767) zeigt, wie brüchig die Modellschicht daneben aussieht: Die Autoren berichten über drei Angriffsklassen gegen MCP-gestützte Workflows: Malicious Code Execution, Remote Access Control und Credential Theft. Der praktische Befund ist weniger, dass ein bestimmtes Modell «kaputt» ist. Gefährlich ist die Kombination aus natürlicher Sprache, Tool-Rechten und automatischer Ausführung.

Die Rule of Two: das erste ehrliche Sicherheitsmodell

Meta hat mit der Agents Rule of Two eine Heuristik in die Diskussion gebracht, die für 2026 die pragmatischste Positionsbestimmung bleibt.

Ein Agent hat drei potenzielle Eigenschaften:

1. Er verarbeitet unvertrauenswürdige Eingaben (Web, E-Mail, PDFs, Tickets, User-Content).
2. Er greift auf sensitive Systeme zu (interne Datenbanken, Secrets, Kundendaten).
3. Er ändert extern Zustand (Zahlungen, Commits, Nachrichten, API-Calls mit Nebenwirkung).

Zwei davon sind mit heutiger Technik verteidigbar. Alle drei gleichzeitig sind es in der Praxis nicht, ausser man akzeptiert Human-in-the-Loop bei jeder konsequenzreichen Aktion. Das ist keine akademische Formel, sondern eine Architekturregel für jedes Produkt-Whiteboard.

Die produktive Übersetzung: Ein Agent, der das offene Web liest, darf nicht gleichzeitig auf interne Secrets zugreifen und autonom Mails versenden. Ein Agent, der interne Daten liest und schreibt, darf keine externen Inhalte parsen. Wer alle drei Modi will, braucht entweder eine architektonische Trennung in mehrere Agenten mit unterschiedlichen Trust-Levels oder eine Human-Approval-Stufe vor jeder externen Aktion.

Was jenseits von Guardrails wirklich hilft

Wer Agenten produktiv betreibt, kommt an einer mehrschichtigen Verteidigung nicht vorbei. Der Ausdruck ist abgenutzt, aber im Kontext von Prompt Injection hat er 2026 eine konkrete Form angenommen.

Capability-basierte Isolation. Solche Ansätze verschieben die Sicherheitsgarantie aus dem Modell heraus in die Ausführungsumgebung. Der Agent erhält nur Fähigkeiten, die explizit erlaubt sind, und Datenflüsse zwischen Trust-Zonen werden kontrolliert. Der Vorteil: Garantien, die stärker sind als «das Modell wird sich schon richtig entscheiden». Der Preis: Usability-Einbussen, weil viele nützliche Agent-Muster genau von der lockeren Verkettung leben.

Sandboxing für alles, was ausführt. Die OWASP Top 10 für Agentic Applications vom Dezember 2025 führen unerwartete Code-Ausführung als eigene Risikokategorie. Die Empfehlung ist unmissverständlich: Agent-generierter Code braucht strikte Sandbox, Input-Validation und Allowlisting. Sandboxing ist notwendig, aber nicht hinreichend, weil es die Code-Ausführung adressiert, nicht die Prompt-Logik. Ein Agent, der aus manipuliertem Kontext heraus eine legitime API-Rechnung von 50'000 Franken auslöst, hat ein Autorisierungsproblem. Wer die Ebene technisch verstehen will, findet in meiner Analyse zu LangSmith Sandboxes einen Einstieg in das, was Sandboxes leisten und wo sie enden.

Execution Monitoring mit Anomalie-Erkennung. Klassische SOC-Werkzeuge sehen Agenten-Läufe schlecht, weil die semantische Ebene fehlt. MELON und ähnliche Ansätze setzen bei beobachtbarem Verhalten an: Sie führen Agentenläufe mit maskiertem Nutzerauftrag erneut aus und vergleichen die Tool-Calls. Auch hier: nützlich, aber probabilistisch.

Bedrohungsmodellierung an der Quelle. Statt jeden Payload einzeln zu blocken, muss der Perimeter dorthin verschoben werden, wo die Daten in den Kontext einfliessen. Ein Web-Scraping-Modul, das eingelesene Inhalte in eine strikte, für den Agenten deutlich als «untrusted» markierte Sektion des Kontexts schiebt, ist wirkungsvoller als jede spätere Filterung. Der NVIDIA-NemoClaw-Stack versucht genau das auf Infrastrukturebene und zeigt zugleich die Grenzen: Selbst mit dediziertem Sicherheits-Stack bleibt Capability Overprovisioning eine häufige operative Schwäche.

Human-in-the-Loop bei jeder irreversiblen Aktion. Das ist keine schöne Antwort, aber es ist die einzige, die im Rule-of-Two-Fenster mit allen drei Eigenschaften funktioniert. Wer autonome Agenten mit ungebremster Wirkung in Produktionssystemen verspricht, verspricht mehr, als die aktuelle Technik trägt. Wer das im Produkt versteckt, produziert die nächsten Postmortems.

Wer den Gesamtrahmen sucht, findet ihn im Überblick zu KI-Sicherheit 2026, in den Prompt Injection eines von mehreren Kapiteln ist, aber inzwischen das operativ dringlichste.

Diagnose: die drei blinden Flecken der aktuellen Enterprise-Debatte

In aktuellen Sicherheitskonzepten und Vendor-Pitches wiederholen sich drei Fehler:

Erster blinder Fleck: «Wir haben Guardrails.» Guardrails sind Textklassifikation. Prompt Injection ist ein semantisches Ausrichtungsproblem. Beides ist verwandt, aber nicht deckungsgleich. Guardrails fangen einen Teil der bekannten Payload-Familien. Sie übersehen leicht den Angriff, der über eine legitim aussehende, aber semantisch manipulierte Instruktion in einem RAG-Dokument kommt.

Zweiter blinder Fleck: «Wir isolieren die Toolausführung.» Sandboxing schützt vor Code-Schäden im Host-System. Es verhindert nicht automatisch, dass der Agent legitime, aber ungewollte API-Aufrufe im Namen der Firma tätigt. Der Angriff findet oberhalb der Sandbox statt, auf der Ebene der Intent-Interpretation.

Dritter blinder Fleck: «Wir loggen alles.» Logging schafft forensische Kapazität, aber keine Prävention. In dokumentierten Enterprise-Vorfällen war der Angriff meist nachvollziehbar, sobald man die Traces las. Nur eben nach dem Schaden. Detektion muss zeitnah passieren, und dafür braucht es semantische Anomalieerkennung auf Agent-Ebene, nicht Zeilen im SIEM.

Was Sicherheits- und Plattformteams sofort tun sollten

Die kurze Prüfliste aus den Quellen dieses Artikels:

• Jeden produktiven Agenten gegen die Rule of Two prüfen. Zwei Eigenschaften maximal, sonst Human-in-the-Loop oder architektonische Aufteilung.
• Jede Datenquelle, aus der Kontext gezogen wird, explizit als Trust-Zone taggen. Web-Scraper, Ticket-Systeme, E-Mail-Inhalte und User-generierte Dokumente gehören in die niedrigste Trust-Klasse, unabhängig davon, wie «intern» sie sich anfühlen.
• Tool-Beschreibungen (MCP oder eigen) als Angriffsfläche behandeln. Sie sind Teil des Prompts, nicht Metadaten.
• RAG-Indizes gegen Poisoning härten: Herkunftsprüfung, Deduplizierung, Anomaliedetektion auf Einbettungsebene, regelmässige Sanity-Retrievals.
• Bei jedem konsequenzreichen Tool-Call zwei Ebenen der Autorisierung durchsetzen: die des Agenten und eine unabhängige Policy-Engine, die den Agenten als nicht vertrauenswürdigen Entscheider behandelt.

Nichts davon ist neu. Zusammen ergibt es die Sicherheitsarchitektur, die 2026 den Unterschied macht zwischen einem Agenten-Deployment, das man in einem Audit erklären kann, und einem, das in einer Woche im Threat-Report auftaucht.

Prompt Injection wird nicht verschwinden.