Prompt Injection: nierozwiązana podatność u podstaw każdej aplikacji LLM

Jeder Engineer kennt SQL Injection: nicht vertrauenswürdige Eingaben werden als Befehl interpretiert. Wir haben das Problem vor Jahrzehnten mit parametrisierten Abfragen gelöst — einer harten Grenze zwischen Code und Daten. Prompt Injection ist dieselbe Idee, angewendet auf LLMs, mit einem brutalen Unterschied: Für natürliche Sprache gibt es keine parametrisierte Abfrage. Für ein Modell ist alles Token. Der System-Prompt, die Frage des Nutzers und der Inhalt eines PDFs, das zusammengefasst werden soll, kommen alle über denselben Kanal an — und das Modell hat keine zuverlässige Möglichkeit zu erkennen, welche Teile Anweisungen und welche Daten sind. Das ist kein Bug eines einzelnen Modells. Es ist eine strukturelle Eigenschaft der Architektur, und deshalb stufen OpenAI, Anthropic und jeder Security-Anbieter Prompt Injection nach wie vor als ungelöstes Grenzproblem ein.

Direkte vs. indirekte Injection

Direkte Injection ist der klassische „Ignoriere vorherige Anweisungen"-Trick, der direkt in einen Chatbot eingetippt wird. Lästig, aber begrenzt — der Angreifer kompromittiert meist nur seine eigene Sitzung. Indirekte Injection ist der Ort, an dem das eigentliche Risiko liegt. Die bösartigen Anweisungen gelangen über Inhalte in das Modell, die es im Auftrag einer anderen Person verarbeitet: eine Webseite, die ein Agent durchsucht, ein Dokument in Ihrer RAG-Pipeline, eine E-Mail, ein GitHub-Issue, eine Kalendereinladung. Das Opfer tippt selbst nie etwas Bösartiges ein — es bittet seinen Assistenten lediglich, „dieses Ticket zusammenzufassen", und das Ticket enthält versteckte Anweisungen, denen das Modell brav folgt. Zwischen 2024 und 2026 entwickelte sich das von Forschungsdemos zu Produktionsvorfällen: dokumentierte Angriffe auf Slack AI, Microsoft 365 Copilot, Cursor und die MCP-Integrationen von GitHub folgten alle diesem Muster. Bis 2026 zeigt die Exploit-Berichterstattung von OWASP organisiertes Tooling — Dutzende unterschiedliche Payload-Familien und Zustellungstechniken im aktiven Einsatz — statt isolierter Experimente.

Die tödliche Trifecta

Simon Willison prägte die klarste Denkweise über dieses Risiko. Ein KI-System wird gefährlich angreifbar, sobald es drei Dinge kombiniert:

1. Zugriff auf private Daten — Ihre Dokumente, Datenbank, Codebasis, Postfach
2. Exposition gegenüber nicht vertrauenswürdigen Inhalten — alles, was ein Angreifer beeinflussen kann: Webseiten, E-Mails, Tickets, Package-READMEs
3. Die Fähigkeit, nach außen zu kommunizieren — Anfragen, E-Mails, Commits oder Tool-Aufrufe zu senden, die den Perimeter verlassen

Jede beliebige Kombination aus zwei dieser Punkte ist überlebbar. Alle drei zusammen bedeuten, dass ein Angreifer, der einen einzigen Inhalt kontrolliert, den Ihr Agent liest, potenziell alles exfiltrieren kann, was der Agent sehen kann. Fast jeder größere Vorfall der letzten zwei Jahre lässt sich exakt auf diese Kombination zurückführen. Das ist auch der Grund, warum das agentische Zeitalter die Lage verschärft hat. Ein Chatbot von 2023, der auf eine Injection hereinfällt, sagt etwas Peinliches. Ein Agent von 2026 mit Datenbankzugriff, einer Shell und einem E-Mail-Tool tut etwas Irreversibles. Der Einsatz hat sich von Worten zu Handlungen verlagert — deshalb haben die Five-Eyes-Behörden (CISA, NSA und ihre Pendants aus Großbritannien, Kanada, Australien und Neuseeland) im Mai 2026 eine gemeinsame Leitlinie zu agentischer KI veröffentlicht, in der Prompt Injection als zentraler Manipulationsvektor benannt und klar festgestellt wird, dass keine einzelne Schutzmaßnahme ausreicht.

Warum man es nicht einfach herausfiltern kann

Die instinktive Lösung — „bösartige Prompts erkennen und blockieren" — hält nicht stand. Injections lassen sich endlos umformulieren, kodieren, über mehrere Dokumente verteilen, in weißem Text auf weißem Grund oder in Bild-Metadaten verstecken. Selbst die stärksten veröffentlichten Erkennungsansätze übersehen einen beachtlichen Anteil optimierungsbasierter Angriffe, und ein Angreifer braucht nur einen einzigen Erfolg. Guardrail-Modelle helfen als eine Schicht; als Fundament versagen sie. Die ehrliche technische Haltung lautet: davon ausgehen, dass eine Injection gelingen wird, und so gestalten, dass eine erfolgreiche Injection keinen ernsthaften Schaden anrichten kann.

Defense in Depth, die tatsächlich funktioniert

• Die Trifecta brechen. Der wirkungsvollste einzelne Schritt. Wenn ein Agent nicht vertrauenswürdige Inhalte liest, kappen Sie seinen Egress oder seinen Zugriff auf Geheimnisse. Gestalten Sie jeden Agenten so, dass er höchstens zwei der drei Eigenschaften besitzt.
• Tools nach dem Prinzip der geringsten Rechte. Beschränken Sie jedes Tool auf den engstmöglichen Aktionsumfang. Wo möglich nur lesend. Keine Produktionscredentials in Reichweite des Agenten.
• Modellausgaben als nicht vertrauenswürdige Eingaben behandeln. Leiten Sie sie nie ohne Validierung direkt in eine Shell, SQL oder einen API-Aufruf — sonst macht die Injection das Modell zum Werkzeug des Angreifers.
• Menschliche Bestätigung für irreversible Aktionen. Zahlungen, Löschungen, E-Mails an externe Adressen, Produktions-Deployments.
• Sandboxing und Isolation. Codeausführung in Containern mit eingeschränktem Egress; Isolation pro Sitzung, damit ein vergiftetes Dokument nicht andere Nutzer kontaminiert.
• Alles loggen. Vollständige Prompt- und Tool-Call-Telemetrie in Ihrem SIEM. Injection-Versuche sind ein Angriffssignal, auf das Sie alarmieren sollten, nicht etwas, das Sie erst Wochen später entdecken.

Wenn Sie Modelle auf eigener Infrastruktur betreiben, setzen diese Maßnahmen auf der Hardening-Baseline auf, die wir in Sicherheit von selbst gehosteten LLMs behandelt haben — Injection ist die Bedrohung auf der Verhaltensebene, die bestehen bleibt, selbst wenn Ihr Netzwerk und Ihre Lieferkette sauber sind.

Fazit

Prompt Injection ist keine Schwachstelle, die man patcht; es ist eine Eigenschaft, um die herum man Architektur gestaltet. Die Teams, die das 2026 richtig machen, sind nicht die mit dem klügsten Filter — es sind die, die von einer Kompromittierung ausgegangen sind und den Schadensradius klein gehalten haben: minimale Rechte, gebrochene Trifectas, validierte Ausgaben und ein Mensch im Loop, wo es darauf ankommt. Bei NextVector wenden wir auf KI-Systeme dasselbe Security-First-Engineering an, das wir in unsere Zahlungs- und Blockchain-Infrastruktur einbringen. Sie bauen ein LLM-Feature, das mit echten Daten arbeitet? Kontaktieren Sie uns.