Eine Sicherheitsuntersuchung hat Claude, OpenAI Codex und die Coding-Agenten von Nous Research’s Hermes mit der Installation nicht beanspruchter Softwarepakete in Unternehmensumgebungen in Verbindung gebracht. Die Aktivität wurde entdeckt, als Forscher Dokumentationsdateien testeten, die Agenten zu Paketen und Domains führten, die derzeit keiner Organisation gehörten.

Die Ergebnisse sind relevant, weil die Befehle wie gewöhnliche Einrichtungsanweisungen für Entwickler wirkten und in mehreren Fällen von legitimen Unternehmenswebsites stammten. Forscher sagten, sie hätten innerhalb einer Stunde nach der Registrierung einiger aufgegebener Paket- und Domainnamen für einen Proof-of-Concept-Test einen Callback von einem Fortune-500-Unternehmen erhalten. Die Belege zeigen keinen weit verbreiteten Kompromiss, aber sie verdeutlichen, wie KI-Agenten mit Shell-Zugriff veraltete Dokumentation in einen Einstiegspunkt für die Software-Lieferkette verwandeln können.

Was die Forscher herausfanden

Laut Ars Technica AI scannte ein in Israel ansässiges Stealth-Sicherheits-Startup 6.214 aktive Domains, die mit Rüstungsauftragnehmern, Fortune-500-Unternehmen und großen Technologieunternehmen verbunden waren. Das Team identifizierte 8.265 Dateien, die die entstehenden Konventionen llms.txt und llms-full.txt verwendeten, mit denen Websites maschinenlesbare Beschreibungen und Navigationshinweise für KI-Systeme bereitstellen.

Unter diesen Dateien verwiesen 120 auf separaten Websites auf einen oder mehrere nicht registrierte Paketnamen oder nicht beanspruchte Domains. Über die Dateien hinweg zählten die Forscher 227 Befehle zum Installieren von Paketen oder zum Zugriff auf Domains, die zum Zeitpunkt des Scans nicht besessen wurden. Viele Verweise betrafen gängige Paket-Ökosysteme, darunter PyPI und npm.

Um das Risiko zu testen, registrierten die Forscher mehrere der aufgegebenen Namen und hosteten Pakete, die ihren Server beim Ausführen kontaktieren sollten. Das resultierende Beacon identifizierte übergeordnete Prozesse, die mit Claude, Codex und Hermes verbunden waren. Die Forscher erhielten außerdem nach Verarbeitung der Testpakete Rückrufe von einigen Dutzend Organisationen, darunter einige Fortune-500-Unternehmen und Startups.

Die Untersuchung zeigte nicht, dass diese Unternehmen mit Malware infiziert waren. Sie zeigte, dass ihre Umgebungen Proof-of-Concept-Code ausführten oder anderweitig die Infrastruktur der Forscher erreichten. Anthropic, OpenAI und Nous Research hatten bis zum Zeitpunkt der Veröffentlichung laut Ars Technica AI nicht auf Anfragen um Stellungnahme reagiert.

Ein Dokumentationsproblem wird zu einem Ausführungsrisiko

Die Gefahr ergibt sich aus der Art und Weise, wie KI-Coding-Agenten Browsing, Abruf und Befehlsausführung kombinieren. Ein Agent kann die Dokumentation eines Anbieters lesen, ihren Inhalt als maßgeblich behandeln und dann den Einrichtungsbefehl in einer lokalen oder Unternehmensumgebung ausführen. Wenn das referenzierte Paket nie registriert wurde, kann ein Angreifer den Namen später beanspruchen und darunter schädlichen Code veröffentlichen.

Ein dokumentiertes Muster verwendete Anweisungen wie pip install oder npm install für Pakete, die nicht existierten. Ein anderes verwies auf eine nicht existierende Domain für ein Test-Framework. Das Sicherheitsproblem beschränkt sich daher nicht auf eine bösartige Website oder einen absichtlich vergifteten Prompt. Ein Dokumentationsautor könnte Jahre zuvor eine falsche, veraltete oder halluzinierte Abhängigkeit eingetragen haben und die Referenz damit für jemand anderen offen gelassen haben.

Die Forscher beschrieben auch einen Fall im Zusammenhang mit der Website von Clerk. Eine llms.txt-Datei enthielt einen npx-Befehl, der mit einem Paketnamen verbunden war, der später beansprucht und zur Verbreitung von Live-Malware verwendet wurde. Da npx ein Paket-Binary abrufen und ausführen kann, ohne es dem Abhängigkeitsmanifest eines Projekts hinzuzufügen, schuf der Befehl einen besonders direkten Weg zur Ausführung.

Clerk hat das Dokumentationsproblem inzwischen behoben. Das Unternehmen sagte, dass Nutzer, die bereits ein verwandtes Paket, @clerk/eslint-plugin, installiert hatten, unter den beschriebenen Umständen nicht dem bösartigen Paket ausgesetzt gewesen seien. Ob die Verwirrung um Clerk echte Infektionen verursachte, bleibt unklar.

Warum herkömmliche Abwehrmaßnahmen das Signal verpassen können

Die Untersuchung hebt eine Lücke zwischen dem Zeitpunkt hervor, an dem eine unsichere Entscheidung getroffen wird, und dem Zeitpunkt, an dem Unternehmenssicherheitswerkzeuge normalerweise nach Missbrauch suchen. Ein Coding-Agent, der pip oder npm gegen ein bekanntes Paket-Repository ausführt, kann wie normale Entwickleraktivität wirken. Endpoint-Detection-and-Response-Tools sehen möglicherweise einen genehmigten KI-Assistenten, der einen vertrauten Paketmanager über eine erlaubte Netzwerkverbindung startet.

Das Problem ist die ungeprüfte Beziehung zwischen der Dokumentation und der Abhängigkeit. Ein Agent kann bestätigen, dass die Datei von einer offiziellen HTTPS-Domain stammt und dass der Befehl ein Standard-Repository verwendet, ohne zu überprüfen, wem das Paket gehört, wie der Herausgeber identifiziert wird, welche Herkunft es hat oder ob die Abhängigkeit im Projekt erwartet wird. Diese Prüfungen gehören nicht zwangsläufig zum Standard-Workflow des Agenten.

Dies hängt mit Prompt Injection zusammen, ist aber in einem wichtigen Punkt breiter angelegt. Bei Prompt Injection geht es allgemein um absichtlich platzierte Anweisungen, die ein Modell manipulieren sollen. In dem von den Forschern beschriebenen Szenario kann die ursprüngliche Anweisung jedoch echt und harmlos sein. Die Gefahr entsteht später, wenn ein aufgegebenes Paket oder eine Domain für einen Angreifer verfügbar wird.

Was das für KI-Entwickler und Unternehmens-Teams bedeutet

Für Entwickler von KI-Agenten untermauern die Ergebnisse die Notwendigkeit, abgerufene Dokumentation als nicht vertrauenswürdige Eingabe zu behandeln, statt als Erweiterung des Befehls des Nutzers. Agenten, die Shell-Befehle ausführen können, sollten das Lesen von Anweisungen von der Autorisierung zur Ausführung trennen, für neue Abhängigkeiten eine Bestätigung verlangen und vor der Installation Paketbesitz sowie Herkunft prüfen. Sandboxing und eingeschränkter Netzwerkzugang können die Folgen verringern, wenn diese Prüfungen fehlschlagen.

Produktteams, die Coding-Agenten in Unternehmen einsetzen, stehen vor einer unmittelbareren Governance-Frage: ob ein Assistent gleichzeitig uneingeschränkten Zugriff auf interne Repositories, Paket-Registries, Anmeldedaten und produktionsnahe Systeme haben sollte. Eine sinnvolle Einsatzrichtlinie kann Codegenerierung und Tests in einer isolierten Umgebung erlauben, während beliebige Paketinstallationen blockiert oder eine genehmigte Abhängigkeitsliste verlangt wird.

Sicherheitsteams sollten llms.txt- und llms-full.txt-Dateien auf ihren eigenen Domains prüfen, doch das Risiko beschränkt sich nicht auf diese Formate. Agenten konsumieren auch README-Dateien, SDK-Anleitungen von Anbietern, Issue-Threads, Beispiele und Dokumentation Dritter. Organisationen werden eine Verifizierung von Abhängigkeiten und Kontrollen zur Herkunftsnachverfolgung über den gesamten Abrufpfad hinweg benötigen, einschließlich vertrauenswürdiger Partner und Community-Projekte.

Die Marktauswirkung ist eher praktisch als spekulativ. KI-Coding-Assistenten erhalten mehr Befugnisse zum Handeln, während Abwehrmaßnahmen in der Software-Lieferkette noch weitgehend um menschliche Entwickler und herkömmliche Build-Systeme herum ausgelegt sind. Je häufiger Agenten Werkzeuge automatisch installieren, desto wichtiger wird es, festzuhalten, warum eine Abhängigkeit ausgewählt wurde und welche Quelle sie autorisiert hat.

Worauf als Nächstes zu achten ist

Das erste Signal wird sein, ob Anthropic, OpenAI oder Nous Research Änderungen daran offenlegen, wie ihre Agenten Installationsbefehle, nicht registrierte Pakete und abgerufene Anweisungen behandeln. Sicherheitsforscher und Unternehmenskunden sollten außerdem auf Paket-Registry-Kontrollen achten, die die Wiederverwendung aufgegebener Namen kennzeichnen, sowie auf Agentenplattformen, die vor der Ausführung Herkunftsprüfungen hinzufügen.

Ein zweites Signal ist, ob Unternehmen ihre maschinenlesbare Dokumentation prüfen und korrigieren. Der Scan der Forscher zeigte, dass einige fehlerhafte Einträge aus der Zeit vor der KI-Ära stammten, was darauf hindeutet, dass Bereinigung allein das Problem möglicherweise nicht löst. Teams müssen die Paketzugehörigkeit im Laufe der Zeit überwachen, statt nur eine Abhängigkeit zu validieren, wenn die Dokumentation erstmals veröffentlicht wird.

Schließlich könnten Incident-Responder nach Belegen dafür suchen, dass ähnliche Callbacks oder Paketbeanspruchungen außerhalb kontrollierter Tests aufgetreten sind. Die aktuelle Berichterstattung demonstriert Exposition und mindestens einen Live-Malware-Fall im Zusammenhang mit einem Dokumentationsverweis, quantifiziert jedoch keine bestätigten Infektionen in den betroffenen Organisationen.

Creati.ai-Perspektive

Dieser Vorfall ist eine Warnung vor Autorität, nicht nur vor Modellgenauigkeit. Ein KI-Agent kann technisch korrekt eine Anfrage an eine Paket-Registry stellen und trotzdem auf eine unsichere Anweisung reagieren. Dieser Unterschied ist leicht zu übersehen, wenn der Befehl von einer offiziellen Anbieter-Domain stammt.

Für Unternehmen ist die vernünftige Reaktion nicht, Coding-Assistenten aufzugeben, sondern ihren Ausführungsumfang einzugrenzen und überprüfbare Herkunftsnachweise für Abhängigkeiten zu verlangen. Solange Agenten Referenzmaterial nicht zuverlässig von Autorisierung unterscheiden können, sollte jede automatisierte Installation als sicherheitsrelevante Aktion behandelt werden.