# Wie ein fremdes Repository Claude Code kapern kann: 7 Schutzregeln
> Vier dokumentierte indirekte Prompt-Injection-Wege über Repositorys, GitHub-Inhalte, Sentry-Ereignisse und MCP-Metadaten mit Primärquellen und Grenzen praktischer Schutzmaßnahmen.
Source: https://ailoot.ai/blog/de/malicious-repository-claude-code/
Canonical: https://ailoot.ai/blog/de/malicious-repository-claude-code/
Language: de
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-148
Revision: sha256-4d1587a0b890468c1ec964db84080406b48e399e46535a62bb6af8ca0a2dbd7f
Das Wichtigste
Veröffentlichte Forschung zeigt vier indirekte Injection-Wege: Installationsanweisungen, GitHub-Inhalte, Telemetrie und MCP-Toolmetadaten. Die Berichte erschienen zu verschiedenen Zeiten und betreffen unterschiedliche Clients und Berechtigungen. Es folgen Primärquellen und praktische Begrenzungsmaßnahmen. Keine Einstellungsdatei garantiert Immunität.
[Ailoot-Dokumentation: API, Schlüssel und Einrichtung](https://ailoot.ai/docs/).
## Vier dokumentierte Wege von fremdem Text zu Agentenaktionen
Das Wichtigste
Diese Beispiele gehören zu unterschiedlichen Forschungszeiträumen und Clientkonfigurationen, nicht zu vier Entdeckungen binnen vierzehn Tagen. Sie zeigen die Beeinflussung von Toolnutzung durch fremde Inhalte. Implementierungsfehler, verfügbare Zugangsdaten und Ausführungsrechte bestimmen den Ausgang.
Formal wird das indirekte Prompt-Injection genannt: Eine bösartige Anweisung kommt nicht direkt von dir, sondern über Daten, die der Agent während einer Aufgabe verarbeitet – ein fremdes README, eine Fehlermeldung, ein GitHub-Kommentar oder eine Antwort eines externen Dienstes. Den Begriff kannst du direkt nach diesem Absatz wieder vergessen; von hier an verwende ich einfache Worte.
Vier unten behandelte Forschungsbeispiele:
1. Ein harmlos wirkendes Repository wurde nachweislich in eine Reverse-Shell verwandelt.
2. Ein Pull-Request-Titel wurde nachweislich dazu verwendet, drei verschiedene KI-Agenten zu kapern.
3. Ein Agent wurde nachweislich dazu gebracht, einen gefälschten Sentry-Fehlerbericht statt eines echten zu akzeptieren.
4. Eine MCP-Toolbeschreibung wurde nachweislich dazu verwendet, das Verhalten deines Agenten durch Toolmetadaten zu beeinflussen; das ist keine automatische Gleichsetzung mit System-Prompt-Autorität.
## Wie wird das README eines harmlosen Repositorys zur Reverse-Shell?
Das Wichtigste
[0DINs Machbarkeitsnachweis vom 25. Juni 2026](https://0din.ai/blog/clone-this-repo-and-i-own-your-machine) zeigt: Du klonst ein gewöhnlich wirkendes Repository und bittest Claude Code, es auszuführen – und der Agent folgt brav den Installationsanweisungen. Ein Fehler beim ersten Start schlägt einen „Fix“-Befehl vor, der in Wirklichkeit den DNS-Eintrag des Angreifers auflöst und eine Reverse-Shell startet. Die zitierte Quelle demonstriert die Technik, belegt aber nicht ihre Häufigkeit in realen Vorfällen.
Der Ablauf ist so gestaltet, dass keine einzelne Ebene verdächtig wirkt:
1. Du klonst ein gewöhnlich wirkendes Repository und bittest Claude Code, es auszuführen.
2. Das Repository bindet ein Python-Paket ein, das beim ersten Einsatz absichtlich fehlschlägt.
3. Die Fehlermeldung schlägt höflich einen „Fix“-Befehl vor: `python3 -m axiom init`.
4. Der Befehl `init` führt `setup.sh` aus.
5. Das Skript fragt einen DNS-TXT-Eintrag ab (der gewöhnlich für Hinweise zu einer Domain verwendet wird, aber beliebigen Text aufnehmen kann). Der Angreifer hinterlegt dort einen Base64-codierten Befehl (eine Möglichkeit, beliebige Daten ohne Leerzeichen oder Sonderzeichen in Klartext umzuwandeln) und leitet ihn direkt an bash weiter.
6. Der Wert des DNS-Eintrags kann jederzeit geändert werden – so erhält der Angreifer eine interaktive Reverse-Shell mit deinen Benutzerrechten und Zugriff auf alle Geheimnisse auf dem Rechner.
Die demonstrierte Payload wurde erst zur Laufzeit aus DNS abgerufen. Eine Prüfung allein der Repositorybytes zeigte diesen endgültigen Inhalt deshalb nicht. Das beweist keine Machtlosigkeit sämtlicher Scanner oder Laufzeitkontrollen. Analyse abgerufener Inhalte, Prozessüberwachung und Netzwerkgrenzen können die Kette erkennen oder unterbrechen. Die Quelle ist ein Machbarkeitsnachweis, keine Messung realer Vorfallhäufigkeit. Solche Repositorys können jedoch auf beliebige Weise verbreitet werden – über gefälschte Stellenanzeigen, Rezensionen, Blogbeiträge oder Direktnachrichten.
## Wie konnte ein Pull-Request-Titel drei verschiedene KI-Agenten kapern?
Das Wichtigste
Der am 15. April 2026 veröffentlichte und am 4. Mai aktualisierte [Forschungsbericht „Comment and Control“](https://oddguan.com/blog/comment-and-control-prompt-injection-credential-theft-claude-code-gemini-cli-github-copilot/) dokumentiert verschiedene GitHub-Text-Injection-Wege in Claude Code Security Review, Gemini CLI Action und Copilot Agent. Eine niedrigere Schwerebewertung beweist keine vollständige Behebung der Angriffsklasse. Der Bericht beschreibt Anbieterreaktionen und eine konkrete Claude-Toolbeschränkung.
Der Bericht beschreibt diese Wege und Reaktionen als historische Untersuchung. Er verifiziert nicht jede aktuelle Produktversion:
| Agent | Wie der Angriff eindrang | Was durchsickerte | Status heute |
|----|----|----|----|
| Claude Code Security Review | PR-Titel ohne Bereinigung direkt in den System-Prompt eingefügt | `ANTHROPIC_API_KEY`, `GITHUB_TOKEN` | Bericht nennt ps-Beschränkung und Dokumentationsänderungen; Schwere am 20. April 2026 auf None geändert |
| Gemini CLI Action | Gefälschter Abschnitt „Trusted Content“ in einem Kommentar umging die Sicherheitsanweisungen | `GEMINI_API_KEY` | Google fügte dem System-Prompt separate Schutz-Prompts hinzu |
| GitHub Copilot Agent | Payload in einem unsichtbaren HTML-Kommentar in Markdown versteckt | `GITHUB_COPILOT_API_TOKEN`, `COPILOT_JOB_NONCE` | GitHub betrachtet dies als architektonische Einschränkung, nicht als Fehler |
Zwischen dem ersten und dem letzten Bericht dieses Offenlegungszyklus vergingen fast fünf Monate (der erste Claude-Code-Bericht stammte vom 17. Oktober 2025; der letzte GitHub-Copilot-Bugfix vom 9. März 2026). Schwereänderung und Gegenmaßnahmen belegen keine vollständige Schließung sämtlicher möglicher Payloads. Das [PoC-Repository](https://github.com/0dd/Claude-review-poc) dokumentiert den gezeigten Claude-Weg. Führe die Angriffspayload nicht gegen echte Systeme aus. Der Nutzen für dich liegt im Angriffsmuster selbst: Nicht verifizierte Daten von GitHub gelangen zum Agenten, der Agent führt Befehle aus, und Geheimnisse sickern über dasselbe GitHub durch – der Angreifer braucht keinen externen Server.
Zwei Analysen genügen, um das Muster zu erkennen: Jeden neuen Befund einzeln zu beheben, ist nicht praktikabel; solche Schwachstellen tauchen alle zwei Wochen auf. Sicherheitsregeln ausdrücklich in CLAUDE.md und settings.json festzuhalten, statt sie im Kopf zu behalten, ist Teil des Context Engineerings: Du legst sie einmal fest, und sie gelten automatisch in jeder neuen Claude-Code-Sitzung, ohne Erinnerungen. Drei Säulen wirken zusammen: **KI-Klon + Second Brain + Context Engineering** – diese Kombination macht aus Claude Code einen Agenten mit ausdrücklichen Regeln statt eines Ausführers, der allem vertraut.
## Kann ein gefälschter Sentry-Fehlerbericht deinen Agenten übernehmen?
Das Wichtigste
Ein Angreifer sendet ein gefälschtes Fehlerereignis an Sentry; der Agent fragt über MCP eine Liste von Problemen ab, erhält das schädliche Ereignis zwischen legitimen Einträgen und führt den darin eingebetteten Befehl als „Korrekturschritt“ aus. Tenets am 17. Juni 2026 aktualisierter [Agentjacking-Bericht](https://tenetsecurity.ai/blog/agentjacking-coding-agents-with-fake-sentry-errors/) nennt 85 % erfolgreiche Ausnutzung über kontrollierte Validierungswellen mit mehr als 100 Agentenausführungen einschließlich Claude Code, Cursor und Codex. Er nennt eine Claude-Code-2-1-161-Aufnahme vom 2. Juni, veröffentlicht aber weder vollständige Modellliste noch reproduzierbares Harness, exakten Versuchsnenner oder Aufteilung je Client. Die 85 % sind eine Gesamtbeobachtung der Forscher, keine Angriffswahrscheinlichkeit jeder heutigen Installation.
Für den Angriff braucht man lediglich einen Sentry-DSN-Schlüssel – eine öffentliche Kennung, die viele Projekte direkt in clientseitigen Code aufnehmen:
Der Ablauf ist einfach: Ein Entwickler bittet den Agenten, offene Sentry-Fehler zu untersuchen; der Agent fragt sie über den MCP-Server ab, erhält ein schädliches Ereignis zwischen echten Einträgen und liest den darin eingebetteten Befehl als vertrauenswürdige Anweisung zur Behebung des Fehlers – denn formal ist genau das die Aufgabe, um die er gebeten wurde.
Tenet berichtet von ausbleibenden Warnungen vorhandener Kontrollen in den getesteten Umgebungen. Das belegt keine spurenfreie Ausführung aller Bereitstellungen: Agenten-/Toollogs, Endpunkttelemetrie und Netzwerkaufzeichnungen können Folgeaktionen erfassen. Der Angriff beginnt mit extern eingereichter Telemetrie und hängt danach von tatsächlich verfügbaren Tools und Rechten ab.
## Warum können MCP-Toolbeschreibungen das Modellverhalten beeinflussen?
Toolmetadaten können Modellverhalten beeinflussen, sind aber nicht automatisch gleichrangig mit einem System-Prompt. [MCPTox](https://arxiv.org/abs/2508.14925), erstmals am 19. August 2025 eingereicht, prüft Tool Poisoning an realistischen MCP-Tools und berichtet von modell- und konfigurationsabhängiger Anfälligkeit. Höhere Anfälligkeit leistungsfähigerer Modelle ist dort ein Benchmarkbefund, kein allgemeines Gesetz.
Microsofts Formulierung ist die treffendste, die ich zu diesem Thema gefunden habe:
Diese Technik heißt Tool Poisoning: Eine Anweisung, die in der Beschreibung eines harmlosen Tools versteckt ist, bringt den Agenten dazu, entsprechend zu handeln.
Die Ergebnisse gelten für die in MCPTox getesteten Modelle und Einstellungen. Anfälligkeit und Ablehnungsverhalten lassen sich nicht allein aus allgemeiner Leistungsfähigkeit ableiten. Prüfe den genauen Benchmarkaufbau statt eines universellen Zusammenhangs zwischen gutem Anweisungsfolgen und Unsicherheit.
## Was haben diese Angriffe gemeinsam, und was kann Erkennung übersehen?
Das Wichtigste
Die Beispiele zeigen das Risiko, fremde Daten als Anweisung zur Toolnutzung zu behandeln. Eine reine Repositoryprüfung kann später über Tools oder Netzwerk gelieferte Payloads übersehen. Erkennung bleibt nützlich, muss aber den gesamten Ausführungsweg betrachten. Kombiniere sie mit Grenzen für Dateien, Zugangsdaten, Tools und Netzwerk, statt auf das Erkennen der Anweisung durch das Modell zu vertrauen.
Die Schlussfolgerung gilt für alle vier Befunde: Man kann sich nicht darauf verlassen, dass „der Code normal aussieht“ – jeder einzelne Schritt eines Angriffs ist tatsächlich harmlos. Begrenze tatsächliche Fähigkeiten des Agenten und prüfe vorgeschlagene Aktionen. Erkennung und Eingrenzung behandeln unterschiedliche Teile des Angriffs.
## Welche Schutzmaßnahmen hat Claude Code bereits – und warum reichen sie nicht?
Das Wichtigste
Claude Code verfügt über eingebaute Schutzmaßnahmen: Es analysiert den gesamten Prompt auf verdächtige Anweisungen, verwendet für Webinhalte isolierte Kontextfenster, prüft beim ersten Start in einem neuen Ordner das Vertrauen und tut dies auch beim Verbinden mit MCP-Servern. Doch die Option `--dangerously-skip-permissions`, mit der viele lästige Berechtigungsfragen abschalten, deaktiviert all diese Schutzmaßnahmen auf einmal.
Anthropic räumt das Problem in [seiner Dokumentation](https://code.claude.com/docs/en/security) offen ein, statt es zu verschweigen:
Prompt Injection ist eine Technik, bei der ein Angreifer versucht, die Anweisungen eines KI-Assistenten zu überschreiben oder zu verändern, indem er bösartigen Text einfügt. Claude Code verfügt über mehrere Schutzmaßnahmen gegen diese Angriffe.
— Claude-Code-Dokumentation, https://code.claude.com/docs/en/security
Laut Dokumentation analysiert der Agent den gesamten Prompt auf verdächtige Anweisungen, genehmigt `curl` und `wget` nicht automatisch, hält Webinhalte in einem separaten Kontextfenster, damit sie nicht mit dem Hauptfenster vermischt werden, und verlangt eine Vertrauensbestätigung, wenn du erstmals in einer neuen Codebasis startest oder einen neuen MCP-Server verbindest.
Doch es gibt einen klaren Vorbehalt, den Anthropic unverblümt nennt:
Der Modus bypassPermissions bietet keinen Schutz vor Prompt Injection oder unbeabsichtigten Aktionen.
— Claude-Code-Dokumentation, https://code.claude.com/docs/en/permission-modes
Wenn du Claude Code schon einmal aus Verärgerung mit `--dangerously-skip-permissions` gestartet hast, damit es „nicht dauernd Fragen stellt“, hast du damit genau die Mechanismen abgeschaltet, die die vier oben beschriebenen Angriffe hätten aufhalten können. Ich lasse diese Option bewusst deaktiviert, selbst wenn Claude Code in einer Sitzung zum zehnten Mal fragt – das nervt, aber diese Fragen bilden die Grenze zwischen „der Agent hat verdächtigen Text gelesen“ und „der Agent hat ihn ausgeführt“. Eine sinnvolle Einrichtung für Nichtprogrammierer ist der Standard-Berechtigungsmodus (`default` oder `acceptEdits`) mit aktiviertem Sandbox-Modus: Gewöhnliche Dateiänderungen erfolgen ohne zusätzliche Fragen, während Terminalbefehle die Sandbox physisch nicht verlassen können, selbst wenn der Agent getäuscht wurde.
## Wie aktiviert man den Sandbox-Modus und schließt die standardmäßig offene Lücke?
Das Wichtigste
Der Befehl `/sandbox` in einer Claude-Code-Sitzung beschränkt, wo der Agent schreiben und welche Domains er kontaktieren kann. Unter macOS funktioniert er sofort; unter Linux und WSL2 werden die Pakete `bubblewrap` und `socat` benötigt. Ein wichtiges Detail: Standardmäßig blockiert die Sandbox nicht das Lesen von Dateien wie `~/.ssh` – das musst du gesondert aktivieren.
Um die Funktion für alle Projekte dauerhaft zu aktivieren, nimm eine Änderung an `~/.claude/settings.json` vor:
```json
{
"sandbox": { "enabled": true }
}
```
Standardmäßig dürfen Sandbox-Befehle nur in das Projekt-Arbeitsverzeichnis und das temporäre Verzeichnis der Sitzung schreiben. Der Netzwerkzugriff läuft über einen Proxy – im Voraus ist keine Domain zugelassen, und Claude Code fragt beim ersten Kontakt mit einer neuen Domain nach deiner Bestätigung. [Anthropic sagt](https://www.anthropic.com/engineering/claude-code-sandboxing), dass dies die Berechtigungsabfragen deutlich reduziert – in internen Messungen des Unternehmens um 84 % –, weil die Sandbox einige sichere Fälle selbst handhabt, statt jedes Mal nachzufragen.
Die Lücke in den Standardeinstellungen: Die Sandbox beschränkt standardmäßig das *Schreiben*, verhindert aber nicht das *Lesen* von Dateien wie `~/.aws/credentials` und `~/.ssh`. Genau auf diese Angriffe zielen die oben beschriebenen Analysen. Schließe die Lücke mit einem separaten Block in derselben Datei:
```json
{
"sandbox": {
"enabled": true,
"credentials": {
"files": [
{ "path": "~/.aws/credentials", "mode": "deny" },
{ "path": "~/.ssh", "mode": "deny" }
],
"envVars": [
{ "name": "GITHUB_TOKEN", "mode": "deny" },
{ "name": "NPM_TOKEN", "mode": "deny" }
]
}
}
}
```
Entscheidend ist: Selbst wenn die Reverse-Shell aus der ersten Analyse innerhalb der Sandbox geöffnet wird, werden diese Variablen und Dateien vor dem Start physisch aus der Prozessumgebung entfernt – es bleibt nichts zum Stehlen übrig.
## Welche permissions.deny-Regeln solltest du heute hinzufügen?
Das Wichtigste
`permissions.deny` in settings.json blockiert bestimmte Aktionen auf Regelebene, statt Absichten zu analysieren – und Anthropic garantiert ausdrücklich, dass eine deny-Regel immer Vorrang vor einer allow-Regel hat. Deny-Regeln beschränken passende Toolaktionen, sind aber keine Betriebssystem-Zugriffsgrenze. Indirekte Befehle und andere Tools benötigen eigene Kontrollen.
Ein minimales Set für Nichtprogrammierer, das die wichtigsten Ziele aller vier Angriffe zugleich abdeckt:
```json
{
"permissions": {
"deny": [
"Read(~/.ssh/**)",
"Read(~/.aws/credentials)",
"Read(.env)",
"Bash(curl *)",
"Bash(wget *)",
"Bash(sudo *)"
]
}
}
```
Laut der [Claude-Code-Dokumentation](https://code.claude.com/docs/en/permissions) haben deny-Regeln stets Vorrang vor allow-Regeln. Selbst wenn du (oder der Agent selbst) an anderer Stelle versehentlich einen umfassenderen Zugriff erlaubst, greift eine konkrete deny-Regel zuerst. Dieser Regelvorrang gilt für passende Toolanfragen. Er beweist nicht, dass ein Geheimnis für jeden Unterprozess und jedes Tool unerreichbar ist. Nutze zusätzlich durchgesetzte Dateisystem- und Umgebungsgrenzen.
Claude Code bietet außerdem einen `auto`-Modus, in dem ein separates Klassifizierungsmodell Aktionen vor ihrer Ausführung prüft – es ist nicht dasselbe Modell, das mit dir kommuniziert. Standardmäßig blockiert es unter anderem genau das Muster „Code herunterladen und sofort ausführen“ (`curl | bash`). Anthropic warnt ausdrücklich, dass es sich um einen Forschungsmodus handelt, der die Zahl der Abfragen verringert, aber für sich allein keine Sicherheit garantiert – betrachte ihn als zusätzliche Ebene, nicht als Ersatz für die Sandbox und permissions.deny.
## Wie prüfst du ein Repository und einen MCP-Server, bevor du sie deinem Agenten anvertraust?
Das Wichtigste
Bevor du Claude Code bittest, ein fremdes Repository auszuführen, prüfe dessen Alter, Commit-Verlauf und die Herkunft des Links. Installiere einen MCP-Server nur aus vertrauenswürdigen Quellen und bedenke, dass Anthropic selbst keine Sicherheitsprüfung von Servern Dritter durchführt. Beide Checklisten dauern nur ein paar Minuten und decken genau die Einstiegspunkte ab, die in allen vier besprochenen Angriffen verwendet wurden.
Für Repositorys gilt diese kurze Checkliste, bevor du sie dem Agenten übergibst:
1. Beginne nicht sofort mit der Installation über einen Link aus einer E-Mail, einem Beitrag oder einer Rezension unbekannter Herkunft.
2. Wenn bei der Installation ein Fehler mit der Anweisung erscheint, „Befehl X zur Behebung auszuführen“, lies zuerst nach, was X tatsächlich tut, bevor du Claude Code die Ausführung erlaubst. Die Anweisung in der obigen Analyse sah völlig routinemäßig aus – genau das war der Zweck.
3. Prüfe das Alter des Repositorys und den Commit-Verlauf, nicht nur die Zahl seiner Sterne – neu erstellte Repositorys können eigens für diese Art von Angriff leicht mit gefälschten Sternen versehen werden.
4. Führe die Installation bei einem unbekannten Repository in einer virtuellen Maschine aus, nicht auf deinem Arbeitsrechner mit echten Schlüsseln. Dies ist [Anthropics eigene direkte Empfehlung](https://code.claude.com/docs/en/security) für die Arbeit mit externen Diensten.
Anthropics [Position zu MCP-Servern ist offen formuliert](https://code.claude.com/docs/en/security):
Wir empfehlen, eigene MCP-Server zu schreiben oder Server von Anbietern zu verwenden, denen du vertraust. Anthropic prüft Connectoren anhand seiner Aufnahmekriterien, bevor es sie in das Verzeichnis aufnimmt, führt aber keine Sicherheitsprüfungen durch und betreibt selbst keinen MCP-Server.
— Claude-Code-Dokumentation, https://code.claude.com/docs/en/security
Das bedeutet, dass du für die Prüfung von MCP-Servern Dritter verantwortlich bist, nicht die Plattform, auf der du sie installiert hast. Einige Teams – vor allem Sicherheits-Start-ups – entwickeln bereits Werkzeuge dafür: Scanner für MCP-Konfigurationen, die nach vergifteten Beschreibungen suchen, und Tool-Pinning, das bei der ersten Installation den Hash der Beschreibung speichert und spätere Änderungen meldet. Diese Technologien sind noch jung; es ist zu früh, sich als einzigem Schutz auf sie zu verlassen. Sie sind aber besonders dann im Auge zu behalten, wenn du MCP-Server mit der Produktion verbindest. Bei solchen Verbindungen kannst du jede Paketversion fixieren und den Fingerabdruck der Toolbeschreibungen in einem Audit-Log festhalten.
## 7 Schutzregeln: die heutige Checkliste
Das Wichtigste
Alles in diesem Leitfaden lässt sich auf sieben konkrete Maßnahmen bringen: drei Änderungen in einer settings.json-Datei (Sandbox, Zugangsdaten, permissions.deny) und vier Gewohnheiten im Umgang mit fremdem Code, Fehlern und MCP-Servern. Dafür sind keine besonderen Kenntnisse erforderlich – die gesamte Checkliste dauert weniger als 20 Minuten.
1. Aktiviere den Sandbox-Modus (`/sandbox` oder `"sandbox": {"enabled": true}` in `~/.claude/settings.json`) und füge einen `credentials`-Block hinzu, der das Lesen von `~/.ssh` und `~/.aws/credentials` verhindert.
2. Füge `permissions.deny`-Regeln für das Lesen geheimer Dateien und gefährliche Bash-Befehle (`curl`, `wget`, `sudo`) hinzu – eine deny-Regel hat immer Vorrang vor einer allow-Regel.
3. Verwende `--dangerously-skip-permissions` niemals mit fremdem oder nicht verifiziertem Code – die Option deaktiviert alle Schutzmaßnahmen auf einmal, einschließlich genau jener, die diese Angriffe hätten aufhalten können.
4. Lass Claude Code niemals automatisch einen „Fix“-Befehl aus einer Fehlermeldung ausführen – lies zuerst nach, was er tatsächlich tut.
5. Installiere MCP-Server nur aus Quellen, denen du vertraust, und bedenke, dass Anthropic sie nicht stellvertretend für dich auf Sicherheit prüft.
6. Trenne Sitzungen nach Berechtigungen: Eine arbeitet mit deinen persönlichen Daten und sieht keine externen Daten; eine zweite untersucht E-Mails, Repositorys und Tickets anderer, hat aber keinen Zugriff auf Geheimnisse; eine dritte veröffentlicht extern – und nur das, was du persönlich freigegeben hast. In meinen eigenen Projekten halte ich diese Trennung strikt ein: Eine Sitzung mit Zugriff auf Zahlungsschlüssel liest niemals beliebige externe Tickets oder Repositorys, und eine Sitzung, die den Code anderer analysiert, sieht überhaupt keine Geheimnisse. Vermische diese Rollen nicht in einem Chat.
7. Halte Claude Code und verbundene Automatisierungsskripte aktuell – die meisten hier besprochenen Lücken waren zum Zeitpunkt der Veröffentlichung dieses Leitfadens bereits durch Patches geschlossen, und neue werden auf ähnliche Weise behoben.
## Was jetzt zu tun ist
Keine dieser Ebenen ist eine Garantie – sogar Anthropic räumt ehrlich ein, dass kein Schutz vollständige Immunität bietet. Ich erwarte nicht, dass Claude Code einen Trick in einer Fehlermeldung oder einem Issue-Kommentar selbst erkennt. Für mich gehören die Sandbox und `permissions.deny` dazu, wie ich den Projektkontext verwalte: was der Agent sieht, was er standardmäßig für vertrauenswürdig hält und was passiert, wenn er einen Fehler macht.
### Quellen
- [0DIN: Clone This Repo and I Own Your Machine, 25. Juni 2026](https://0din.ai/blog/clone-this-repo-and-i-own-your-machine)
- [Comment and Control – Forschungsbericht vom 15. April 2026, aktualisiert am 4. Mai](https://oddguan.com/blog/comment-and-control-prompt-injection-credential-theft-claude-code-gemini-cli-github-copilot/)
- [Tenet Threat Labs: Agentjacking, aktualisiert am 17. Juni 2026](https://tenetsecurity.ai/blog/agentjacking-coding-agents-with-fake-sentry-errors/)
- [MCPTox: primärer Tool-Poisoning-Benchmark](https://arxiv.org/abs/2508.14925)
- [Claude-Code-Dokumentation – Berechtigungsmodi](https://code.claude.com/docs/en/permission-modes)
- [Anthropic Engineering – Claude-Code-Sandboxing](https://www.anthropic.com/engineering/claude-code-sandboxing)
- [Claude-Code-Dokumentation – Berechtigungen](https://code.claude.com/docs/en/permissions)
- [Claude-Code-Dokumentation – Best Practices für Sicherheit](https://code.claude.com/docs/en/security)
- [Claude-Code-Dokumentation – Model Context Protocol (MCP)](https://code.claude.com/docs/en/mcp)
- [Analyse einer verwandten Schwachstelle in der Claude Code GitHub Action](https://ailoot.ai/blog/de/claude-code-github-action-security/)
- [Wie du Claude Code so konfigurierst, dass es dein Projekt nicht über Nacht zerstört](https://ailoot.ai/blog/de/claude-code-safe-overnight-setup/)
- [Claude-Code-MCP-Server: 7 sofort einsatzbereite Konfigurationen und Installation Schritt für Schritt](https://ailoot.ai/blog/de/mcp-servers-claude-code/)
- [Vibe-Coding-Sicherheit: So verhinderst du, dass deine KI-generierte Anwendung gehackt wird](https://ailoot.ai/blog/de/vibe-coding-security/)
Wenn du über Ailoot auf neuronale Netze zugreifen möchtest, sieh dir [Ailoot](https://ailoot.ai/) an.
## Fragen und Antworten
### Sagen die berichteten 85 % die Gefahr meiner heutigen Einrichtung voraus?
Nein. Das ist Tenets Gesamtwert kontrollierter Validierungswellen ohne vollständige öffentliche Modellliste, reproduzierbares Harness oder exakten Versuchsnenner. Tools, Freigaben, Zugangsdaten und Netzwerk deiner Agentenumgebung bestimmen mögliche Aktionen.
### Warum reicht die Prüfung allein des geklonten Repositorys nicht?
Die endgültige Payload kann später über Fehlerbericht, Toolmetadaten oder DNS-Inhalte eintreffen. Prüfe den ganzen Ausführungsweg und begrenze Zugangsdaten, Dateien, Tools und Netzwerk. Scanner und deny-Regeln allein belegen keine vollständige Eingrenzung.
## Ailoot · Das Unternehmen und sein Projektportfolio
Ailoot baut auf bewährte Betriebserfahrung, einen großen Kundenstamm, stabilen Service und kontinuierliche KPI-Kontrolle.
Das Unternehmen und sein Projektportfolio: Millionen von Kunden; monatliche Umsätze in Milliardenhöhe.
Ailoot nutzt diese Betriebserfahrung für den API-Zugang zu KI-Funktionen in Kundenprodukten, Agenten, Anwendungen und Automatisierungen.