Quellcode-Leak bei Claude Code: Was es über Agentenarchitektur verrät

Claude Code wurde zu einem viel heißeren Suchbegriff, sobald der Ausdruck Quellcode-Leak die Runde machte. Diese Reaktion ist nachvollziehbar. Wenn bei einem KI-Coding-Agenten Interna durchsickern, wollen die Leute sofort wissen, was offengelegt wurde, ob das Produkt noch sicher zu verwenden ist und was der Leak darüber verrät, wie moderne Agentensysteme wirklich funktionieren.

Die nützliche Antwort besteht nicht darin, den exakten System-Prompt eines anderen zu veröffentlichen oder den geleakten Code in eine schrittweise Nachbauanleitung zu verwandeln. Die nützliche Antwort besteht darin, die sicherheitsäquivalente Architektur hinter einem Tool wie Claude Code zu verstehen: wie eine Anfrage zu Kontext wird, wie sich die Tool-Schleife selbst repariert, wie Berechtigungen durchgesetzt werden, wie der Speicher komprimiert wird und warum Prompt-Injection weitaus wichtiger ist als Gerüchte über eine einzelne geleakte Datei.

Die jüngsten Veröffentlichungen von Anthropic selbst machen diesen Rahmen noch relevanter. In seinem Beitrag vom März 2026 über den Auto-Modus von Claude Code gibt Anthropic an, dass Benutzer 93 % der Berechtigungsaufforderungen genehmigen, und erklärt, dass der Auto-Modus eine serverseitige Prompt-Injection-Prüfung für Tool-Ausgaben sowie einen Aktionsklassifikator vor der Ausführung hinzufügt. In seiner Forschung zu Browser-Agenten sagt Anthropic auch, dass Prompt-Injection eines der schwierigsten ungelösten Probleme für handlungsorientierte KI-Systeme bleibt. Zusammengenommen sagen diese beiden Punkte mehr über die Zukunft von KI-Coding-Agenten aus als jedes geleakte Prompt-Fragment es je könnte.

TL;DR

1. Der Quellcode-Leak von Claude Code ist wichtig, weil er Implementierungsentscheidungen aufdeckt, nicht weil er ein zuverlässiges Rezept zur Nachbildung des Produkts liefert.
2. Der sicherste Weg, über Claude Code zu diskutieren, ist auf Architekturebene: Prompt-Zusammenstellung, Tool-Schleifen, Speicher, Berechtigungen und Erweiterungsschnittstellen.
3. Ein Coding-Agent funktioniert in der Regel, indem er eine Basisanweisungsschicht, eine Benutzeranfrage, Repository-spezifische Anleitungen, Tool-Schemata und abgerufenen Kontext zu einem einzigen funktionierenden Prompt-Zustand kombiniert.
4. Die eigentliche Sicherheitsgeschichte ist die Prompt- und Tool-Injection, nicht nur die Geheimhaltung von Prompts.
5. Das Prinzip der geringsten Rechte, Schwärzung, Ausgabefilterung, Sandboxing und Audit-Protokolle sind wichtiger als der Versuch, jeden internen String für immer zu verbergen.
6. Multi-Agenten-Workflows, Slash-Befehle, Speicher, MCP, LSP, Plugins und Skills erhöhen alle die Nützlichkeit, aber jeder fügt eine weitere Oberfläche hinzu, die sorgfältig abgegrenzt und beobachtet werden muss.

Warum der Quellcode-Leak von Claude Code wichtig ist – und was er nicht beweist

Ein Quellcode-Leak von Claude Code kann Ihnen etwas Reales über die Produktkategorie beibringen. Er kann zeigen, dass Coding-Agenten keine Magie sind. Sie sind geschichtete Systeme mit Anweisungen, Tools, Richtlinien, Kontextmanagement, UI-Verknüpfungen und Wiederherstellungslogik. Dieser Teil ist nützlich.

Was er nicht beweist, ist, dass jeder, der die geleakten Interna sieht, plötzlich das gesamte Produkt reproduzieren kann. Das tatsächliche Verhalten eines Agenten hängt vom umgebenden Stack ab: Modellverhalten, Sicherheits-Wrapper, Berechtigungsprüfungen, Tool-Verträge, serverseitige Sonden, clientseitige Durchsetzung, Zustandsmanagement und betriebliche Abstimmung. Ein geleaktes Quellcode-Fragment ist eine Momentaufnahme. Ein Produktionsagent ist ein lebendes System.

Diese Unterscheidung ist wichtig, weil viele Diskussionen über einen Quellcode-Leak schnell unseriös werden. Die Leute fixieren sich auf das dramatischste Detail, normalerweise eine Prompt-Formulierung oder einen internen Befehlsnamen, und übersehen die härtere Wahrheit: Moderne KI-Agenten werden weniger durch einen einzigen Master-Prompt geformt als durch eine ganze Regelschleife.

Wenn Sie Claude Code nach dem Leak bewerten, lautet die richtige Frage nicht: „Kann ich den versteckten Prompt sehen?“ Sondern: „Welche Sicherheitsgrenzen gelten auch dann noch, wenn einige Interna öffentlich werden?“ Das ist die Frage, die sich ernsthafte Käufer, technische Leiter und Sicherheitsteams stellen sollten.

Eine sicherheitsäquivalente Sicht auf den System-Prompt-Assembly-Flow von Claude Code

Auf einer hohen Ebene folgt ein Tool wie Claude Code wahrscheinlich demselben Muster, das die meisten ernsthaften Coding-Agenten heute verwenden.

Erstens gibt es eine Basisanweisungsschicht. Dies ist der beständige Rollen- und Richtlinienrahmen, der dem Modell mitteilt, welche Art von Assistent es ist, welche Sicherheitsregeln wichtig sind und wie es sich in Bezug auf Tools, Benutzerabsichten und sensible Aktionen verhalten soll.

Zweitens gibt es eine Aufgabenschicht. Diese umfasst die Anfrage des Benutzers, den aktuellen Arbeitsverzeichnis- oder Repository-Kontext und alle lokalen Anweisungsdateien, die Projektnormen erklären. Die Dokumentation von Claude Code zu CLAUDE.md und zum Speicher macht deutlich, dass Anleitungen auf Repository-Ebene und beständige Anweisungen Teil der Arbeitsumgebung sind, auch wenn sie nicht dasselbe wie eine harte Durchsetzung sind.

Drittens gibt es eine Fähigkeitenschicht. Hier werden Tool-Schemata, der Berechtigungsstatus, Erweiterungsschnittstellen und agentenspezifische Befehle in die Sitzung eingebunden. Das Modell wird nicht nur gebeten zu antworten. Ihm wird mitgeteilt, welche Tools existieren, wofür jedes Tool da ist und welche Einschränkungen gelten.

Viertens gibt es eine abgerufene Kontextschicht. Diese kann relevante Dateien, Testergebnisse, Shell-Resultate, frühere Zusammenfassungen, Speichereinträge oder von externen Systemen abgerufene Inhalte umfassen. Diese Schicht ändert sich während der Sitzung kontinuierlich.

Der praktische Punkt ist einfach: Der System-Prompt ist kein heiliger Absatz. Er ist besser als eine dynamische Assembly-Pipeline zu verstehen. Das ist für die Sicherheit wichtig, da sich Verteidiger darauf konzentrieren sollten, was in diese Pipeline gelangt, wie es gekennzeichnet wird und welche Schichten außerhalb des Modells durchgesetzt werden.

Wie sich die Tool-Aufruf-Schleife selbst repariert

Eines der aufschlussreichsten Dinge an einem Coding-Agenten ist nicht, dass er Tools aufrufen kann. Sondern, dass er sich oft erholen kann, wenn ein Tool-Aufruf fehlschlägt.

Ein normaler Loop sieht in etwa so aus:

1. Der Benutzer fordert eine Änderung an.

2. Der Agent entscheidet, dass er Beweise benötigt, also liest er Dateien, sucht oder führt einen Befehl aus.

3. Das Tool gibt eine Ausgabe zurück.

4. Der Agent interpretiert diese Ausgabe, aktualisiert seinen Plan und antwortet entweder oder versucht einen weiteren Tool-Aufruf.

Der interessante Teil ist das Wiederholungsverhalten. Wenn ein Befehl fehlschlägt, ein Dateipfad falsch ist oder eine Testausgabe dem ersten Plan widerspricht, kann der Agent den Umfang eingrenzen, den Befehl ändern, eine andere Datei öffnen oder um Genehmigung bitten, bevor er eskaliert. Das ist es, was diese Systeme weniger wie eine Autovervollständigung und mehr wie Operatoren wirken lässt.

Aber derselbe Loop ist auch der Ort, an dem Tool-Injection gefährlich wird. Der Agent liest nicht nur vertrauenswürdige Dateien. Er kann Protokolle, Shell-Ausgaben, Kommentare, Issue-Texte, generierten Code oder Inhalte lesen, die über Integrationen abgerufen werden. Die Anleitung zur Prompt-Injection von OWASP warnt ausdrücklich davor, dass sich indirekte Angriffe in Code-Kommentaren, Dokumentationen, Merge-Requests, E-Mails und abgerufenen Webseiten verstecken können. Sobald man den Loop versteht, versteht man auch das Risiko: Nicht vertrauenswürdige Ausgaben können versuchen, zu neuen Anweisungen zu werden.

Deshalb ist das Auto-Modus-Design von Anthropic bemerkenswert. Anthropic gibt an, zwei Verteidigungsebenen zu verwenden: eine für das, was Claude liest, und eine für das, was Claude tut. Auf der Eingabeseite scannt eine serverseitige Sonde Tool-Ausgaben wie gelesene Dateien, Shell-Ausgaben, Web-Abrufe und externe Tool-Antworten, bevor sie in den Agentenkontext gelangen. Auf der Aktionsseite bewertet ein Klassifikator die vorgeschlagene Aktion vor der Ausführung. Das ist genau die Art von Architektur, die man sich für einen Coding-Agenten mit hohen Berechtigungen wünscht.

Die Abfrage-Pipeline: Von der Benutzerabsicht zum umsetzbaren Kontext

Wenn Sie ein klareres mentales Modell für Claude Code wünschen, stellen Sie es sich eher als Abfrage-Pipeline denn als Chatbot vor.

Ein starker Agent muss normalerweise fünf Aufgaben nacheinander erledigen.

1. Absicht interpretieren: Was fragt der Benutzer eigentlich?
2. Kontext sammeln: Welche Dateien, Befehle, Dokumente, Erinnerungen oder Tools sind relevant?
3. Ausführung planen: Was ist der nächste Schritt mit dem geringsten Risiko?
4. Ausgaben validieren: Hat das Tool-Ergebnis den Plan unterstützt oder einen Fehler oder Angriff aufgedeckt?
5. Zustand komprimieren: Was sollte gespeichert, zusammengefasst oder verworfen werden, damit die Sitzung nützlich bleibt?

Diese Pipeline ist wichtig, weil sie erklärt, warum der genaue Prompt-Text weniger wichtig ist, als die Bediener denken. Kleine Änderungen im Wortlaut sind von Bedeutung, aber der größere Qualitätsfaktor ist, ob die Pipeline konsistent die richtigen Beweise einbringt und die falschen zurückweist.

Hier kommt auch die Kontextkomprimierung ins Spiel. Große Repositories erzeugen zu viel Zustand, um jedes rohe Token für immer im Kontext zu behalten. Gute Agenten fassen also zusammen, komprimieren und laden selektiv neu. Die Speicher-Dokumente von Claude Code beschreiben sowohl CLAUDE.md als auch den automatischen Speicher als Mechanismen zur Verwaltung dauerhafter Anleitungen und abgerufener Kontexte. In der Praxis bedeutet das, dass das Modell oft mit einer Mischung aus rohen Beweisen und Zusammenfassungen arbeitet. Hilfreich für die Benutzerfreundlichkeit; riskant, wenn der Speicher vergiftet wird.

Kontextkomprimierung, Speicher und das Risiko der Speichervergiftung

Der Speicher ist einer der praktischsten und am meisten missverstandenen Teile des Agenten-Designs.

Ohne Speicher vergisst ein Agent nützliche Präferenzen, frühere Entscheidungen und wiederkehrende Repo-Einschränkungen. Mit Speicher wird er schneller, maßgeschneiderter und schwieriger anzugreifen, da er stabile Betriebsregeln beibehalten kann. Aber der Speicher kann auch zu einer Persistenzschicht für schlechte Daten werden.

Die Anleitung zur KI-Agenten-Sicherheit von OWASP spricht Memory Poisoning (Speichervergiftung) direkt an: Bösartige Inhalte können im Agentenspeicher abgelegt werden und zukünftige Sitzungen beeinflussen. Diese Warnung ist für jede Diskussion über den Quellcode-Leak von Claude Code von Bedeutung, denn sobald man akzeptiert, dass Prompts dynamisch zusammengestellt werden, erkennt man, dass der gespeicherte Kontext Teil der Prompt-Oberfläche ist.

Gute Speicherhygiene wirkt langweilig, und genau deshalb funktioniert sie:

1. Speicher auf Benutzer, Repo oder Sitzung beschränken
2. Wenn möglich, kurze Zusammenfassungen anstelle von rohen Transkripten speichern
3. Persistenz von Geheimnissen, Token oder rohen Tool-Dumps vermeiden
4. Bedienern die Möglichkeit geben, den Speicher zu inspizieren und zu bearbeiten
5. Speicher, der veraltet oder von Angreifern kontrolliert sein könnte, ablaufen lassen oder neu validieren

Deshalb ist auch die Schwärzung wichtig. Wenn Protokolle, Prompts, Diffs oder Befehlsergebnisse ohne Filterung in den Speicher kopiert werden, vergrößert sich der Radius des Lecks. Ein Quellcode-Leak ist schlimm. Ein Quellcode-Leak plus dauerhafte Speicherung von Geheimnissen ist viel schlimmer.

Berechtigungen, Auto-Modus und warum das Prinzip der geringsten Rechte die Prompt-Geheimhaltung übertrifft

Der Quellcode-Leak von Claude Code hat viele Leute zu einer vereinfachten Schlussfolgerung verleitet: Halte den Prompt geheim und das Produkt ist sicher. Das ist nicht genug.

Eine dauerhaftere Verteidigung ist das Prinzip der geringsten Rechte (Least Privilege). Das AI Agent Security Cheat Sheet von OWASP besagt, dass Agenten die für die Aufgabe erforderlichen Mindestwerkzeuge erhalten sollten, mit begrenzten Operationen und expliziter Genehmigung für sensible Aktionen. Die Dokumentation von Anthropic macht eine ähnliche Unterscheidung zwischen Verhaltensanleitung und technischer Durchsetzung: Einstellungen können Tools, Befehle, Pfade oder Sandbox-Grenzen blockieren, selbst wenn das Modell selbst eine schlechte Wahl getroffen hätte.

Das ist die richtige Denkweise über Berechtigungen in Claude Code.

Ein sicherer Agent sollte trennen:

1. was das Modell *lesen darf*
2. was das Modell *vorschlagen darf*
3. was die Laufzeitumgebung *ausführen darf*
4. was weiterhin eine *menschliche Genehmigung* erfordert

Diese Trennung ist im Auto-Modus noch wichtiger. In Anthropics Bericht vom März 2026 heißt es, dass die manuelle Genehmigung funktioniert, aber auch zu einer Genehmigungsmüdigkeit führt, da die Benutzer die meisten Prompts ohnehin genehmigen. Daher hat Anthropic eine automatisierte Entscheidungsebene hinzugefügt, anstatt die Benutzer standardmäßig auf eine völlig uneingeschränkte Ausführung umzustellen. Das ist der reife Schritt: Reibung reduzieren, aber einen Klassifikator und eine Sonde zwischen dem Modell und dem Explosionsradius beibehalten.

Mit anderen Worten, die beste Antwort auf ein Quellcode-Leak ist nicht Panik. Sondern bessere Grenzen.

Slash-Befehle, Multi-Agenten-Workflows und Erweiterungsschnittstellen

Claude Code ist nicht nur ein Shell-Wrapper für ein einzelnes Modell. Die umgebende Bedienererfahrung ist entscheidend.

Slash-Befehle bieten Benutzern kurze, wiederverwendbare Einstiegspunkte in Workflows. Sie reduzieren den Aufwand für das Schreiben von Prompts und machen gängige Operationen konsistenter. Das ist gut für die Produktivität, bedeutet aber auch, dass Befehle zu privilegierten Ausführungs-Shortcuts werden können. Behandeln Sie sie als code-nahe Schnittstellen, nicht als harmlose Makros.

Multi-Agenten-Workflows sind aus einem anderen Grund wichtig. Wenn Sie die Arbeit in Planer-, Rechercheur-, Prüfer- oder Korrektor-Rollen aufteilen, reduzieren Sie die kognitive Belastung und verbessern manchmal die Qualität. Aber Sie schaffen auch mehr Nachrichtenaustausch, mehr Zusammenfassungen und mehr Möglichkeiten für ein vergiftetes Zwischenergebnis, sich zwischen den Agenten zu bewegen. OWASP warnt aus genau diesem Grund ausdrücklich vor kaskadierenden Fehlern in Multi-Agenten-Systemen.

Dann gibt es die Fähigkeitssubsysteme.

1. MCP steht für Model Context Protocol, einen offenen Standard zur Verbindung von Modellen mit Werkzeugen und Datenquellen.
2. LSP bedeutet normalerweise Code-Intelligenz im Stil eines Sprachservers innerhalb von IDE-Flows.
3. Plugins und Skills bündeln wiederverwendbare Fähigkeiten und Workflows.

Diese sind nützlich, weil sie den Kernagenten kleiner halten und es den Betreibern ermöglichen, gezielte Fähigkeiten hinzuzufügen. Sie sind riskant, weil jede Erweiterung eine weitere Vertrauensgrenze darstellt. Ein Plugin kann seine Befugnisse überschreiten. Ein MCP-Server kann mehr preisgeben als beabsichtigt. Ein Skill kann den Werkzeugzugriff unbemerkt erweitern. Eine Sprachintegration kann sensible Code-Intelligenz an Orten sichtbar machen, an denen Sie es nicht erwartet haben.

Die sichere Designregel ist langweilig, aber effektiv: Jede Erweiterung sollte deklarieren, was sie lesen, was sie schreiben, welches Netzwerk sie erreichen kann und was protokolliert wird.

Wie man Prompt Injection und Tool Injection in der Praxis erkennt

Wenn Sie über das Quellcode-Leak von Claude Code lesen, weil Sie Coding-Agenten in der Produktion einsetzen, gibt es hier ein dringenderes Problem zu lösen: Wie erkennen Sie einen Angriff, bevor er zu einer Aktion wird?

Achten Sie auf Muster wie diese:

1. externe Inhalte, die den Agenten anweisen, frühere Anweisungen zu ignorieren
2. Protokolle, Problemtexte, Dokumente oder Kommentare, die nach Geheimnissen, System-Prompts oder versteckten Regeln fragen
3. Werkzeugausgaben, die den Aufgabenbereich plötzlich von der Anfrage des Benutzers auf das Ziel des Angreifers ändern
4. Anfragen zur Eskalation von Berechtigungen, zur Aktivierung des Netzwerkzugriffs oder zum Exportieren von Dateien ohne einen vom Benutzer angegebenen Grund
5. Versuche, von einer reinen Leseanalyse zu einem Schreib-, Lösch-, Sende- oder Ausführungsverhalten überzugehen
6. versteckte oder verschleierte Anweisungen, die in Markdown, HTML, kodierten Zeichenfolgen oder Screenshots eingebettet sind

Das Spickzettel zur Prompt Injection von OWASP ist hier besonders nützlich, da es Prompt Injection nicht als Neuheit behandelt. Es behandelt es wie ein technisches Problem: Anweisungen von Daten trennen, Eingaben bereinigen, Ausgaben filtern und menschliche Überprüfung für risikoreiche Operationen beibehalten.

Das ist die richtige Denkweise für Claude Code nach einem Quellcode-Leak. Gehen Sie davon aus, dass Angreifer mehr wissen als zuvor. Entwerfen Sie dann so, dass mehr Wissen ihnen trotzdem nicht viel ermöglicht.

Defensive Leitlinien für Teams, die Claude Code oder ähnliche Agenten verwenden

Wenn Ihre Organisation Claude Code, OpenClaw, Cursor, Copilot oder einen anderen agentenbasierten Coding-Workflow verwendet, bieten Ihnen diese Kontrollen den größten Hebel:

1. Prinzip der geringsten Rechte (Least Privilege): Geben Sie dem Agenten nur die Werkzeuge und Pfade, die er für die aktuelle Aufgabe benötigt.
2. Schwärzung: Entfernen Sie Geheimnisse, Token, interne URLs und Kundendaten aus Protokollen und dem Speicher vor der Persistenz.
3. Ausgabefilterung: Überprüfen Sie Antworten und Argumente von Werkzeugaufrufen auf das Durchsickern von Geheimnissen oder verdächtige Exfiltrationsmuster.
4. Sandboxing: Isolieren Sie die Ausführung, die Netzwerkreichweite und den Dateisystemumfang, wann immer möglich.
5. Umgang mit Geheimnissen: Injizieren Sie kurzlebige Anmeldeinformationen pro Aufgabe, anstatt die gesamte Host-Umgebung zu erben.
6. Audit-Protokollierung: Protokollieren Sie Werkzeugaufrufe, Genehmigungen, Richtlinientreffer und ausgehende Anfragen mit ausreichender Genauigkeit, um Vorfälle zu rekonstruieren.
7. Menschliche Kontrollpunkte: Fordern Sie eine Überprüfung für destruktive Aktionen, externe Kommunikation, Paketinstallationen und Schreibvorgänge mit weitem Geltungsbereich.
8. Überprüfung von Erweiterungen: Behandeln Sie MCP-Server, Plugins und Skills als Abhängigkeiten in der Lieferkette (Supply Chain).

Eine gute Checkliste für Vorfälle ist ebenso konkret:

1. autonome Ausführung anhalten
2. exponierte Anmeldeinformationen rotieren und veraltete Token widerrufen
3. jüngste Tool-Ausgaben und Aktionsprotokolle auf eingeschleuste Anweisungen überprüfen
4. persistente Speichereinträge, die möglicherweise vergiftet wurden, löschen oder inspizieren
5. Berechtigungen und Sandbox-Regeln einschränken, bevor die Automatisierung wieder aktiviert wird
6. Artefakte für die Ursachenanalyse und die Meldung an den Anbieter aufbewahren

Abschließendes Urteil

Die nützlichste Lektion aus dem Quellcode-Leak von Claude Code ist nicht der Nervenkitzel, Interna zu sehen. Es ist die Erinnerung daran, dass moderne Programmier-Agenten in Wirklichkeit Orchestrierungssysteme sind: geschichtete Prompts, abgerufener Kontext, Tool-Schemata, Berechtigungen, Speicher und Genehmigungsgrenzen, die unter Druck zusammenarbeiten.

Deshalb ist eine sichere Erklärung wertvoller als ein kopierter Prompt. Wenn Sie die Architektur auf hohem Niveau verstehen, können Sie jeden Programmier-Agenten intelligenter bewerten. Sie können fragen, ob seine Tool-Ausgaben gescannt werden, ob sein Speicher isoliert ist, ob seine Berechtigungen begrenzt sind, ob seine Erweiterungen überprüft werden und ob seine Protokolle die Reaktion auf Vorfälle unterstützen.

Und wenn Sie über den geschäftlichen Einsatz nachdenken, lässt sich dieselbe Lektion nahtlos übertragen: Die siegreichen KI-Systeme werden nicht diejenigen mit den mysteriösesten Prompts sein. Es werden diejenigen mit den klarsten Grenzen sein. Tools wie OpenClaw vs Claude Code und Anleitungen zur Verwendung von Claude Code auf dem Computer sind nützlich, weil sie Ihnen helfen, diese Grenzentscheidungen zu vergleichen, anstatt dem Drama um Leaks nachzujagen.

FAQ

Bedeutet der Quellcode-Leak von Claude Code, dass das Produkt unsicher ist?

Nicht per se. Ein Quellcode-Leak wirft zwar berechtigte Bedenken hinsichtlich der Offenlegung der Architektur und der Einblicke für Angreifer auf, aber Laufzeitschutzmaßnahmen sind nach wie vor wichtiger. Wenn Berechtigungen, Sandboxing, Ausgabefilterung und menschliche Genehmigung intakt bleiben, ist ein Leak zwar ernst, aber dennoch eindämmbar.

Was ist das größte Sicherheitsrisiko nach einem Quellcode-Leak von Claude Code?

Normalerweise nicht das Kopieren von Prompts. Das größere Risiko besteht darin, dass Angreifer neues Wissen nutzen, um bessere Versuche der Prompt-Injection, Tool-Injection, des Missbrauchs von Erweiterungen oder der Privilegienerweiterung zu entwickeln. Deshalb sollten Teams zuerst die Tool-Bereiche, Protokolle und Genehmigungspfade härten.

Wie sollten Teams reagieren, die heute Claude Code oder ähnliche Agenten verwenden?

Behandeln Sie das Ereignis als Auslöser für eine Design-Überprüfung. Überprüfen Sie erneut Geheimnisse, Speicheraufbewahrung, MCP- oder Plugin-Berechtigungen, Sandbox-Einstellungen und Audit-Protokolle. Wenn Sie genau erklären können, was Ihr Agent lesen, schreiben, aufrufen und persistieren darf, sind Sie in einer viel besseren Position.