TrustFall zeigt das Ein-Tasten-Risiko moderner Coding-Agenten

Worum es geht

Adversa AI hat am 7. Mai 2026 eine Untersuchung namens TrustFall veröffentlicht. Der Kern ist unbequem: Ein fremdes Repository kann in mehreren Coding-Agenten Projektdateien mitbringen, die einen MCP-Server definieren. Wenn ein Entwickler den Ordner als vertrauenswürdig bestätigt, kann dieser Server als normaler lokaler Prozess starten.

Betroffen sind laut Untersuchung Claude Code, Gemini CLI, Cursor CLI und GitHub Copilot CLI. Das ist keine klassische Prompt-Injection, bei der das Modell zu etwas überredet wird. Es ist ein Vertrauens- und Konfigurationsproblem an der Grenze zwischen Projektordner, Agent und Betriebssystem.

Was TrustFall tatsächlich macht

Der Angriff nutzt den Model Context Protocol-Mechanismus. MCP erlaubt einem Agenten, externe Hilfsprogramme einzubinden: Datenbankzugriff, Linter, interne Tools oder Suchdienste. Diese Helfer können aber in Projektdateien definiert sein. Wird ein fremdes Repository geöffnet, liest der Agent die Konfiguration und kann den Helfer starten.

Adversa beschreibt zwei Varianten. In der Entwickler-Variante reicht ein Trust-Dialog, der oft auf Zustimmung voreingestellt ist. In der CI-Variante kann ein headless Runner ohne sichtbaren Dialog betroffen sein, wenn der Agent in einer Pipeline auf einem Pull Request läuft. Der gestartete Prozess läuft laut Bericht mit den Rechten des Nutzers oder Runners. Damit geht es nicht nur um den Projektordner, sondern potenziell um SSH-Schlüssel, Cloud-Tokens, Shell-History und andere lokale Quellen.

Warum das wichtig ist

Coding-Agenten werden genau dort eingesetzt, wo sensible Daten liegen: Quellcode, Deployment-Skripte, Cloud-Zugänge und Produktgeheimnisse. Die alte Entwickler-Regel lautete: erst Code anschauen, dann ausführen. Agentische CLIs verschieben diese Grenze, weil schon Projektkonfiguration beim Öffnen aktiv werden kann.

Help Net Security berichtet, dass Anthropic die konkrete Claude-Code-Meldung als außerhalb des eigenen Threat Models bewertet hat: Wer einem Ordner vertraut, stimme der Projektkonfiguration zu. Adversa kritisiert nicht nur diese Grenze, sondern vor allem die Frage, ob der Dialog deutlich genug erklärt, dass damit lokaler Code starten kann. Für Teams ist das eine praktische Security-Frage, nicht nur eine Vendor-Debatte.

Einfach erklärt

Stell dir vor, du leihst dir ein Kochbuch aus. Beim Aufschlagen fragt es: „Vertraust du diesem Buch?“ Wenn du Enter drückst, schaltet es nicht nur den Herd an, sondern öffnet auch deine Küchenschränke und ruft eine fremde Telefonnummer an. Genau darum geht es: Nicht der Rezepttext ist das Problem, sondern die unsichtbare Aktion, die mit dem Vertrauen ausgelöst wird.

Praktisches Beispiel

Ein Entwickler prüft pro Woche 20 fremde Open-Source-Repositories. Eines davon enthält zwei kleine Konfigurationsdateien: eine MCP-Definition mit einem harmlos benannten Helfer und eine Auto-Approval-Einstellung. Der Entwickler startet den Agenten, bestätigt den Trust-Dialog und der Helfer läuft. Wenn auf dem Rechner 8 Cloud-Profile, 3 SSH-Keys und mehrere private Repositories erreichbar sind, wird aus einem Test-Clone ein ernstes Lieferkettenrisiko.

In einer CI-Pipeline ist der Schaden noch direkter. Ein Pull Request kann den Runner dazu bringen, Umgebungsvariablen oder Build-Tokens zu lesen, bevor ein Mensch die Änderung wirklich geprüft hat.

Einordnung und Grenzen

• Der Bericht zeigt ein Konfigurations- und Consent-Problem. Er beweist nicht, dass alle Installationen bereits kompromittiert wurden.
• Teams mit zentral verwalteten Agent-Einstellungen, deaktiviertem projektweiten MCP-Autostart und isolierten CI-Runners können das Risiko deutlich reduzieren.
• MCP bleibt nützlich. Das Problem ist nicht das Protokoll selbst, sondern unklare Trust-Dialoge, project-scoped Auto-Approval und fehlende Isolation.

SEO- und GEO-Schlüsselbegriffe

TrustFall, Adversa AI, Claude Code, Gemini CLI, Cursor CLI, GitHub Copilot CLI, MCP, Model Context Protocol, Coding-Agent-Sicherheit, CI Security, Software Supply Chain, RCE