Claude Code ist aus demselben Grund leistungsfähig, aus dem es riskant ist: Es fasst das Lesen von Code, die Bearbeitung von Dateien, die Ausführung von Shells, den Projektspeicher und den Zugriff auf externe Werkzeuge in einer einzigen Laufzeitumgebung zusammen. Die Dokumentation von Anthropic selbst beschreibt es als ein agentenbasiertes Kodierungswerkzeug, das Ihre Codebasis liest, Dateien bearbeitet, Befehle ausführt und sich mit Entwicklungswerkzeugen integriert. Sobald ein Tool all dies innerhalb eines Repositorys tun kann, ist die Sicherheitsfrage nicht mehr nur, ob das Modell mit Prompt-Injektionen versehen werden kann. Vielmehr stellt sich die Frage, was passiert, wenn Repository-Inhalte, gemeinsam genutzte Konfigurationen, Speicher und Tool-Verbindungen alle am selben Ausführungspfad beteiligt sind. (Claude)
An dieser Stelle wird die Claude Code-Forschungsgeschichte interessant. Öffentliche Herstellerhinweise, NVD-Aufzeichnungen und Untersuchungen von Check Point weisen alle in dieselbe Richtung: Die Fehler mit dem höchsten Wert waren nicht "das Modell sagte etwas Falsches". Es handelte sich um Fehler an den Vertrauensgrenzen. In unterschiedlichen Formen erlaubte Claude Code die Ausführung, bevor das Vertrauen vollständig hergestellt war, erlaubte der projektgesteuerten Konfiguration, die Sicherheitslage zu beeinflussen, oder zeigte Lücken zwischen Berechtigungen, Shell-Validierung und Netzwerkkontrolle auf. Dies sind Fehler in der Systemgestaltung an der Grenze zwischen Konfiguration und Ausführung. (NVD)
Dies ist über einen Produktveröffentlichungszyklus hinaus von Bedeutung. Claude Code ist eine der deutlichsten öffentlichen Fallstudien dafür, was passiert, wenn ein Repository nicht mehr nur aus Daten besteht. In einer agentenbasierten Kodierungsumgebung kann das Repository Anweisungen, Speicher, Hooks, Berechtigungen und Tool-Integrationen enthalten, die sich darauf auswirken, was der Agent sieht und was er tun darf. Eine moderne Sicherheitsüberprüfung muss daher das Repo als eine Fähigkeitsoberfläche modellieren, nicht nur als einen Quellcodebaum. Die Dokumentation von Anthropic macht diese Verschiebung im Klartext sichtbar: projektübergreifende Einstellungen können Berechtigungen, Hooks und MCP-Server enthalten; projektübergreifende MCP-Server leben in .mcp.json und sind so konzipiert, dass sie in die Versionskontrolle eingecheckt werden können; CLAUDE.md und der automatische Speicher werden beim Start der Sitzung geladen; und Unteragenten können Werkzeuge von der Hauptkonversation erben, einschließlich MCP-Werkzeuge. (Claude)
Die Sicherheit von Claude Code beginnt an der Grenze des Vertrauens
Viele Diskussionen über die Sicherheit der KI-Codierung gehen immer noch von dem alten Modell aus. In diesem Modell ist die KI ein Textgenerator, die Shell ist separat, die Repo-Konfiguration ist größtenteils inaktiv, es sei denn, ein Build-Schritt wird ausgeführt, und bei "Prompt Injection" geht es hauptsächlich darum, das Modell zu verwirren. Claude Code bricht dieses Modell. Anthropic dokumentiert Claude Code als eine werkzeugverwendende Umgebung mit mehreren Berechtigungsmodi, nativem Sandboxing für Bash, Speicher auf Projektebene, Hooks, die Aktionen bei Lebenszyklusereignissen automatisieren können, MCP-Integrationen für externe Dienste, Plugins, die Hooks und MCP-Server verpacken, und Subagenten, die Arbeit über Kontexte hinweg delegieren können. Das ist eine viel reichhaltigere Laufzeit als ein Plugin zur Code-Vervollständigung. (Claude)
Die Vertrauensgrenze ist das Einzige, was die Laufzeitumgebung davon abhält, nicht vertrauenswürdige Repository-Inhalte als aktive betriebliche Eingaben zu behandeln. In den Sicherheitsdokumenten von Anthropic heißt es, dass erstmalige Codebase-Läufe und neue MCP-Server eine Vertrauensüberprüfung erfordern und dass Werkzeuge, die Netzwerkanfragen stellen, standardmäßig die Zustimmung des Benutzers benötigen. Sie sagen auch, dass Claude Code nur die Rechte hat, die Sie ihm zugestehen, und dass Sie für die Überprüfung von vorgeschlagenem Code und Befehlen vor der Genehmigung verantwortlich sind. Das sind sinnvolle Kontrollen, aber sie funktionieren nur, wenn die Reihenfolge stimmt. Wenn die Konfiguration vor dem Vertrauen aufgelöst wird oder wenn ein Projekt den Berechtigungsmodus, der den Vertrauensdialog selbst steuert, stillschweigend ändern kann, dann ist die Ausrichtung des Modells nicht mehr das Hauptproblem. Die Reihenfolge ist. (Claude)
In der Beschreibung des automatischen Modus von Anthropic vom März 2026 wird ein weiterer wichtiger Punkt deutlich: Die Nutzer stimmen 93 Prozent der Aufforderungen zur Erteilung einer Genehmigung zu. Anthropic hat den Automatikmodus zum Teil entwickelt, um die Zustimmungsmüdigkeit zu verringern, denn ein System, das ständig nachfragt, trainiert die Menschen schließlich dazu, sich durchzuklicken. Das ist ein nützliches Eingeständnis, weil es das praktische Bedrohungsmodell neu formuliert. Die menschliche Zustimmung ist keine harte Sicherheitsgrenze, wenn das Standardbetriebsmuster des Produkts die Gewöhnung fördert. In dieser Welt braucht der Angreifer nicht immer eine vollständige Zero-Click-Exploit-Kette. Manchmal brauchen sie nur einen Arbeitsablauf, bei dem ein Entwickler nicht mehr merkt, was "genehmigen" jetzt bedeutet. (Anthropisch)
Die Anthropic-Dokumente ziehen auch eine wichtige Grenze zwischen den Sicherheitsmechanismen. Sandboxing isoliert Bash-Unterprozesse mit Dateisystem- und Netzwerkkontrollen, aber die Dokumentation ist ebenso klar, dass eingebaute Datei-Tools das Berechtigungssystem direkt verwenden und nicht durch die Sandbox laufen. Das bedeutet, dass "die Sandbox verwenden" keine vollständige Antwort auf das Risiko von Claude Code ist. Wenn Ihr Bedrohungsmodell Konfigurationsdateien, integrierte Bearbeitungs- und Schreibwerkzeuge oder die Computernutzung umfasst, müssen Sie über mehr als eine Grenze hinweg denken. Sandboxing ist wertvoll, aber es ist nur eine Schicht in einem Stapel. (Claude)
Claude Code Hooks, MCP, Speicher, Subagenten und Plugins erweitern die Angriffsfläche
Der einfachste Weg, die Sicherheitsoberfläche von Claude Code zu verstehen, besteht darin, nicht mehr an einen Assistenten zu denken, sondern an mehrschichtige Erweiterungspunkte. Die Anthropic-Dokumentation beschreibt Hooks als benutzerdefinierte Shell-Befehle, HTTP-Endpunkte oder LLM-Prompts, die automatisch an bestimmten Punkten im Lebenszyklus von Claude Code ausgeführt werden. Die Schnellstartanleitung ist sogar noch direkter: Mit Hooks können Sie Shell-Befehle automatisch ausführen lassen, wenn Claude Dateien bearbeitet, Aufgaben abschließt oder Eingaben benötigt, und sie sollen eine deterministische Kontrolle bieten, anstatt sich darauf zu verlassen, dass das Modell entscheidet, ob es handeln soll. Dieser eine Satz, deterministische Kontrolle, ist der entscheidende Sicherheitsfaktor. Es bedeutet, dass Hooks nicht nur Kontext sind. Sie sind Automatisierung. (Claude)
MCP ist eine andere Oberfläche, aber sie erzeugt eine ähnliche Verschiebung. Anthropic's Claude Code docs sagen, dass projektspezifische Server in einem .mcp.json Datei im Stammverzeichnis des Projekts, dass die Datei dazu bestimmt ist, in die Versionskontrolle eingecheckt zu werden, und dass sie speziell dafür existiert, dass alle Teammitglieder auf dieselben MCP-Tools und -Dienste zugreifen können. In den Dokumenten werden die Benutzer auch gewarnt, den von ihnen installierten MCP-Servern zu vertrauen und besonders vorsichtig mit MCP-Servern zu sein, die nicht vertrauenswürdige Inhalte abrufen, da diese die Benutzer dem Risiko einer Soforteinspeisung aussetzen können. Mit anderen Worten: Das offizielle Modell für die Teamzusammenarbeit geht bereits davon aus, dass Repository-Inhalte die Konnektivität von Tools definieren können. Das ist für Ingenieure sehr praktisch. Es bedeutet auch, dass Repository-Inhalte einen direkten Weg in die Werkzeugebene haben. (Claude)
Das Gedächtnis fügt eine dritte Ebene hinzu. Anthropic dokumentiert zwei komplementäre Gedächtnissysteme in Claude Code, die beide zu Beginn eines jeden Gesprächs geladen werden. Claude behandelt sie als Kontext, nicht als erzwungene Konfiguration. CLAUDE.md-Dateien werden zu Beginn jeder Sitzung gelesen, und CLAUDE.md wird vollständig geladen; MEMORY.md hat ein Startlimit, aber die ersten 200 Zeilen oder 25 KB werden trotzdem automatisch geladen. Dadurch unterscheiden sich Memory Poisoning und Context Shaping von einem einfachen Angriff auf die Eingabeaufforderung. Ein vergifteter Prompt ist flüchtig. Eine vergiftete Projektanweisungsdatei kann Teil jeder Sitzung werden. Der Agent kann sie als Ratschlag und nicht als Code behandeln, aber in einem agentenbasierten Werkzeug beeinflusst der Ratschlag die Auswahl der Aktion. (Claude API-Dokumente)
Subagenten und Plugins sind nach dem gleichen Muster aufgebaut. Die Subagenten-Dokumentation von Anthropic besagt, dass Subagenten standardmäßig alle Werkzeuge der Hauptkonversation erben, einschließlich MCP-Werkzeuge, es sei denn, Sie schränken sie explizit mit einer allowlist oder denylist ein. Die Plugin-Referenz besagt, dass Plugins eine Verpackungsschicht sind, die Skills, Agenten, Hooks, MCP-Server und LSP-Server in einer einzigen installierbaren Einheit bündeln kann. Anthropic setzt hier auch einige Sicherheitsgrenzen: Agenten, die mit Plugins ausgeliefert werden, können keine Hooks enthalten, mcpServer, oder permissionMode. Diese Einschränkung ist aufschlussreich. Sie signalisiert, dass Anthropic diese Oberflächen bereits als besonders empfindlich behandelt. Aber auch mit dieser Einschränkung bleibt die architektonische Lektion bestehen: Erweiterbarkeit ist nicht neutral. Sie ist ein Verteilungsweg für Politik und Fähigkeiten. (Claude API-Dokumente)
In der nachstehenden Tabelle wird der offizielle Funktionsumfang auf die für die Überprüfung wichtigsten Sicherheitsaspekte reduziert. (Claude)
| Oberfläche | Was die offiziellen Dokumente sagen | Warum es für die Sicherheit wichtig ist |
|---|---|---|
| Häkchen | Hooks werden automatisch bei Lebenszyklusereignissen ausgeführt und sind für eine deterministische Steuerung konzipiert | Die Projektkonfiguration kann automatisch ausgeführt werden |
| Projektbezogener MCP | .mcp.json ist eine Projekt-Stammkonfiguration für Versionskontrolle und gemeinsame Nutzung durch das Team | Gemeinsame Werkzeugkonnektivität wird Teil des Repo-Trusts |
| CLAUDE.md und automatischer Speicher | Speicherdateien werden zu Beginn der Sitzung geladen und beeinflussen den Kontext | Der Projektkontext kann Entscheidungen nachhaltig beeinflussen |
| Berechtigungseinstellungen | Berechtigungen können in der Versionskontrolle überprüft und in Teams gemeinsam genutzt werden | Kollaborationskonfigurationen können die Sicherheitslage verändern |
| Unterbeauftragte | Unterbeauftragte erben standardmäßig Werkzeuge, einschließlich MCP-Werkzeuge | Delegation kann mehr Fähigkeiten verbreiten als beabsichtigt |
| Plugins | Plugins paketieren Fähigkeiten, Agenten, Hooks, MCP-Server und LSP-Server | Die Verpackung wird zu einer Verteilungsebene für Politik und Risiko |
Was sich in der Praxis ändert, ist, dass das Repository nicht mehr nur ein Quell-Artefakt ist. Es ist auch eine Angriffsfläche für die Laufzeit. Sicherheitsteams haben Entwicklern jahrelang beigebracht, dass Quellcode gefährlich ist, wenn er kompiliert, ausgeführt oder bereitgestellt wird. Claude Code fügt eine weitere Kategorie hinzu: quellennahe Konfiguration, die nicht offensichtlich im klassischen Sinne ausführbar ist, aber dennoch ändert, was der Agent ausführt, mit wem er sich verbindet und wem er vertraut. Das ist die Brücke, die Angreifer wollen.
Claude Code Permissions und Vertrauen bringen andere Kompromisse mit sich, als die meisten Teams erkennen
Das offizielle Genehmigungsmodell in Claude Code ist umfangreicher als eine einfache Ja-oder-Nein-Abfrage. Anthropic dokumentiert mehrere Erlaubnismodi: Standard, acceptEdits, Plan, Auto, bypassPermissionsund dontAsk. Plan Modus kann Claude Dateien lesen, Shell-Befehle zur Untersuchung ausführen und einen Plan schreiben, ohne den Quellcode zu bearbeiten. dontAsk verweigert automatisch alles, was nicht ausdrücklich erlaubt ist. bypassPermissions deaktiviert Berechtigungsabfragen und Sicherheitsprüfungen, wobei nur noch einige wenige Abfragen für kritische lokale Zustände wie .git, .vscode, .ideeund Teile von .claude. Anthropic warnt ausdrücklich davor, dass bypassPermissions bietet keinen Schutz gegen prompte Injektion oder unbeabsichtigte Aktionen und sollte daher isolierten Umgebungen vorbehalten bleiben. (Claude)
Das ist wichtig, denn die öffentlichen Hinweise zeigen, dass Angreifer kein neues Sicherheitsmodell erfinden müssen. Sie müssen nur Unstimmigkeiten innerhalb des Modells finden, das das Produkt bereits hat. Wenn die Projektkonfiguration den Berechtigungsmodus beeinflussen kann, bevor das Vertrauen hergestellt ist, oder wenn ein Werkzeugpfad eine Schreibsenke erreichen kann, die das Berechtigungssystem blockiert zu haben glaubte, dann sieht die Benutzeroberfläche immer noch berechtigungsbasiert aus, während die tatsächliche Grenze bereits überschritten wurde. Aus diesem Grund geht es in vielen der Ratschläge von Claude Code nicht um große konzeptionelle Fehler. Es geht um Sequenzierung, Analyse und Vorrangigkeit. Diese Details entscheiden darüber, ob das Modell innerhalb einer Richtlinie oder um sie herum operiert. (GitHub)
Die Dokumente über den Vorrang von Einstellungen verdeutlichen diesen Punkt noch weiter. Anthropic sagt, dass projektübergreifende Einstellungen in .claude/settings.json in der Versionskontrolle leben, und dass gemeinsame Projekteinstellungen Vorrang vor einigen Entscheidungen auf Benutzerebene haben, wenn die Hierarchie aufgelöst wird. Auf der Einstellungsseite werden explizit vom Team gemeinsam genutzte Berechtigungen, Hooks und MCP-Server als Anwendungsfälle für den Projektbereich aufgeführt. Das ist nützlich für die Zusammenarbeit, aber vom Sicherheitsstandpunkt aus gesehen bedeutet es, dass Repo-Inhalte ein Richtlinienvehikel sein können. Sobald Sie Richtlinien mit Repo-Umfang zulassen, hängt Ihr sicheres Design von der zuverlässigen Trennung sicherer kollaborativer Vorgaben von ausführungsrelevanter Macht ab. Öffentliche Hinweise deuten darauf hin, dass diese Trennung nicht immer so stark war, wie sie sein sollte. (Claude)
Der praktische Nutzen ist einfach und unangenehm. In Claude Code ist das Berechtigungssystem nicht das gesamte Sicherheitsmodell. Das eigentliche Sicherheitsmodell ist die Kombination aus Einstellungsumfang, Vertrauensüberprüfung, Modusauflösung, Shell-Validierung, Netzwerkgenehmigung, Sandbox-Grenzen und Erweiterungsflächen. Teams, die jedes dieser Elemente isoliert betrachten, verpassen den Weg, auf den es ankommt.
Die Geschichte mit der Quellenkarte vom 31. März hat das Problem der Sichtbarkeit verändert
Am 31. März 2026 behaupteten öffentliche GitHub-Spiegel und Berichte Dritter, dass das npm-verteilte Claude Code-Paket eine cli.js.map Datei und genügend eingebettete Quellinformationen, um einen großen Teil der TypeScript-Codebasis zu rekonstruieren. Die Mirror-Repositories weisen ausdrücklich darauf hin, dass es sich um inoffizielle Extraktionen und nicht um Anthropic-Repositories handelt. Laut Berichten von Dritten hatte Anthropic zum Zeitpunkt der ersten Veröffentlichung noch keine öffentliche Erklärung abgegeben. Zusammengenommen rechtfertigen diese Tatsachen nicht, die undichte Stelle als offizielle Quelle der Wahrheit zu betrachten. Sie rechtfertigen jedoch, sie als eine echte Veränderung der Kosten für die White-Box-Überprüfung zu betrachten. (GitHub)
Diese Unterscheidung ist wichtig. Sicherheitsschlussfolgerungen über Claude Code sollten immer noch in offiziellen Dokumenten, GitHub-Beratungen, NVD-Aufzeichnungen und seriöser Forschung verankert sein. Aber die Berichterstattung über die Source-Map verändert die Umgebung, in der Forscher arbeiten. Eine Laufzeit, die Shell-Ausführung, Berechtigungen, Agent-Schleifen, Tool-Dispatch und Repository-gesteuerte Einstellungen kombiniert, wird viel einfacher zu untersuchen, wenn öffentliche Mirrors behaupten, lesbare Codepfade offenzulegen. Selbst wenn man sich nie direkt auf diese Spiegel verlässt, senkt ihre Existenz die Hürde für unabhängige Analyse, Patch-Diffing und Architekturüberprüfung. Für ein Werkzeug wie Claude Code ist das kein unbedeutendes Ereignis. Es verändert die Wirtschaftlichkeit der Überprüfung. (GitHub)
Es gibt hier auch eine umfassendere technische Lektion. Der Luna-Beitrag über den Source-Map-Vorfall bezeichnete ihn als einen Fehler in der Build-Pipeline und nicht als einen Hack, da eine Source-Map in einem öffentlichen Paket proprietäre Quellen offenlegen kann. Diese Interpretation deckt sich mit den grundlegenden Mechanismen der Paketverteilung. Für ein sicherheitsbewusstes Publikum ist der wichtige Punkt nicht das Gerede über durchgesickerten Code. Es geht darum, dass die Veröffentlichungsartefakte für agenturische Entwicklerwerkzeuge die gleiche Aufmerksamkeit verdienen wie die Werkzeuge selbst, da Artefaktfehler geschlossene Implementierungsdetails über Nacht in offene Analyseoberflächen verwandeln können. (Lunatech)

Claude Code-Schwachstellen kartiert die Umgehungspfade in der Öffentlichkeit
Der öffentliche Verlauf der Schwachstellen von Claude Code ist ungewöhnlich aufschlussreich, weil sich die Probleme um dasselbe Thema gruppieren. Es handelt sich nicht um zufällige Bugs. Sie zeigen immer wieder, dass das Produkt mit den Grenzen zwischen Vertrauen, Konfiguration, Parsing, Tool-Ausführung und Netzwerkkontrolle zu kämpfen hat.
Das früheste Beispiel mit hohem Signalwert ist CVE-2025-59536. Laut NVD waren Versionen vor 1.0.111 aufgrund eines Fehlers in der Implementierung des Startvertrauensdialogs anfällig für Code-Injektion. Claude Code konnte dazu verleitet werden, Code aus einem Projekt auszuführen, bevor der Benutzer den Start-Vertrauensdialog akzeptierte, wobei ein Benutzer Claude Code in einem nicht vertrauenswürdigen Verzeichnis starten musste, um den Fehler auszunutzen. Oberflächlich betrachtet klingt das wie ein Startfehler. Aus architektonischer Sicht ist es eine Feststellung, dass "open repo" und "start agent" im Kontrollfluss zu nahe beieinander lagen. Der Benutzer hatte noch nicht erfolgreich Vertrauen ausgedrückt, aber das System war bereits in Aktion getreten. (NVD)
CVE-2026-21852 hat die gleiche Lektion auf die Netzwerkebene übertragen. Das GitHub-Advisory von Anthropic und NVD besagen, dass vor Version 2.0.65 ein bösartiges Repository Folgendes festlegen konnte ANTHROPIC_BASE_URL in einer Einstellungsdatei und veranlassen Claude Code, API-Anfragen zu stellen, bevor die Vertrauensabfrage angezeigt wird, wodurch API-Schlüssel an einen von einem Angreifer kontrollierten Endpunkt gelangen können. Dies ist keine Prompt-Injection-Geschichte. Es handelt sich um eine Sequenzierungsgeschichte. Die Frage ist nicht, ob das Modell den Benutzer verstanden hat. Die Frage ist, ob die Laufzeitumgebung es zuließ, dass eine vom Repository kontrollierte Umgebungseinstellung wirksam wurde, bevor Vertrauen hergestellt wurde. (GitHub)
Das GitHub-Advisory GHSA-mmgp-wc2j-qcv7 vom März 2026 machte das Berechtigungsproblem noch konkreter. Anthropic enthüllte, dass Claude Code den Berechtigungsmodus von Einstellungsdateien, einschließlich repo-kontrollierter .claude/settings.jsonbevor entschieden wird, ob der Dialog zur Bestätigung des Vertrauens in den Arbeitsbereich angezeigt werden soll. Ein bösartiges Repo könnte die permissions.defaultMode zu bypassPermissionsund überspringt den Vertrauensdialog beim ersten Öffnen und versetzt den Benutzer ohne ausdrückliche Zustimmung in einen freizügigen Modus. Dies ist ein ungewöhnlich sauberes Beispiel für eine Konfiguration, die genau die Grenzen untergräbt, die für die Konfiguration gelten sollen. Was bei einem solchen Entwurf sicher ist, ist im Nachhinein offensichtlich: Vertrauen muss entschieden werden, bevor repo-kontrollierte Einstellungen die Ausführungsposition beeinflussen können. Das Advisory existiert, weil diese Reihenfolge nicht stark genug durchgesetzt wurde. (GitHub)
In der Untersuchung von Check Point vom Februar 2026 wurden mehrere dieser Ideen miteinander verknüpft. In dem Bericht heißt es, dass böswillige Projektkonfigurationen Hooks, MCP-Server und Umgebungsvariablen verwenden können, um Remotecodeausführung und API-Token-Exfiltration zu erreichen, wenn Benutzer nicht vertrauenswürdige Repositories klonen und öffnen. Unabhängig davon, ob Sie mit jeder Bezeichnung in dem Bericht einverstanden sind oder nicht, ist der strukturelle Punkt wichtig: Es handelte sich nicht um eine Behauptung über einen einzelnen Parser-Edge-Case. Es ging um die Behauptung, dass Projektdateien zu einer Ausführungs- und Anmeldungsoberfläche geworden sind. Das ist genau die Veränderung der Grenzen, die Sicherheitsteams verinnerlichen müssen. (Check Point Forschung)
Die Hinweise zur Befehlsvalidierung bekräftigen dieselbe Schlussfolgerung aus einem anderen Blickwinkel. Anthropic veröffentlichte Hinweise auf die Ausführung von beliebigem Code durch Umgehung der Befehlsüberprüfung, auf die Ausführung nicht vertrauenswürdiger Befehle durch finden.für beliebige Dateischreibvorgänge über ZSH-Clobber-Parsing, für die Umgehung des Schreibschutzes durch Piping sed mit echound für die Umgehung geschützter Schreibvorgänge durch Verzeichniswechsel. Unterschiedliche Mechanismen, dieselbe Lektion: Sobald das Produkt die Shell-Absicht im Namen des Benutzers analysieren und klassifizieren muss, wird jede Ecke der Shell-Grammatik sicherheitsrelevant. Ein Berechtigungsmodell, das in der Benutzeroberfläche gut aussieht, ist nur so gut wie der Parser, der ihm zugrunde liegt. (GitHub)
Das Gleiche gilt für die Sandbox- und die Netzwerkschicht. Anthropic enthüllte einen Ausbruch aus der Sandbox über eine dauerhafte Konfigurationsinjektion in einstellungen.jsonEine fehlende Datei beim Start bedeutete, dass die Sandbox diesen Pfad nicht korrekt schützte, was es bösartigem Code in der Sandbox ermöglichte, eine dauerhafte Konfiguration zu erstellen, die später beim Neustart von Claude Code mit Host-Rechten ausgeführt wurde. Außerdem wurde eine Umgehung der Domänenvalidierung in der vertrauenswürdigen WebFetch-Verarbeitung aufgedeckt, bei der startsWith() Logik könnten von Angreifern kontrollierte Domänen die Validierung passieren, wenn ihnen eine vertrauenswürdige Domänenzeichenfolge vorangestellt wird. Keines der beiden Probleme ist glamourös. Beides sind genau die Art von Details, die darüber entscheiden, ob eine "sicherere Agentenlaufzeit" tatsächlich sicherer ist. (GitHub)
In der folgenden Tabelle wird der Verlauf der öffentlichen Ausgaben in eine Forschungskarte und nicht in ein Änderungsprotokoll umgewandelt. (NVD)
| Kennung | Was gescheitert ist | Warum das wichtig ist | Fester Zustand |
|---|---|---|---|
| CVE-2025-59536 | Ein Fehler im Startup-Vertrauensdialog ermöglichte die Ausführung von Projektcode vor der Annahme des Vertrauens | Vertrauen war vor der Ausführung keine harte Grenze | Behoben in 1.0.111 |
| CVE-2026-21852 | Repo-kontrolliert ANTHROPIC_BASE_URL könnte Anfragen vor der Vertrauensabfrage umleiten | Repo-Konfiguration beeinflusst Netzwerkverhalten vor Vertrauen | Behoben in 2.0.65 |
| GHSA-mmgp-wc2j-qcv7 | Repo-gesteuerte Einstellungen könnten bypassPermissions vor dem Dialog "Vertrauen in den Arbeitsbereich | Die Haltung zur Genehmigung könnte vor der Zustimmung geschwächt werden | Behoben in 2.1.53 |
| GHSA-ff64-7w26-62rf | Fehlt einstellungen.json Pfad lässt Sandbox-Code dauerhafte Konfigurationen auf Host-Ebene erstellen | Die Ausführung in einer Sandbox könnte künftiges privilegiertes Verhalten fördern | Behoben in 2.1.2 |
| GHSA-vhw5-3g5m-8ggf | Schwache Domänenvalidierung lässt Angreiferdomänen an der Prüfung vertrauenswürdiger Präfixe vorbei | Automatische Netzwerkanfragen könnten die Infrastruktur des Angreifers erreichen | Behoben in 1.0.111 |
| GHSA-xq4m-mc3c-vvg3 und zugehörige Parser-Beratungen | Fehler bei der Shell- und Pfadanalyse umgingen Validierung und Schreibbeschränkungen | Permission UI ist nur so stark wie das Parsen von Befehlen | Über mehrere Versionen hinweg behoben |
Was diese Geschichte für Verteidiger besonders nützlich macht, ist die Tatsache, dass sie eine Taxonomie aufzeigt, nicht nur eine Patch-Warteschlange. Claude-Code-Probleme kehren immer wieder zu denselben Risikofamilien zurück: Vertrauensreihenfolge, Vorrang der Konfiguration, Mehrdeutigkeit des Parsers, Pfadvalidierung, dauerhafter Zustand und Netzwerkaustritt. Sobald Sie dieses Muster erkennen, hört "Claude-Code-Umgehung" auf, wie eine sensationelle Phrase zu klingen und beginnt, sich wie eine praktische Überprüfungskategorie zu lesen.
Eine Taxonomie für die Umgehung des Claude-Codes
Der nützlichste Weg, den Claude Code zu studieren, ist nicht das Auswendiglernen von Advisory IDs. Sie besteht darin, die Fehler in einige wenige wiederverwendbare Mechanismusklassen einzuteilen. Diese Klassen sind breit genug, um über Claude Code hinaus von Bedeutung zu sein, und konkret genug, um die Überprüfungsarbeit zu informieren.
Vertrauen Umgehung
Vertrauensumgehung ist die Klasse, bei der das Produkt behauptet, dass eine Entscheidungsgrenze besteht, aber ein Teil des Systems arbeitet, bevor diese Entscheidung endgültig ist. CVE-2025-59536 und CVE-2026-21852 sind die deutlichsten Beispiele. Eine davon erlaubte die Ausführung von Projektcode, bevor der Vertrauensdialog beim Start akzeptiert wurde; die andere erlaubte eine umgebungsgesteuerte Umleitung von Anfragen, bevor die Vertrauensabfrage erschien. GHSA-mmgp-wc2j-qcv7 gehört ebenfalls hierher, da die durch das Repo gesteuerten Einstellungen den Berechtigungsmodus beeinflussten, der für die Vertrauensbestätigung selbst maßgeblich war. Die Lektion ist architektonischer Natur: In einem System wie Claude Code muss Vertrauen alle Nebeneffekte einschließen, einschließlich der Konfigurationsauflösung, die spätere Nebeneffekte verändern kann. (NVD)
Konfiguration bis Ausführung
Dies ist die wichtigste Klasse, die von Sicherheitsteams immer noch unterschätzt wird. Hooks sind als deterministische Lebenszyklus-Automatisierung dokumentiert. Projektbezogenes MCP ist als gemeinsame Werkzeugkonfiguration in .mcp.json. Gemeinsame Projekteinstellungen sind ausdrücklich für die Versionskontrolle gedacht. Das bedeutet, dass ein Repository Konfigurationen enthalten kann, die mehr als nur Präferenzen beschreiben. Es kann Befehle planen, Tools verbinden und die Arbeitsweise des Agenten ändern. Die Claude-Code-Forschung von Check Point lässt sich am besten als Instanz dieser umfassenderen Klasse lesen: Die Konfiguration des Repositorys wurde zur Ausführungs- und Exfiltrationslogik. (Claude)
Erlaubnisabweichung
Ein Permission Drift liegt vor, wenn die tatsächliche Sicherheitslage lockerer ist, als der Benutzer denkt. Dies kann durch explizite Modusänderungen, vererbte Richtlinien, verwirrende Präzedenzfälle oder Genehmigungsmüdigkeit geschehen. Anthropics eigene Dokumente machen die Kompromisse deutlich: bypassPermissions läuft ohne Kontrollen, dontAsk lässt nur vorab zugelassene Werkzeuge zu, Plan recherchiert, ohne zu bearbeiten, und Auto verwendet Sicherheitsüberprüfungen im Hintergrund anstelle einer manuellen Genehmigung. Der Hinweis zur Umgehung des Vertrauensdialogs vom März 2026 ist von Bedeutung, weil er zeigt, wie eine von einem Repo kontrollierte Einstellungsdatei den Benutzer unbemerkt in eine freizügigere Haltung zwingen kann, bevor die Benutzeroberfläche mitteilt, was passiert ist. Das ist Permission Drift in seiner reinsten Form. (Claude)

Context Poisoning und Memory Poisoning
Das Speichermodell von Claude Code verdient mehr Aufmerksamkeit, als es in der allgemeinen Diskussion erhält. Anthropic sagt, dass Speicherdateien zu Beginn jeder Konversation geladen werden, dass CLAUDE.md zu Beginn der Sitzung geladen wird und dass Claude diese Dateien als Kontext und nicht als erzwungene Konfiguration behandelt. Diese Unterscheidung ist subtil, aber entscheidend. Eine Kontextdatei dreht nicht einen Booleschen Wert im Code um. Sie tut etwas Wahrscheinlicheres: Sie formt die Interpretation des Modells von Zielen, Risiken und Beschränkungen. In einem normalen Chat kann das nur die Ausgabe verzerren. In einer agentenbasierten Codierungs-Laufzeit ändert eine verzerrte Beurteilung, welche Tools aufgerufen, welche Dateien geöffnet und welche Shell-Aktionen sinnvoll erscheinen. Bei dieser Art von Speichervergiftung geht es nicht um einen einzigen bösartigen Satz. Es geht um eine dauerhafte Beeinflussung des Verhaltens. (Claude API-Dokumente)
Missbrauch von Delegationen
Die Delegation ist der Punkt, an dem es auf Subagenten und gebündelte Fähigkeiten ankommt. Laut Anthropic erben Unteragenten standardmäßig alle Werkzeuge der Hauptkonversation, einschließlich MCP-Werkzeuge. Wenn Teams den Werkzeugzugriff nicht explizit einschränken, kann der Delegationsgraph breiter werden als vom Betreiber beabsichtigt. Das Problem ist nicht, dass Subagenten von Natur aus unsicher sind. Das Problem ist vielmehr, dass die Delegierung die Verteilung von Befugnissen verschleiert. Ein Benutzer mag die Hauptkonversation als die Einheit des Vertrauens betrachten, aber die tatsächliche Autorität umfasst nun alle Hilfsagenten, die unter dieser Autorität erzeugt werden können. In Bezug auf die Sicherheit lautet die Frage nicht nur "Was kann der Hauptagent tun?", sondern "Was kann er seine Kinder tun lassen?" (Claude API-Dokumente)
Validierungsgrenze Einsturz
Diese Klasse sammelt die Hinweise zu Shell-Parsing und Schreibbeschränkungen. Die Anthropic-Dokumente betonen Schutzmaßnahmen wie Eingabebereinigung, Befehlsblocklisten, Fail-closed-Matching, Prüfungen auf verdächtige Befehle und Schreibbeschränkungen für das aktuelle Arbeitsverzeichnis. Die Geschichte der Empfehlungen zeigt, wie zerbrechlich diese Schicht sein kann, wenn die Shell-Grammatik, die Pfadbehandlung oder die Umgebungssemantik falsch interpretiert werden. finden.verrohrt sed, $IFS, kurze Fahnen, cdund die ZSH-Clobber-Syntax sind keine zufällige Nebensächlichkeit. Sie erinnern daran, dass ein KI-Produkt, das eine sichere Shell-Ausführung verspricht, eine Schicht zum Verstehen von Befehlen unter realen Shells implementieren muss. Diese Schicht ist sicherheitskritischer Code, und das ist schwer. (Claude)
Der Wert dieser Taxonomie liegt nicht in der akademischen Ordentlichkeit. Sie gibt den Verteidigern eine Möglichkeit, die richtigen Fragen zu stellen. Nicht "hat Claude Code einen Fehler?", sondern "welche dieser Mechanismusklassen stellen wir in unserer Umgebung bereits zur Verfügung, und welche Schichten verhindern, dass eine in die nächste übergeht?"
Claude Code Detection and Validation, Was in echten Repositories zu prüfen ist
Der schnellste Weg, Zeit für die Sicherheit von Agententools zu verschwenden, ist die Jagd nach einmaligen Exploits und das Ignorieren der langweiligen Oberflächen, die immer wieder in echten Advisories auftauchen. Bei Claude Code beginnt die ertragreiche Überprüfung mit dem Repository-Inhalt und den lokalen Richtlinien, nicht mit exotischem Reverse Engineering. Die erste Frage sollte sein, welche Dateien in einem Repository Claude Code vor oder während der Ausführung beeinflussen können. Dazu gehören mindestens .claude/settings.json, .claude/settings.local.json, .mcp.json, CLAUDE.md, SPEICHER.mdund alle Plugin- oder Agentendefinitionen, die das Projekt voraussichtlich verwenden wird. Die Dokumentation von Anthropic bestätigt, dass projektübergreifende Einstellungen, projektspezifische MCP und Speicherdateien allesamt erstklassige Konfigurationsoberflächen sind. (Claude)
Ein praktischer erster Durchgang ist ein Repository-Scan, der Konfigurationsdateien und verdächtige Schlüssel kennzeichnet. Es geht nicht darum, eine Kompromittierung nachzuweisen. Es geht darum, festzustellen, wo der Inhalt des Projektarchivs das Laufzeitverhalten verändert.
finden . -maxdepth 4 -type f \
\( -pfad "*/.claude/settings.json" \
-o -pfad "*/.claude/Einstellungen.local.json" \
-o -name ".mcp.json" \
-o -name "CLAUDE.md" \
-o -name "MEMORY.md" \) \
| sed 's|^\./||'
rg -n --hidden --no-ignore-vcs \
'permissions\.defaultMode|bypassPermissions|dangerously-skip-permissions|dontAsk|hooks|ANTHROPIC_BASE_URL|mcpServers|curl\s+-fsSL|wget\s+http|powershell|osascript|bash\s+-c|npx\s+@playwright/mcp' .
Diese Art von Scan ist nicht spezifisch für ein einzelnes CVE, was genau der Grund ist, warum er nützlich ist. Sie fängt die Klasse von Risiken ab, die in der öffentlichen Geschichte immer wieder auftauchen: Ausführungshaken, riskante Voreinstellungen für Berechtigungen, Netzwerkumleitungen und die Konnektivität von repo-definierten Tools. Die Anthropic-Dokumente empfehlen auch ausdrücklich einen hygienischen Umgang mit nicht vertrauenswürdigen Inhalten, einschließlich der Überprüfung der vorgeschlagenen Befehle vor der Genehmigung, der Vermeidung der direkten Weiterleitung nicht vertrauenswürdiger Inhalte an Claude und der Verwendung von VMs bei der Interaktion mit externen Webdiensten. Diese Empfehlungen stehen im Einklang mit der Einstellung, dass die Überprüfung der Konfiguration im Vordergrund steht. (Claude)
Für eine tiefergehende Triage ist es hilfreich, das JSON zu parsen, anstatt sich ausschließlich auf grep zu verlassen. Das folgende Python-Beispiel ist absichtlich konservativ. Es versucht nicht, irgendetwas auszuführen oder Claude Code zu emulieren. Es kennzeichnet lediglich Bedingungen, die eine menschliche Überprüfung verdienen.
json importieren
from pathlib import Pfad
VERDÄCHTIGE_BEFEHL_TOKENS = [
"curl -fsSL",
"wget http",
"bash -c",
"powershell",
"osascript",
"nc",
"socat",
]
def load_json(path: Path):
try:
return json.loads(path.read_text())
except Exception as exc:
return {"_parse_error": str(exc)}
def audit_claude_settings(path: Path):
data = load_json(path)
findings = []
if "_parse_error" in data:
findings.append(f"{path}: parse error: {data['_parse_error']}")
return findings
mode = (
data.get("permissions", {})
.get("defaultMode")
)
if mode in {"bypassPermissions"}:
findings.append(f"{path}: gefährlicher Standardmodus: {mode}")
hooks = data.get("hooks", {})
if hooks:
findings.append(f"{pfad}: hooks vorhanden: {', '.join(hooks.keys())}")
serialisiert = json.dumps(hooks)
for token in SUSPICIOUS_COMMAND_TOKENS:
if token in serialized:
findings.append(f"{path}: suspicious hook token found: {token}")
text = json.dumps(Daten)
if "ANTHROPIC_BASE_URL" in text:
findings.append(f"{Pfad}: enthält ANTHROPIC_BASE_URL override")
return findings
def audit_mcp(path: Path):
data = load_json(path)
findings = []
if "_parse_error" in data:
findings.append(f"{path}: parse error: {data['_parse_error']}")
return findings
server = data.get("mcpServer", {})
for name, cfg in server.items():
if isinstance(cfg, dict):
command = cfg.get("command", "")
env = cfg.get("env", {})
if befehl:
findings.append(f"{path}: MCP-Server '{name}' führt Befehl aus: {command}")
if env:
findings.append(f"{Pfad}: MCP-Server '{Name}' definiert env-Schlüssel: {list(env.keys())}")
return findings
targets = []
for p in Path(".").rglob("*"):
if p.is_file() und str(p).endswith(".claude/settings.json"):
targets.extend(audit_claude_settings(p))
if p.is_file() und p.name == ".mcp.json":
targets.extend(audit_mcp(p))
for finding in targets:
print(finding)
Diese Art der Prüfung ist wichtig, da das dokumentierte Funktionsmodell bereits angibt, wo das Risiko kumuliert. Hooks sind deterministische Ausführungspunkte. Projektübergreifende MCP ist eine quellengesteuerte Werkzeugkonfiguration. Berechtigungseinstellungen können in der Versionskontrolle überprüft werden. Der Speicher wird beim Start der Sitzung geladen. Sie brauchen kein Exploit-Kit, um aus diesen Fakten etwas Nützliches zu lernen. Sie brauchen Dateisichtbarkeit und eine Überprüfungsrichtlinie. (Claude)
Auch Laufzeit-Telemetrie ist wichtig. CVE-2026-21852 ist ein klares Beispiel dafür, warum frühe Netzwerkereignisse Aufmerksamkeit verdienen. Wenn ein Entwickler Claude Code in einem neuen Repository startet und Sie unerwartete ausgehende Anfragen sehen, insbesondere an nicht-anthropische Hosts oder bevor Vertrauen sinnvoll aufgebaut ist, sollte dies als ernsthafter Untersuchungspfad behandelt werden. Die Dokumentation von Anthropic besagt, dass Werkzeuge, die Netzwerkanfragen stellen, standardmäßig eine Genehmigung benötigen, aber ihr eigenes Advisory hat gezeigt, dass die Konfigurationsreihenfolge diese Erwartung unter bestimmten Bedingungen untergraben könnte. Die richtige betriebliche Reaktion besteht nicht darin, der Aufforderung blind zu vertrauen. Sie besteht darin, die Anfragen zu protokollieren, zu korrelieren und zu überprüfen. (Claude)
Eine der saubersten Betriebskontrollen besteht darin, die Wahl des Modus zu einem expliziten Teil des Arbeitsablaufs zu machen, anstatt ihn zur Gewohnheit werden zu lassen. Die dokumentierten Modi von Anthropic unterstützen dies bereits.
# Durchsuchen eines Repositorys und Planen von Änderungen ohne Bearbeitung
claude --permission-mode plan
# Ausführen nur vorab genehmigter Werkzeuge in einer gesperrten Umgebung
claude --permission-mode dontAsk
# Niemals auf einer normalen Entwickler-Workstation verwenden
# Nur für isolierte Container oder Wegwerf-VMs reservieren
claude --permission-mode bypassPermissions
Der Punkt ist nicht, dass ein Modus alles löst. Der Punkt ist, dass Teams einen Modus wählen sollten, der auf dem Vertrauensniveau des Repositorys und der Umgebung basiert. Plan ist ein guter Standard für den ersten Kontakt mit unbekanntem Code. dontAsk ist nützlich, wenn Sie genau vorgeben können, was erlaubt ist. bypassPermissions gibt es zwar, aber laut Anthropics eigenen Unterlagen deaktiviert es die Sicherheitsprüfungen und bietet keinen Schutz gegen sofortige Injektionen oder unbeabsichtigte Aktionen. Behandeln Sie es wie einen Vorfall, der nur darauf wartet zu passieren, es sei denn, die Umgebung ist absichtlich entbehrlich. (Claude)
Claude Code Hardening für Teams
Die meisten Teams brauchen kein heroisches Sicherheitsprogramm, um das Claude-Code-Risiko zu verringern. Sie brauchen eine saubere Trennung zwischen der kollaborativen Konfiguration und der ausführungsrelevanten Konfiguration. Das ist das wichtigste Prinzip der Absicherung. Wenn Sie zulassen, dass beliebige Repositories Hooks, Berechtigungsvorgaben oder projektspezifische MCP-Server auf einem Entwickler-Laptop definieren, der auch echte Anmeldeinformationen und eine große Netzwerkreichweite besitzt, dann behandeln Sie Bequemlichkeit als Ersatz für Vertrauen. Das ist genau die Annahme, die in den öffentlichen Anleitungen bestraft wird. (Claude)
Die erste Richtlinie sollte einfach sein: Unbekannte Repositories starten in einem Modus mit geringerer Kapazität, idealerweise in einer Wegwerfumgebung. Die Anthropic-Dokumente empfehlen ausdrücklich VMs bei der Interaktion mit externen Webdiensten und sagen bypassPermissions ist nur für isolierte Container und VMs geeignet. Dieser Ratschlag ist mehr als Hygiene. Es ist ein Eingeständnis, dass der Explosionsradius eines agentenbasierten Codierungswerkzeugs über das hinausgehen kann, was eine einzelne Genehmigungsaufforderung mitteilt. Die Isolationsgrenze sollte die Umgebung sein, nicht die Erinnerung des Benutzers an das, was er angeklickt hat. (Claude)
Die zweite Politik ist die Behandlung .claude/, .mcp.json, CLAUDE.mdund Plugin-bezogene Dateien als Code-Review-Ziele, nicht als harmlose Metadaten. Codebesitzer sollten Änderungen an diesen Dateien überprüfen. Sicherheitsprüfer sollten sie auf die gleiche Weise prüfen, wie sie CI-Workflows, Dockerdateien oder Terraform prüfen würden. Der Grund dafür ist strukturell. In der Dokumentation von Anthropic heißt es, dass projektübergreifende Einstellungen Berechtigungen, Hooks und MCP-Server enthalten können, und dass projektübergreifende MCP speziell für die Quellcodekontrolle konzipiert ist. Das allein reicht aus, um ein Review Gate zu rechtfertigen. Sie brauchen nicht auf ein neues CVE zu warten. (Claude)
Die dritte Strategie besteht darin, das, was man kann, zu zentralisieren. Die MCP-Dokumente von Anthropic beschreiben managed-mcp.json als eine Möglichkeit für Administratoren, die ausschließliche Kontrolle über MCP-Server zu übernehmen und Benutzer daran zu hindern, beliebige Server außerhalb dieser verwalteten Gruppe hinzuzufügen. Das ist das richtige Modell für Unternehmen mit bedeutenden internen Systemen. Wenn Ihre Entwickler jeden MCP-Server anhängen können, den sie im Internet finden, ist Ihr eigentliches Sicherheitsproblem nicht mehr die "Toolnutzung". Es ist die Lieferkette und die Delegation. Managed MCP ist nicht die Antwort auf jedes Problem, aber es ist ein deutlicher Hinweis darauf, dass die Konnektivität von Tools geregelt und nicht improvisiert werden sollte. (Claude)
Die vierte Richtlinie besteht darin, genau zu sagen, was Sandboxing für Sie bedeutet und was nicht. Die Sandbox-Dokumente von Anthropic sind hier hilfreich, weil sie ehrlich sind. Sandboxing isoliert Bash-Unterprozesse mit Dateisystem- und Netzwerkkontrollen. Das bedeutet nicht, dass alle Claude-Code-Funktionen innerhalb der gleichen Isolationsgrenze laufen. Eingebaute Datei-Tools verwenden das Berechtigungssystem direkt, und die Computernutzung erfolgt auf dem echten Desktop und nicht in der isolierten Bash-Umgebung. Teams, die "Sandbox" hören und nicht weiter darüber nachdenken, werden enttäuscht werden. Sandboxing ist wertvoll, insbesondere gegen Shell-Aktivitäten, die durch Prompt-Injektionen ausgelöst werden, aber es ist keine universelle Hülle für das gesamte Agentenverhalten. (Claude)
Die fünfte Richtlinie besteht darin, dass evidenzbasierte Arbeitsabläufe den autonomen Arbeitsabläufen vorzuziehen sind. Die eigene Produktausrichtung von Anthropic weist in diese Richtung. Claude Code Security, das im Februar 2026 angekündigt wurde, ist nicht als "lass das Modell deinen Code unbeaufsichtigt patchen" konzipiert. Anthropic sagt, dass es Codebasen scannt, gezielte Patches vorschlägt, jeden Fund durch einen mehrstufigen Verifizierungsprozess laufen lässt, Schweregrad und Vertrauen zuweist und nichts ohne menschliche Zustimmung anwendet. Das ist kein Marketing-Gedöns. Es ist eine Aussage darüber, wie der ausgereifte Einsatz eines agentenbasierten Kodierungssystems unter echtem Sicherheitsdruck aussehen kann. Die Verifizierung, nicht nur die Generierung, ist das Produktproblem. (Anthropisch)
Das gleiche Prinzip gilt für die offensive Seite. Penligents öffentliches englisches Schreiben über Claude als Pentest-Kopilot plädiert für einen evidenzbasierten Arbeitsablauf, bei dem das Modell hilft, über Angriffswege und Entwurfsprüfungen nachzudenken, aber nicht von sich aus Hypothesen in Beweise umwandeln kann. Das ist hier der richtige Ansatz. Eine Argumentationsebene kann sehr leistungsfähig sein, ohne die endgültige Entscheidung über die Ausnutzbarkeit zu treffen. In der Praxis erzielen Teams sicherere Ergebnisse, wenn der Agent eine Komponente in einer Verifizierungskette ist, die Beweise, eine begrenzte Ausführung und eine menschliche Überprüfung sicherstellt. (Sträflich)
Die sechste Richtlinie besteht darin, die Exposition von Netzwerken und Anmeldeinformationen zu instrumentieren. CVE-2026-21852 sollte die Vorstellung zerstören, dass lokale KI-Tools "nur lokal" sind. Wenn eine repo-kontrollierte Einstellung das API-Routing beeinflussen kann, bevor Vertrauen aufgebaut ist, dann brauchen Entwickler-Laptops die gleichen Annahmen zur ausgehenden Sichtbarkeit, die Sie auch für interne Build-Runner oder CI-Jobs anwenden würden. Überwachen Sie zumindest unerwartete Domänen, halten Sie die Lebensdauer von Schlüsseln so kurz wie möglich und wechseln Sie die Schlüssel, wenn die Exposition plausibel ist, anstatt auf einen perfekten Beweis zu warten. Die Empfehlung von Anthropic beschreibt einen Vorvertrauenspfad für potenzielle API-Schlüsselverluste. Teams sollten dies als eine Lektion auf Flottenebene verstehen, nicht als eine Fußnote zu einer einzelnen Veröffentlichung. (GitHub)
Claude Code Security zeigt, wohin sich die Branche entwickelt
Anthropics Ankündigung von Claude Code Security vom Februar 2026 ist auch dann wertvoll, wenn Sie die Funktion nie nutzen. Sie zeigt auf, wie Anthropic glaubt, dass die Agenten der Grenzkodierung für Verteidiger operationalisiert werden müssen. In der Ankündigung heißt es, dass Claude Code Security Gründe für den Code sucht, anstatt nur bekannte Muster abzugleichen, und dann jedes Ergebnis in einem mehrstufigen Verifizierungsprozess erneut prüft, um falsch positive Ergebnisse herauszufiltern, bevor ein Analyst sie sieht. Die Ergebnisse werden nach Schweregrad und Vertrauenswürdigkeit eingestuft, und nichts wird ohne menschliche Zustimmung angewendet. Dies ist eine auffallend konservative Form für eine KI-Funktion, und das aus gutem Grund. Wenn die Laufzeit leistungsstark ist, ist die fehlende Komponente nicht mehr die Generierung. Es ist die disziplinierte Überprüfung. (Anthropisch)
Diese Design-Entscheidung trägt auch dazu bei, die breitere Beratungsgeschichte des Claude Code zu erklären. Die meisten der öffentlichen Probleme waren kein Versagen der "KI-Kreativität". Es waren Fehler in der Ausführungssteuerung. Ein Sicherheitsprodukt, das lediglich die Modellfähigkeit erweitert, ohne die Validierung und Kontrolle zu verbessern, wird diese Fehler verschlimmern, nicht verbessern. Die Ankündigung des Auto-Modus von Anthropic macht einen ähnlichen Punkt aus einem anderen Blickwinkel deutlich. Der Auto-Modus fügt eine Prompt-Injection-Sonde für Tool-Ausgaben und einen Transkript-Klassifikator für Aktionen hinzu und versucht so, gefährliches Verhalten zu erkennen und gleichzeitig die Genehmigungsmüdigkeit zu verringern. Das Vorhandensein dieser Ebenen ist eine stillschweigende Anerkennung der Tatsache, dass Genehmigungen allein nicht ausreichen, wenn der Agent fähig und der Mensch beschäftigt ist. (Anthropisch)
Für offensive Teams ist die Lektion fast symmetrisch. Reasoning-first-Assistenten können wertvoll sein, aber die Einheit des Wertes ist nicht "der Agent hatte eine Idee". Die Einheit des Wertes ist "der Arbeitsablauf hat ein vertretbares Ergebnis hervorgebracht". Aus diesem Grund bleiben von Prüfern unterstützte offensive Systeme auch dann relevant, wenn die Kodierassistenten besser werden. Das öffentliche Material von Penligent über KI-Pentest-Workflows macht diese Unterscheidung direkt: Die wichtige Grenze ist die zwischen intelligenten Vorschlägen und verifizierten Ergebnissen. Das ist nicht nur eine Produktaussage. Es ist ein Grundsatz der Sicherheitsarchitektur. (Sträflich)
Claude Code lehrt daher zwei Lektionen auf einmal. Die eine ist negativ: Projektdateien, Berechtigungsmodi, Werkzeugbusse und Shell-Parsing können zusammen ein echtes Umgehungsrisiko darstellen. Die andere ist positiv: Die richtige Antwort ist nicht das völlige Verbot von agentenbasierten Werkzeugen. Sie besteht darin, die Kluft zwischen Argumentation und Verifizierung zu verringern und Vertrauensentscheidungen näher an reale Grenzen heranzuführen als an dekorative Aufforderungen. Die Produktausrichtung von Anthropic und die evidenzbasierte Workflow-Sprache von Penligent weisen beide auf dasselbe ausgereifte Modell hin: begrenzte Handlungsfähigkeit, bessere Verifizierung, explizite Steuerung. (Anthropisch)
Warum Claude Code zu einem Referenzfall für die Sicherheit von Agententools wurde
Claude Code ist nicht einzigartig, weil er Bugs hatte. Jede sicherheitsrelevante Laufzeitumgebung hat Bugs. Claude Code ist einzigartig, weil das öffentliche Material reichhaltig genug ist, um das gesamte Grenzproblem an einem Ort zu zeigen. Anthropic dokumentiert die mächtigen Oberflächen der Laufzeitumgebung offen. GitHub-Advisories dokumentieren, wo bestimmte Grenzen versagt haben. NVD fasst die hochwirksamen CVEs zusammen. Check Point zeigt, wie Projektdateien zu einem Ausführungs- und Exfiltrationspfad werden können. Die Berichterstattung über die Source-Maps vom 31. März deutet darauf hin, dass die Kosten für eine White-Box-Inspektion jetzt auch geringer sein könnten, selbst wenn man sie mit Vorsicht behandelt. Diese Kombination macht Claude Code zu einem der besten verfügbaren Referenzfälle für die Untersuchung der Sicherheit von agentenbasierten Entwicklerwerkzeugen in der Öffentlichkeit. (Claude)
Die richtige Schlussfolgerung ist nicht "Claude Code ist kaputt". Die richtige Schlussfolgerung ist, dass agentenbasierte Kodierungssysteme eine neue Art der Überprüfung erzwingen. Man muss sich fragen, wie Repositories die Richtlinien beeinflussen, wie die Reihenfolge des Vertrauens festgelegt wird, wie Werkzeuge delegiert werden, wie der Speicher erhalten bleibt, wie die Shell-Absicht validiert wird, wie der Netzwerkaustritt geregelt wird und wie die Verifizierung vom Optimismus getrennt wird. Diese Fragen gelten heute für Claude Code, und sie werden morgen für jede ernstzunehmende Laufzeitumgebung für agentenbasierte Programmierung gelten. (Claude API-Dokumente)
Wenn es einen Satz gibt, der es wert ist, in jede künftige Überprüfung mitgenommen zu werden, dann ist es dieser: In agentenbasierten Kodierungssystemen sind Projektdateien nicht mehr nur Eingaben. Sie sind Teil der Steuerungsebene. Das ist die Grenzverschiebung, die die Claude-Code-Ratschläge unübersehbar gemacht haben.
Weitere Lektüre und Referenzen
Anthropic, Claude Code-Übersicht. (Claude)
Anthropic, Claude Dokumentation zur Sicherheit des Codes. (Claude)
Anthropic, Claude Code-Haken Dokumentation. (Claude)
Anthropic, Claude Code MCP Dokumentation. (Claude)
Anthropic, Claude Code Erlaubnismodi. (Claude)
Anthropic, Claude Code auto mode engineering note. (Anthropisch)
Anthropic, Claude Code Security Ankündigung. (Anthropisch)
NVD, CVE-2025-59536. (NVD)
NVD, CVE-2026-21852. (NVD)
Anthropische GitHub-Beratung, Umgehung des Arbeitsbereich-Vertrauensdialogs über repo-gesteuerte Einstellungsdatei. (GitHub)
Check Point Research, Claude Code Projektdateien, RCE, und API Token Exfiltration. (Check Point Forschung)
Penligent, Claude AI für Pentest Copilot, Aufbau eines beweisorientierten Workflows mit Claude Code. (Sträflich)
Penligent, Claude Code-Projektdateien wurden zu einem RCE- und API-Schlüssel-Exfiltrationspfad. (Sträflich)
Penligent, Agentic Security Initiative, Absicherung von Agentenanwendungen in der MCP-Ära. (Sträflich)
Homepage von Penligent. (Sträflich)

