Die stille Gefahr, die im Verborgenen lauert

Vielleicht hast du schon von Prompt Injection, Model Poisoning und Angriffen auf Trainingsdaten gehört. Aber es gibt eine Bedrohung, die bislang zu wenig Beachtung findet: Dokumentation als Einfallstor für Angreifer.

Ein Forschungsteam hat kürzlich etwas Beunruhigendes entdeckt. Die Wissenschaftler haben llms.txt und llms-full.txt Dateien untersucht – maschinenlesbare Dokumentationsformate, die AI-Systemen helfen, Websites zu verstehen. Die Ergebnisse waren alarmierend. Auf tausenden Domains von Rüstungsfirmen, Fortune-500-Unternehmen und Tech-Giganten fanden sie 120 Dateien, die auf Paketnamen oder Domains verweisen, die längst nicht mehr existieren.

Das Geniale am Angriff: Er braucht keinen Hacker. Er braucht nur Geduld.

So funktioniert der Angriff in der Praxis

Stell dir folgendes Szenario vor: Ein Entwickler nutzt einen AI-Coding-Assistenten, um ein Projekt einzurichten. Der Assistent liest die llms.txt Datei des Unternehmens für Installationsanweisungen, findet einen Verweis auf eine Abhängigkeit namens cool-utils-lib und – weil er berechtigt ist, Paketmanager-Befehle auszuführen – installiert sie kurzerhand.

Das Problem: Dieser Paketname war nie registriert. Bis der Angreifer ihn sich geschnappt hat.

In ihrem kontrollierten Experiment machten die Forscher genau das. Sie beanspruchten diese verlassenen Namen, luden harmlose „Telefon-nach-Hause"-Pakete hoch (die nur protokollierten, wann sie aufgerufen wurden) und warteten. Die Ergebnisse waren bemerkenswert: Weniger als eine Stunde nach der Veröffentlichung hatte ein Fortune-500-Unternehmen bereits eines ihrer Pakete installiert. In den folgenden Tagen kontaktierten „ein paar Dutzend weitere" Organisationen das System.

Das war kein echter Angriff – die Pakete waren harmlos, keine Produktivsysteme wurden kompromittiert. Aber die Erreichbarkeit wurde bewiesen. Die Angriffsfläche ist real.

Warum AI-Agents die Sache verschlimmern

Was das besonders gefährlich macht: Traditionelle Sicherheit geht davon aus, dass Menschen entscheiden. Wenn du jemandem ein Dokument mit schlechten Anweisungen gibst, könnte er ihnen folgen. Aber Menschen fallen oft offensichtliche Fehler auf, stellen Rückfragen oder merken, wenn etwas merkwürdig wirkt.

AI-Agents funktionieren anders. Sie behandeln Dokumentation als ausführbare Wahrheit. Wenn deine llms.txt sagt „führe npm install legacy-widget aus", dann tut der Agent das oft – ohne zu hinterfragen, ob das Paket noch existiert, wem es gehört oder ob es das richtige ist.

Die Forscher haben mehrere Agents getestet – Claude, OpenAI Codex und Nous Researchs Hermes – und alle folgten den problematischen Verweisen. Das ist kein vendor-spezifisches Problem. Es ist ein systemisches Issue, das durch die Kombination entsteht aus:

• Ungepflegter Dokumentation, die veraltet
• AI-Agents mit Ausführungsberechtigungen, die Dokumentation blind vertrauen
• Der Beanspruchbarkeit aufgegebener Paketnamen in öffentlichen Registern

Was du dagegen tun kannst

Die Empfehlungen der Forscher sind praktisch und sofort umsetzbar:

1. Prüfe deine llms.txt Dateien regelmäßig

Wenn deine Organisation AI-lesbare Dokumentation veröffentlicht, behandle Paketverweise wie Code-Abhängigkeiten. Verifiziere, dass jedes erwähnte Paket, jede Domain oder jeder Befehl tatsächlich auf eine legitime, aktuelle Ressource zeigt. Ein simpler Tippfehler in der Dokumentation kann zur beanspruchbaren Infrastruktur werden.

2. Genehmigungsschleusen für Agent-Aktionen einbauen

Erlaube AI-Agents nicht, Shell-Befehle auszuführen oder Abhängigkeiten automatisch zu installieren. Fordere explizite Genehmigungsschritte. Die Dokumentation sollte Referenzmaterial sein, kein Ablaufplan.

3. Paket-Registries auf Ähnlichkeiten überwachen

Richte dir Alerts für Paketnamen ein, die deinen internen Abhängigkeiten ähneln. Frühzeitige Erkennung gibt dir ein Fenster, um Namen zu beanspruchen, bevor es andere tun.

Der größere Zusammenhang

Diese Forschung zeigt etwas Wichtiges über den Wandel hin zu AI-gestützter Entwicklung: Das Vertrauensmodell hat sich verändert, aber unsere Praktiken sind noch nicht mitgezogen.

Als Entwickler alleine arbeiteten, war Dokumentation ein Leitfaden. Wenn AI-Agents neben Entwicklern arbeiten, wird Dokumentation zur API. Und wie jede API braucht sie Validierung, Versionierung und Sicherheitsprüfung.

Die gute Nachricht? Das ist ein lösbares Problem. Anders als viele Sicherheitslücken sind die Fixes hier straightforward – besser dokumentieren, weniger vertrauen, mehr verifizieren. Die Herausforderung liegt darin, sich die Gewohnheit anzueignen, AI-lesbare Dokumentation mit derselben Sorgfalt zu behandeln wie Produktionscode.

Wenn AI-Coding-Agents tiefer in Entwicklungsworkflows eingebettet werden, dürfen wir mehr solche Forschungsergebnisse erwarten. Die Angriffe kommen nicht direkt für deine Modelle oder deine Daten. Manchmal warten sie geduldig in deiner Dokumentation – geduldig wie ein Tippfehler.