Constantin, Platform Engineering bei Pexon Consulting | 9 Min. Lesezeit | 02.09.2026
TL;DR
Claude Prompt Injection ist 2026 kein Modellproblem mehr, sondern ein Konfigurationsproblem. Anthropic meldet für Opus 5 mit aktiven Schutzschichten keine erfolgreichen Angriffe im Browser-Test. Gleichzeitig stehen 28 Sicherheits-Advisories gegen Claude Code, 22 davon hochkritisch. Der Schutz hängt an Ihrer Version und Ihren Berechtigungen.
Warum Prompt Injection bei Claude ein Betriebsproblem ist
Prompt Injection funktioniert, weil ein Sprachmodell Daten und Anweisungen im selben Kontextfenster sieht. Ein Angreifer schreibt in ein GitHub-Issue, eine Confluence-Seite oder eine Rechnungs-PDF einen Satz, der wie eine Anweisung klingt, und der Agent führt ihn aus. Das ist die indirekte Prompt Injection, und sie ist die gefährlichere Variante: Ihr Nutzer ist vertrauenswürdig, der Inhalt nicht.
Der Punkt, den die meisten deutschen Beiträge zum Thema auslassen: Anthropic hat auf der Modell-Ebene erheblich geliefert. Am 26.08.2026 hat Anthropic zur allgemeinen Verfügbarkeit von Claude in Chrome Zahlen aus Red-Team-Tests veröffentlicht. Gegen die stärkeren, von professionellen Red-Teamern gebauten Angriffe war Opus 4.5 in 17,6 Prozent der Fälle angreifbar, Opus 5 nur noch in 3,8 Prozent. Mit aktivierten Probes und Sicherheits-Klassifikator gelang gegen Sonnet 5 und Opus 5 kein einziger Angriff mehr, Fable 5 lag bei 0,3 Prozent.
Wer daraus schließt, das Thema sei erledigt, verwechselt zwei Ebenen. Das Modell wird schwerer zu überreden. Die Rechte, die es hat, wenn es doch überredet wird, bleiben genau so groß, wie Sie sie konfiguriert haben.
Die Zahl, die in keinem Anbieter-Blog steht
Wir haben am 02.09.2026 die veröffentlichten GitHub-Security-Advisories für das npm-Paket @anthropic-ai/claude-code ausgezählt. Ergebnis: 28 Advisories insgesamt, 13 aus 2025 und 15 aus 2026. Nach Schweregrad sind 22 als „high“ eingestuft, 4 als „medium“, 2 als „low“.
Die Titel lesen sich wie eine Themenliste für ein Rechtekonzept: Trust-Dialog-Bypass, Sandbox-Escape, Permission-Deny-Bypass über Symlinks, Command Injection über sed und find. Das jüngste ist CVE-2026-55607 vom 24.07.2026, ein Sandbox-Escape über Git-Worktree-Pfadverwirrung, behoben in Version 2.1.163.
Das ist ausdrücklich kein Argument gegen Claude Code. Ein aktiv beforschtes Werkzeug mit funktionierendem Meldeweg produziert genau dieses Bild, und Anthropic patcht schnell. Es ist ein Argument gegen eine bestimmte Praxis, die wir bei Kunden regelmäßig sehen: Claude Code wird einmal installiert, die Version eingefroren, damit „nichts kaputtgeht“, und dann zwölf Monate nicht angefasst. Die aktuelle Version ist 2.1.258 (Stand 02.09.2026). Wer auf 2.1.53 steht, hat fünf bekannte Sicherheitslücken offen und einen Prompt-Injection-Schutz, der auf dem Papier existiert.
Unsere klare Empfehlung: Behandeln Sie die Claude-Code-Version wie eine Abhängigkeit im Produktivcode, mit Renovate oder Dependabot und einem festen Update-Fenster. Nicht wie ein Entwickler-Werkzeug, das jeder selbst pflegt.
Die vier Schalter in Claude Code, die tatsächlich zählen
Claude Code bringt eine Reihe eingebauter Schutzmechanismen mit: ein Berechtigungssystem, das im Manual-Modus mit Nur-Lese-Rechten startet, eine Arbeitsverzeichnis-Grenze, isolierte Kontextfenster für Web-Fetch, damit abgerufene Inhalte nicht in den Hauptkontext injizieren, und Trust-Verifikation für neue Codebasen und neue MCP-Server. Netzwerkbefehle wie curl und wget sind bewusst nicht vorab genehmigt.
Vier Einstellungen entscheiden in der Praxis darüber, ob das trägt. Sie gehören in eine versionierte settings.json im Repository, nicht in die persönliche Konfiguration jedes Entwicklers:
{
"permissions": {
// Netzwerk-Abfluss und Secret-Pfade hart verbieten, nicht nur nachfragen
"deny": [
"Bash(curl *)",
"Bash(wget *)",
"Read(./.env)",
"Read(./secrets/**)"
]
},
// Niemals bypassPermissions: hebt den kompletten Schutz auf
"defaultMode": "default",
// Nur geprüfte MCP-Server, Allowlist statt Blockliste
"allowedMcpServers": ["github", "internal-jira"],
"enableAllProjectMcpServers": false
}Der wichtigste Wert ist defaultMode. Wir haben in Audits mehrfach bypassPermissions in eingecheckten Konfigurationen gefunden, meist eingeführt, weil die Rückfragen im CI genervt haben. Damit ist jede weitere Maßnahme wirkungslos. Wenn die Rückfragen im CI stören, ist die Antwort Sandboxing über /sandbox, nicht das Abschalten des Berechtigungssystems.
Der zweite Punkt ist die MCP-Allowlist. Ein ungeprüfter MCP-Server ist keine Integration, sondern ein Pfad zur Rechte-Eskalation. Anthropic prüft Konnektoren im Verzeichnis gegen Listing-Kriterien, führt aber ausdrücklich kein Sicherheits-Audit der einzelnen MCP-Server durch. Diese Prüfung bleibt bei Ihnen.
Eigene Agenten über die Claude API absichern
Bauen Sie selbst auf der API, verschiebt sich die Arbeit in die Struktur Ihrer Requests. Anthropic ist hier ungewöhnlich konkret: Nicht vertrauenswürdige Inhalte gehören ausschließlich in tool_result-Blöcke, niemals in den System-Prompt oder einen einfachen Text-Block. Claude ist darauf trainiert, Anweisungen aus Tool-Ergebnissen mit Skepsis zu behandeln.
Der zweite Baustein ist die JSON-Kodierung, die Eingabevalidierung auf Strukturebene statt auf Musterebene erledigt. Verketten Sie Fremdtext nie zu Freitext, sondern verpacken Sie ihn als JSON-String. Das Escaping liefert eindeutige Trennzeichen, sodass ein Angreifer kein Tag und kein Anführungszeichen schließen kann, um in den Anweisungskontext auszubrechen:
import json
# E-Mail-Inhalt als Daten kennzeichnen, nicht als Text anhaengen
nutzlast = json.dumps({
"source": "inbound_email",
"from": "unbekannt@example.com",
"body": roher_mail_text, # darf alles enthalten, bleibt escaped
})
nachricht = {
"role": "user",
"content": [{
"type": "tool_result",
"tool_use_id": tool_id,
"content": [{"type": "text", "text": nutzlast}],
}],
}Als dritte Schicht empfiehlt Anthropic eine Laufzeit-Erkennung. Erst diese drei Ebenen zusammen ergeben Verteidigungstiefe: Jede Tool-Ausgabe vor der Weitergabe durch einen schlanken Klassifikator-Aufruf mit claude-haiku-4-5 schicken und über Structured Outputs ein einzelnes boolesches injection_suspected zurückgeben lassen. Nur wenn das Urteil negativ ist, geht der Rohinhalt an das Hauptmodell. Das kostet wenige Millisekunden und ist die einzige Schicht, die auch dann greift, wenn das Modell selbst überredet wurde.
Und die Regel, die alles andere überlebt: Zugriffskontrolle vor Filterlogik. Ein Agent ohne Zugriff auf ein Geheimnis kann es auch nach erfolgreicher Injection nicht abfließen lassen.
Open-Source-Guards: zwei der meistempfohlenen Tools sind tot
Hier wird es unangenehm. Wer 2026 nach Open Source Tools zur Prompt-Injection-Erkennung sucht, landet in fast jedem Listicle bei llm-guard und rebuff. Wir haben beide am 02.09.2026 geprüft: Beide Repositories sind auf GitHub archiviert. Bei rebuff liegt der letzte Push im August 2024, bei llm-guard im Juli 2026. Archiviert heißt: keine Patches, keine neuen Angriffsmuster, kein Meldeweg.
Wir raten von beiden archivierten Projekten ab, auch wenn sie technisch noch installierbar sind. Ein Sicherheitsfilter, dessen Mustererkennung seit zwei Jahren stillsteht, erzeugt vor allem ein falsches Sicherheitsgefühl in der Risikobewertung. Für das Red-Teaming eigener Agenten nehmen wir garak, für die Regressionsprüfung von Prompts und Guardrails promptfoo. Beide werden aktiv gepflegt.
Dass die Bedrohung real ist, zeigt der Fall, den Oasis Security am 18.03.2026 unter dem Namen „Claudy Day“ veröffentlicht hat: Über unsichtbare HTML-Tags in URL-Parametern von claude.ai wurde die Chat-Eingabe vorbefüllt und Konversationsdaten über die Anthropic Files API abgezogen, ohne sichtbares Zeichen für den Nutzer. Genau diese Datenexfiltration ist das eigentliche Schadensbild, nicht die Injection selbst. Anthropic hat die Injection-Lücke im Rahmen des Responsible-Disclosure-Programms geschlossen.
Was der EU AI Act ab August 2026 von Ihnen verlangt
Seit dem 02.08.2026 greifen die Pflichten des EU AI Act für die Breite der betroffenen Unternehmen. Artikel 15 verlangt für Hochrisiko-Systeme ausdrücklich Robustheit und Cybersicherheit, und Prompt Injection ist genau der Angriff, den diese Anforderung meint. Haftbar ist dabei nicht das Modell und nicht Anthropic, sondern das Unternehmen, das den Agenten betreibt. Unternehmenssicherheit und Datenschutz fallen damit zusammen: Ein abgeflossener Prompt-Kontext ist im Zweifel auch eine meldepflichtige Datenpanne. Bei kritischer Infrastruktur kommt NIS2 hinzu, das die Geschäftsleitung persönlich in die Pflicht nimmt.
Für die Praxis heißt das weniger, als viele befürchten, und mehr, als die meisten dokumentieren: Sie brauchen ein nachweisbares Rechtekonzept für Ihre Agenten, einen dokumentierten Update-Prozess und Red-Teaming-Ergebnisse für den eigenen Workflow. Die technischen Maßnahmen aus den Abschnitten oben liefern Ihnen den Nachweis fast nebenbei, wenn Sie sie versioniert ablegen statt mündlich zu vereinbaren. Wie ein Coding-Agent als privilegierte Identität behandelt wird, haben wir am Beispiel OpenAI Codex im Repository-Kontext beschrieben, die Architekturfrage ist dieselbe.
Häufig gestellte Fragen
Ist Claude sicherer gegen Prompt Injection als andere Modelle?
Auf der Modell-Ebene liegt Claude aktuell gut. Anthropic meldet für Opus 5 einen Rückgang der Angriffserfolgsquote auf 3,8 Prozent gegen starke Red-Team-Angriffe, mit aktivierten Klassifikatoren keine erfolgreichen Angriffe im Browser-Szenario. Das gilt aber nur für das Modell selbst. Ein schlecht konfigurierter Claude-Agent mit weiten Rechten ist unsicherer als ein eng geschnürter Agent auf einem schwächeren Modell.
Was kostet der Schutz vor Prompt Injection?
Die technischen Maßnahmen kosten fast nichts: Berechtigungsregeln und MCP-Allowlist sind Konfiguration, der Haiku-Klassifikator pro Tool-Aufruf liegt im Bereich von Bruchteilen eines Cents. Der Aufwand steckt im Rechtekonzept und im Update-Prozess. Bei unseren Kunden liegt die Ersteinrichtung inklusive Red-Teaming und Dokumentation typischerweise bei zwei bis vier Personenwochen.
Reicht es, Claude Code im Manual-Modus zu betreiben?
Nein, aber es ist die wichtigste einzelne Maßnahme. Der Manual-Modus startet mit Nur-Lese-Rechten und fragt vor systemverändernden Befehlen nach. Ohne aktuelle Version, Deny-Regeln für Secret-Pfade und eine MCP-Allowlist bleiben trotzdem Wege offen, wie die Sandbox-Escape- und Trust-Dialog-Bypass-Advisories der letzten Monate zeigen.
Direkte oder indirekte Prompt Injection: was ist das größere Risiko?
Die indirekte. Bei der direkten Variante ist Ihr eigener Nutzer der Angreifer, das begrenzt den Schaden meist auf dessen ohnehin vorhandene Rechte. Bei der indirekten Variante ist der Nutzer vertrauenswürdig, und der Angriff kommt über ein Dokument, eine Webseite oder ein Tool-Ergebnis. Genau dieser Weg trifft RAG-Systeme und MCP-Anbindungen am härtesten.
Welche Rolle spielt OWASP bei der Bewertung?
Die OWASP LLM Top 10 führen Prompt Injection als LLM01 auf, also als das Risiko mit der höchsten Priorität. Für die Zuordnung zu deutschen Compliance-Anforderungen wie NIS2 und DSGVO ist die Liste ein brauchbarer Rahmen, weil Auditoren sie kennen. Wir nutzen sie als Struktur für Sicherheitsreviews und haben das Mapping in unserem Beitrag zu den OWASP LLM Top 10 im DACH-Kontext ausgeführt.
Nächster Schritt
Wenn Sie Claude Code oder eigene Claude-Agenten bereits im Team einsetzen, ist der schnellste Erkenntnisgewinn nicht die Diskussion über Schutzstrategien, sondern ein Blick in die eingecheckten Konfigurationen: Version, defaultMode, MCP-Liste. Erfahrungsgemäß findet sich dort in der Hälfte der Fälle mindestens ein offener Punkt.
Verwandte Themen
→Wenn Dokumente den Agent übernehmen
→Den Agent-Stack sauber aufsetzen
