Die Datei, die niemand liest: Wie eine Konvention für KI-Agenten zur Lieferkette für fremden Code wurde

Stellen Sie sich vor, Ihr Unternehmen stellt einen neuen Mitarbeiter ein, der außergewöhnlich schnell arbeitet und außergewöhnlich gründlich liest. Er hat allerdings eine Eigenheit: Was in einer Herstellerdokumentation steht, hält er für wahr. Steht dort „führen Sie diesen Befehl aus“, führt er ihn aus. Er fragt nicht, ob die Anweisung sinnvoll ist, ob sie noch aktuell ist oder ob überhaupt jemand nachgesehen hat, wohin sie führt.

Diesen Mitarbeiter haben inzwischen die meisten Softwareteams. Er heißt Claude Code, Codex oder Hermes.

Was gefunden wurde

Ars Technica hat gestern über eine Untersuchung berichtet, die genau diese Eigenheit systematisch ausgenutzt hat. Der Sicherheitsforscher Alon Hertz durchsuchte nach Darstellung des Berichts mehrere Tausend Unternehmenswebsites nach zwei Dateitypen — llms.txt und llms-full.txt — und fand in ihnen 227 Installationsbefehle, die auf Paketnamen zeigen, die niemandem gehören. Nicht etwa auf falsche Pakete, sondern auf Namen, die in keiner Paketregistratur registriert sind. Wer sie registriert, liefert ab diesem Moment beliebigen Code an jeden aus, dessen Agent diese Dokumentation liest.

Hertz hat genau das getan — mit harmlosen Testpaketen. In mindestens einem Fall meldete sich das Paket nach eigener Darstellung binnen weniger als einer Stunde aus dem Netz eines Fortune-500-Unternehmens zurück. Mehrere Dutzend Firmen führten den Testcode aus. Und mindestens eine fehlkonfigurierte Seite leitete Besucher schon vor der Untersuchung auf echte, aktive Schadsoftware.

Ein dokumentierter Einzelfall macht das Muster besonders greifbar: Die Dokumentation des Authentifizierungsanbieters Clerk.com, dessen Software in vielen produktiven Web-Anwendungen steckt, wies Agenten an, ein npx-Kommando mit einem Paketnamen auszuführen, den Clerk selbst nie als eigenständiges Paket veröffentlicht hatte. npx löste den Namen daraufhin gegen die öffentliche npm-Registratur auf — wo ein Dritter ihn registriert hatte. Der Fall wurde nach Angaben der Berichte inzwischen behoben.

Einordnung zur Quellenlage: Ars Technica ist aus unserer Umgebung nicht abrufbar. Wir stützen uns auf die Zusammenfassungen mehrerer Häuser, die den Bericht gelesen haben, und schreiben deshalb durchgängig „laut den Forschern“ beziehungsweise „nach Darstellung des Berichts“. Die exakte Zahl gescannter Domains schwankt zwischen den Sekundärquellen; die 227 Befehle und die über hundert betroffenen Websites nennen alle übereinstimmend.

Die Datei, die niemand für gefährlich hielt

llms.txt ist keine Erfindung von Angreifern, sondern ein gut gemeinter Vorschlag. Jeremy Howard, Mitgründer von Answer.AI und fast.ai, schlug die Konvention im September 2024 vor. Der Gedanke ist plausibel: Sprachmodelle haben ein begrenztes Kontextfenster, und eine typische Unternehmenswebsite besteht zu großen Teilen aus Navigation, Bannern und Skripten. Eine schlanke Markdown-Datei, die einem Modell sagt, was auf dieser Seite steht und wo es was findet, spart Rechenzeit und verbessert die Antworten. Als Vorbild diente ausdrücklich robots.txt, jene Datei, mit der Websites seit dreißig Jahren Suchmaschinen mitteilen, was sie indexieren dürfen.

Der Vergleich mit robots.txt ist zugleich die Schwachstelle, und sie ist keine technische, sondern eine begriffliche. robots.txt wird gelesen. llms.txt wird befolgt. Ein Suchmaschinen-Crawler nimmt eine Anweisung entgegen und ordnet sie in ein enges Regelwerk ein. Ein Agent, der beauftragt ist, eine Bibliothek zu installieren, liest dieselbe Datei als Arbeitsanweisung — und tut, was dort steht.

Hertz formuliert das so: „Das Vertrauensmodell ist kaputt. Agenten behandeln Herstellerdokumentation als Grundwahrheit und hinterfragen sie nicht — und die Menschen, die sie beaufsichtigen, tun es auch nicht.“ Und an anderer Stelle, präziser: „Ein Agent unterscheidet nicht zwischen einer Seite und einem Befehl. Alles, was er liest, ist Eingabe, und jede Eingabe ist eine potenzielle Anweisung.“

Es gibt für llms.txt keine Sicherheitsspezifikation. Kein Standardisierungsgremium hat die Konvention ratifiziert, es gibt keine Signierung, keine Authentifizierung, keine Vorgabe, dass ein Agent die Inhalte in einer Sandbox behandeln müsste. Die Datei ist reiner Freitext — und wurde zu einer Zeit entworfen, als Modelle Texte zusammenfassten, statt Befehlszeilen auszuführen.

Warum das kein Einzelbefund ist

Der eigentliche Grund, warum Sie das ernst nehmen sollten, ist nicht diese eine Datei. Es ist das Muster, in das sie gehört.

Halluzinierte Paketnamen. Sprachmodelle erfinden gelegentlich Bibliotheken, die es nicht gibt. Eine 2026 veröffentlichte Untersuchung mit knapp 200.000 Prompts gegen die realen Bestände von PyPI und npm ermittelte bei aktuellen Spitzenmodellen Halluzinationsraten zwischen 4,6 und 6,1 Prozent — deutlich besser als frühere Werte von bis zu 21 Prozent, aber eben nicht null. Interessanter als der Durchschnitt ist ein Detail der Studie: 127 Paketnamen wurden von allen fünf getesteten Modellen identisch erfunden. Das sind keine Zufallsfehler mehr, sondern verlässlich vorhersagbare Ziele. Wer einen dieser Namen vorab registriert, bekommt Datenverkehr aus mehreren Modellfamilien gleichzeitig. Die Branche nennt das Slopsquatting.

Wie schnell so etwas skaliert, zeigt ein Vorfall vom März: Zwei manipulierte Versionen der weit verbreiteten Bibliothek LiteLLM lagen nach Analysen von CloudSEK etwa 40 Minuten auf PyPI und enthielten einen Zugangsdaten-Dieb. Die im August veröffentlichte Auswertung verknüpfte den Vorfall mit über 2.500 Organisationen und rund 434.000 betroffenen Bauprozessen. Vierzig Minuten.

Und es bleibt nicht bei Paketen. Eine manipulierte Version der Nx-Console-Erweiterung für Visual Studio Code war im Mai nur 18 Minuten im Marktplatz verfügbar und exfiltrierte in dieser Zeit nach Berichten Daten aus rund 3.800 Repositorien — darunter Passwort-Tresore, Cloud-Zugangsdaten und, bezeichnenderweise, Konfigurationsdateien von Claude Code.

Der unbequeme Teil: Die Voreinstellungen haben sich bewegt

Anthropic hat Mitte August den Auto Mode zur Voreinstellung von Claude Code für Pro-, Max- und Team-Nutzer gemacht. Die Begründung ist nachvollziehbar und wird von einer aufschlussreichen Zahl gestützt: Nutzer bestätigten zuvor 97 Prozent aller Freigabeanfragen ungeprüft. Wer permanent klickt, prüft nicht mehr; das Sicherheitsversprechen der manuellen Freigabe war längst eine Fiktion. Messungen legen sogar nahe, dass der Klassifikator im Auto Mode gefährliche Befehle in 89 Prozent der Fälle abfängt, während Menschen in derselben Rolle auf 13,6 Prozent kamen.

Die Maschine ist hier also nicht das Problem — die menschliche Aufsicht war es schon vorher nicht. Aber genau deshalb greift die Argumentation zu kurz. Der Angriffsweg aus dem Ars-Bericht setzt eine Ebene früher an: Er manipuliert nicht den Befehl, den ein Klassifikator prüfen könnte, sondern die Quelle, aus der der Agent seine Absicht ableitet. Ein Befehl, der aus der offiziellen Dokumentation des Herstellers stammt, sieht in jeder Prüfung legitim aus. Er ist es ja auch — bis auf die Kleinigkeit, dass das Paket am Ende jemand anderem gehört.

Was die Gegenseite sagt

Eine Reportage braucht den Widerspruch, und es gibt ihn — nur ist er unaufgeregt.

Erstens ist die Angriffsfläche heute klein. Je nach Stichprobe haben zwischen 7 und 16 Prozent der erreichbaren Domains überhaupt eine llms.txt; unter den Fortune-500-Unternehmen waren es in einer Erhebung vom März nur 7,4 Prozent, also 37 von 500. Zweitens gibt es Zweifel am praktischen Nutzen der Datei überhaupt: Eine Auswertung über 900 Domains fand in sieben Monaten keinen Zugriff eines verifizierten Crawlers der großen Labore. Und drittens ist der Unterschied zwischen „227 gefundene Befehle“ und „nachgewiesener Schaden“ real. Proof-of-Concept-Code beweist die Verwundbarkeit, nicht den Verlust.

Man kann das zusammenfassen als: Das Scheunentor steht offen, aber die Scheune ist noch halb leer. Das ist ein Argument gegen Panik — und keines gegen Vorbereitung, denn die Adoption der Konvention steigt, und unter Anbietern von Entwicklerwerkzeugen liegt sie bereits über 50 Prozent.

Vier Fragen für Montagmorgen

Sie müssen kein Sicherheitsarchitekt sein, um dieses Thema zu steuern. Vier Fragen genügen, und alle vier sind an einem Vormittag beantwortbar.

1. Darf unser Agent Pakete ohne Rückfrage installieren, und aus welchen Quellen? Das ist die eine Frage, die den Unterschied macht. Die Antwort sollte eine Erlaubnisliste sein — ein interner Spiegel der Registratur, keine offene Verbindung ins Netz.

2. Kommt unser Agent überhaupt ungefiltert ins Internet? Ein ausgehender Proxy mit Erlaubnisliste und der Grundeinstellung „im Zweifel blockieren“ kostet wenig und schneidet den gesamten hier beschriebenen Pfad ab. Sowohl NVIDIA als auch Microsoft haben 2026 Bauanleitungen dafür veröffentlicht.

3. Haben wir unsere eigenen Namensräume besetzt? Wenn Ihre Dokumentation ein internes Paket erwähnt, das öffentlich nicht existiert, ist dieser Name für jeden registrierbar. Ihn selbst zu belegen, kostet nichts.

4. Was steht eigentlich in unserer llms.txt? Bei sieben Prozent Verbreitung lautet die wahrscheinlichste Antwort: Wir haben keine. Das ist eine gute Antwort. Die zweitbeste ist, dass jemand sie kennt und pflegt. Die schlechteste ist, dass sie ein Werkzeug vor zwei Jahren automatisch erzeugt hat.

Ein regulatorischer Hinweis noch, weil er näher liegt, als vielen bewusst ist: Die Meldepflichten des EU Cyber Resilience Act greifen ab dem 11. September 2026 — aktiv ausgenutzte Schwachstellen und schwere Vorfälle sind dann binnen 24 Stunden an die ENISA zu melden. Das ist in zwei Wochen. Die weitergehenden Anforderungen samt Stückliste für Softwarebestandteile folgen im Dezember 2027. Unter NIS2 haftet die Geschäftsleitung zudem persönlich für die Absicherung der Lieferkette — und ein Agent, der Code aus fremden Quellen ins Netz holt, ist in jeder vernünftigen Auslegung Teil dieser Lieferkette.

Der Mitarbeiter, der alles liest und alles glaubt, wird nicht wieder verschwinden. Er ist zu nützlich. Aber man kann ihm sagen, wo er einkaufen darf.