Ein KI-Coding-Agent soll in einem neuen Projekt vor allem erst einmal verstehen, wo er gelandet ist. Viele Werkzeuge fragen dafür im Hintergrund Git nach Branch, Änderungen und Dateien. Neue Sicherheitsrecherchen zeigen, warum gerade diese harmlose Vorarbeit gefährlich werden kann: In mehreren Agenten konnte ein mitgebrachter Git-Kontext dazu führen, dass Code auf dem Rechner lief, bevor eine Vertrauensabfrage sichtbar wurde. Das Problem ist nicht der erste Prompt. Es steckt in der stillen Infrastruktur davor.
Das Wichtigste in Kürze
- Mehrere KI-Coding-Agenten rufen beim Öffnen oder Einrichten eines Projekts Git-Kommandos zur Kontextsuche auf.
- Wenn ein Projektordner mitsamt seinem Git-Metadatenordner aus einer fremden Quelle kommt, können bestimmte Git-Einstellungen Programme starten.
- Manifold Security berichtet über betroffene Produkte, darunter historische Fälle bei Claude Code sowie bereits behobene Varianten bei Codex und Cursor.
- Der praktische Schutz ist banal, aber wichtig: Fremde Projektordner erst isoliert prüfen und KI-Agenten nur mit minimalen Rechten starten.
Warum der Start eines Agents mehr tut, als man sieht
Ein Coding-Agent arbeitet nicht wie eine reine Textsuche. Damit er Änderungen bewerten oder Aufgaben planen kann, sammelt er Kontext: Welcher Branch ist aktiv? Welche Dateien wurden verändert? Gibt es lokale Anpassungen? Dafür sind Befehle wie git status oder git diff naheliegend. Der neue Bericht von Manifold Security beschreibt, dass mehrere Kommandozeilen-Agenten solche Aufrufe teils schon beim Start ausführen. Das ist bequem, weil der Agent sofort orientiert ist. Es bedeutet aber auch, dass die Umgebung schon vor dem ersten sichtbaren Arbeitsschritt eine Rolle spielt.
Git ist dabei nicht nur ein Programm zum Vergleichen von Textdateien. Es liest Konfigurationen und kann für bestimmte Funktionen Hilfsprogramme einbinden. Eine dieser vorgesehenen Funktionen ist core.fsmonitor. Sie soll in großen Projekten schneller feststellen, welche Dateien geändert wurden. Wenn eine Git-Konfiguration auf ein externes Programm verweist, kann ein Git-Aufruf beim Aktualisieren seines Index dieses Programm starten. Das ist keine exotische Schwachstelle in Git selbst, sondern eine Eigenschaft, die in einer untrusted Umgebung zum falschen Zeitpunkt gefährlich wird.
Laut der Untersuchung entsteht der kritische Fall nicht durch das normale Klonen einer URL. Entscheidend ist ein Projektordner, der seine .git-Metadaten bereits mitbringt, etwa aus einem ZIP-Archiv, einem synchronisierten Ordner, einem USB-Stick oder einer geteilten Ablage. Wer so ein Verzeichnis in einem Agenten öffnet, vertraut nicht nur dem sichtbaren Quellcode. Er übernimmt auch den Zustand, den Git zu diesem Projekt gespeichert hat. Genau diese Unterscheidung ist im Alltag leicht zu übersehen.
Kein einzelner Herstellerfehler
Manifold nennt für die untersuchte Fehlerklasse Claude Code, Goose, Qwen Code, Grok Build und Hermes. Nach einem Update vom 1. September waren auch Codex und Cursor betroffen, die jeweiligen Varianten seien aber inzwischen behoben. Für Claude Code nennt der Bericht eine Korrektur des konkret beschriebenen Startpfads ab Version 2.1.196. Gleichzeitig beschreibt er weitere, teils noch offene Fälle bei anderen Werkzeugen. Die wichtige Aussage ist deshalb nicht, dass ein bestimmter Assistent grundsätzlich unsicher wäre. Sie lautet: Viele Agenten bauen beim Kontextlesen auf dieselben normalen Entwicklerwerkzeuge und können dabei dieselbe Vertrauensgrenze übersehen.
Das Muster taucht auch außerhalb von Git auf. GitLab veröffentlichte im August eine kritische Schwachstelle im MCP-Server Serena. Dort konnte eine bösartige Projektdatei beim Öffnen eines Repositories zu Codeausführung führen, obwohl Serena eine Vertrauensprüfung vorsah. Die Cloud Security Alliance hatte zuvor auf ähnliche Risiken hingewiesen, wenn Coding-Assistenten projektgebundene MCP-Konfigurationen vor der Prüfung laden. In allen Fällen geht es um dieselbe Frage: Behandelt das Werkzeug Dateien aus einem fremden Projekt als Daten, oder führt es sie als Konfiguration aus?
Das ist besonders relevant, weil Coding-Agenten oft mit den Rechten ihrer Nutzer laufen. Ein kompromittierter Prozess kann deshalb nicht nur den aktuellen Ordner sehen, sondern im schlechtesten Fall auch SSH-Schlüssel, Cloud-Zugangsdaten, Tokens aus der Shell-Umgebung oder andere lokale Projekte erreichen. Für Privatanwender ist das unangenehm. Für Teams mit produktiven Zugängen kann es ein ernstes Lieferkettenproblem werden. Die jüngste Einstufung einer kritischen Cyberfähigkeit bei OpenAI betrifft eine andere Ebene, zeigt aber dieselbe Richtung: Agenten müssen nicht nur kluge Antworten geben, sondern ihre Werkzeuge verlässlich begrenzen.
Was Entwickler jetzt tatsächlich tun sollten
Die wichtigste Regel lautet: Einen fremden Projektordner wie fremden ausführbaren Inhalt behandeln. Wer ein Archiv oder einen Ordner mit bereits vorhandenem .git-Verzeichnis erhält, sollte ihn nicht direkt in einem privilegierten Agenten öffnen. Erst auf einer isolierten Maschine oder in einem restriktiven Container prüfen, woher er stammt und welche Git-Konfiguration enthalten ist. Das ist kein Aufruf, jede Open-Source-Abhängigkeit zu misstrauen. Es ist eine saubere Reihenfolge: Herkunft und Metadaten prüfen, dann mit möglichst wenig Berechtigungen arbeiten.
Ebenso wichtig sind Updates. Die öffentlich dokumentierten Fixes helfen nur, wenn die installierte Version tatsächlich aktuell ist. Teams sollten Agenten, Editor-Erweiterungen und MCP-Server in ihre normale Patch-Routine aufnehmen, statt sie als harmlose Produktivitätshelfer nebenher laufen zu lassen. Bei bereits geöffneten verdächtigen Projekten ist es sinnvoll, verwendete Tokens und Schlüssel zu bewerten und gegebenenfalls aus einer sauberen Umgebung zu erneuern. Bloß den Projektordner zu löschen beantwortet nicht die Frage, ob etwas mit den vorhandenen Rechten ausgeführt wurde.
Für professionelle Umgebungen gehören zusätzlich technische Grenzen dazu: getrennte Konten oder Container für Experimente, keine langfristigen Zugangsdaten im Agentenprozess, eingeschränkter Netzwerkzugang und explizite Freigaben für neue MCP-Server. In CI-Systemen sollten Agenten keine unvertrauten Pull Requests mit weitreichenden Geheimnissen verarbeiten. Dass ein Tool eine Bestätigung anzeigt, reicht nicht, wenn es schon vorher Nebenprozesse startet. Vertrauen muss vor der Ausführung greifen, nicht erst im sichtbaren Dialog.
Ausblick: Agentensicherheit beginnt im Maschinenraum
Die Debatte über KI-Sicherheit dreht sich oft um Prompt-Injection, Modellfähigkeiten oder die Qualität erzeugten Codes. Diese Fälle sind eine Erinnerung an eine weniger glamouröse Schicht: Prozesse, Konfigurationsdateien und Standardbefehle. Ein Agent kann vorsichtig formuliert sein und trotzdem ein Risiko schaffen, wenn sein Startvorgang fremde Metadaten mit zu viel Vertrauen übernimmt.
Die gute Nachricht ist, dass sich ein großer Teil des Problems technisch klar beschreiben lässt. Hersteller können Git-Aufrufe so isolieren, dass lokale Projektkonfigurationen keine Hilfsprogramme starten. Organisationen können Ausführung, Berechtigungen und Netzwerke besser trennen. Nutzer können fremde Verzeichnisse zuerst prüfen. Je selbstständiger Coding-Agenten werden, desto weniger darf die Sicherheit davon abhängen, dass ein unsichtbarer Startschritt zufällig harmlos bleibt.