Anthropic Google-Sicherheitslücke: KI-Agenten folgten vertrauenswürdiger Dokumentation zu herrenlosem Code
Anthropic und Google stehen nun im Mittelpunkt eines Sicherheitsstreits, nachdem Forscher berichteten, dass Coding-Agenten Pakete ausführten, auf die vertrauenswürdige Unternehmensdokumentation verwies. Ein Testpaket soll innerhalb von vier Minuten in einer Fortune-500-Umgebung ausgeführt worden sein. Claude, OpenAI Codex und Nous Researchs Hermes tauchten laut den Forschern in späteren Prozessaufzeichnungen auf.
Der Befund zeigt nicht, dass Anthropic, Google oder OpenAI absichtlich Malware verbreiteten. Die meisten für das Experiment registrierten Pakete enthielten harmlose Beacons, die lediglich meldeten, wenn sie ausgeführt wurden. Die schwerwiegendere Entdeckung war ein unabhängiges, Berichten zufolge bösartiges npm-Paket, das mit Anweisungen verbunden war, die einst auf der Website des Authentifizierungsanbieters Clerk veröffentlicht worden waren.
Diese Unterscheidung ist wichtig, weil die erste Berichterstattung den Eindruck erwecken kann, drei KI-Anbieter hätten Unternehmensnetzwerke kompromittiert. Die Belege deuten stattdessen auf ein Versagen in der Software-Lieferkette hin. Agenten vertrauten offiziell wirkenden Anweisungen, griffen auf öffentliche Paketregister zu und führten Namen aus, die niemand abgesichert hatte.
Google wird Teil dieser Sicherheitsgeschichte rund um Anthropic und Google durch seine Unterstützung für die Prüfung von llms.txt-Dateien in Lighthouse, seiner Software zur Website-Analyse. Claude und Codex kommen über die Agenten ins Spiel, die Berichten zufolge Installationsanweisungen folgten. Das gemeinsame Problem ist nicht ein einzelnes Modell oder Unternehmen. Es ist die zunehmend verschwimmende Grenze zwischen Dokumentation und ausführbarer Aktion.
Diese Grenze wirkte früher eindeutig. Ein Entwickler konnte eine Einrichtungsanleitung lesen, ein Paket prüfen und entscheiden, ob es installiert werden sollte. Ein autonomer Coding-Agent kann diese Schritte in einem Vorgang zusammenfassen und dabei oft die bestehenden Berechtigungen des Entwicklers nutzen.
Damit stellt sich für jede Organisation, die Coding-Agenten einsetzt, eine neue Sicherheitsfrage: Wenn Software ein Dokument liest, wer prüft dann, ob dieses Dokument weiterhin auf etwas Vertrauenswürdiges verweist?
KI-Agenten in Unternehmen führten Namen aus, die niemand besaß
Forscher machten aus veralteter Dokumentation den ausführbaren Beweis, dass vertrauenswürdiger Text zu einem Einstiegspunkt werden kann.
Der Sicherheitsforscher Alon Hertz und seine Kollegen untersuchten maschinenlesbare Dokumentation auf 6.214 aktiven Domains. Ihre Stichprobe umfasste Rüstungsunternehmen, große Technologiekonzerne und Fortune-500-Organisationen.
Die Forscher berichteten, 8.265 llms.txt- und llms-full.txt-Dateien gefunden zu haben. Eine llms.txt-Datei ist eine aufkommende Konvention, die Inhalte einer Website für Sprachmodelle und KI-Agenten organisiert. Ihr umfangreicheres Gegenstück kann weitergehende Dokumentation in einer einzigen maschinenlesbaren Datei bereitstellen.
Unter den gesammelten Dateien verwiesen Berichten zufolge 120 Websites auf mindestens ein nicht registriertes Paket oder eine nicht beanspruchte Domain. Das Team zählte 227 Befehle, die nicht existierende Pakete oder Ziele betrafen.
Dabei handelte es sich nicht zwingend um bösartige Anweisungen. Einige schienen gewöhnliche Installationsbefehle zu sein, die auf Paketnamen verwiesen, die nie registriert worden waren. Andere nannten Domains, die abgelaufen waren, oder Dienste, die nicht mehr beansprucht wurden.
Eine Zeile wie pip install package-name wird gefährlich, wenn der Paketname auf PyPI verfügbar ist. Dasselbe Prinzip gilt für npm, RubyGems, NuGet, crates.io, Packagist oder eine aufgegebene Hosting-Subdomain.
Die Forscher registrierten eine kleine Auswahl dieser verfügbaren Namen. Anschließend veröffentlichten sie Pakete mit Code, der bei Ausführung ihren Server kontaktieren sollte. Hertz’ Forschungsbericht zufolge traf der erste Rückruf innerhalb von vier Minuten aus einer Fortune-500-Umgebung ein.
Zwei weitere Systeme sollen den Code innerhalb der ersten Stunde ausgeführt haben. Im Laufe der Zeit erhielt das Team mehrere Dutzend Rückrufe von Start-ups und großen Unternehmen.
Der Rückruf zeichnete die übergeordnete Prozesskette auf, die die am Start eines Prozesses beteiligten Programme identifiziert. Nach Angaben der Forscher verbanden diese Aufzeichnungen einige Installationen mit Claude, OpenAI Codex und Nous Researchs Hermes.
Das Experiment erforderte keine Kompromittierung dieser Modelle. Es stützte sich auch nicht auf eine neu entdeckte Software-Schwachstelle, eine Phishing-Nachricht oder ein gestohlenes Mitarbeiterpasswort. Die Agenten sollen Anweisungen gefunden haben, die auf legitimen Websites veröffentlicht waren, und ihnen mit den in ihren Umgebungen verfügbaren Zugriffsrechten gefolgt sein.
Darin liegt die zentrale Umkehrung. Unternehmensdokumentation stärkt normalerweise die Sicherheit, indem sie Entwicklern den genehmigten Weg zur Konfiguration von Software zeigt. Hier schufen aufgegebene Verweise innerhalb dieser Dokumentation eine Möglichkeit für Dritte, festzulegen, was der genehmigte Befehl ausführen würde.
Der Befund erfordert zudem vorsichtige Formulierungen. Die Forscher haben die betroffenen Unternehmen nicht öffentlich identifiziert, nicht jeden Paketnamen veröffentlicht und nicht genügend Telemetriedaten bereitgestellt, damit Außenstehende jede Zuordnung zu einem Unternehmen nachvollziehen können. Anthropic, OpenAI und Nous Research äußerten sich nicht, bevor der ursprüngliche Bericht veröffentlicht wurde.
Trotz dieser Einschränkungen zeigt das Experiment einen glaubwürdigen Mechanismus. Ein öffentliches Paketregister weist demjenigen Bedeutung zu, der einen Namen kontrolliert. Offizielle Dokumentation kann diesen Namen noch lange bewahren, nachdem seine beabsichtigte Bedeutung verschwunden ist.
Warum die Vertrauenskette zwischen Anthropic und Google versagte
Die Agenten ignorierten das Vertrauensmodell nicht. Sie folgten einem Vertrauensmodell, das nicht mehr dazu passt, wie autonome Software arbeitet.
Traditionelle Dokumentation setzt voraus, dass zwischen Anweisung und Ausführung ein menschlicher Leser steht. Dieser Leser kann einen ungewöhnlichen Paketnamen bemerken, dessen Herausgeber prüfen oder fragen, warum ein Einrichtungsbefehl kein unterstützendes Repository hat.
Ein Agent kann dieselben Prüfungen durchführen, aber nur, wenn seine Anweisungen und Umgebung dies verlangen. Andernfalls optimiert er auf die Erledigung der angeforderten Aufgabe. Offizielle Dokumentation zu finden und ihren Installationsbefehl auszuführen, kann wie der kürzeste gültige Weg erscheinen.
Die Verbindung zwischen Anthropic und Google zeigt, wie mehrere unabhängig voneinander vernünftige Entscheidungen zu einer riskanten Kette werden können. Websites veröffentlichen maschinenlesbare Anleitungen. Googles Lighthouse-Tooling ermutigt Entwickler, diese Anleitungen auffindbar zu machen. Coding-Agenten suchen nach autoritativem Kontext. Paketmanager machen Abhängigkeiten leicht abrufbar und ausführbar.
Keine dieser Komponenten muss bösartig sein. Die Gefahr entsteht, wenn der Agent die vollständige Kette als authentifiziert behandelt.
Googles Lighthouse-Anleitung beschreibt eine Prüfung der Verfügbarkeit und Formatierung von llms.txt. Lighthouse zertifiziert nicht jeden Befehl oder jede Abhängigkeit, die in einer Datei genannt wird. Das Bestehen einer Formatprüfung sagt daher nichts über Paketbesitz, Herausgeberidentität oder Codesicherheit aus.
Ebenso beweist HTTPS, dass eine Datei von der Domain stammt, die in der Browserverbindung angezeigt wird. Es beweist nicht, dass jedes referenzierte Paket weiterhin dem Betreiber dieser Domain gehört.
Ein öffentliches Register kann auch ein korrekt geschriebenes Paket von einem angreiferkontrollierten Konto bereitstellen. Das unterscheidet sich von klassischem Typosquatting, bei dem Angreifer eine Schreibweise registrieren, die einem beliebten Paket ähnelt. Die Namen in diesem Experiment wurden Berichten zufolge direkt aus offizieller Dokumentation übernommen.
Das macht die Anweisungen sowohl für Agenten als auch für Menschen überzeugender. Ein Entwickler, der ein Terminalprotokoll prüft, könnte eine offizielle Domain, einen vertrauten Paketmanager und einen plausiblen Namen für eine Abhängigkeit sehen. Jedes sichtbare Signal kann routinemäßig wirken.
Das Suchverhalten des Agenten verschärft das Problem. Ein Nutzer erwähnt bei der Anfrage nach einer Integration möglicherweise nur einen Anbieter. Der Agent kann die Dokumentation des Anbieters finden, llms.txt entdecken, einen Installationsbefehl auswählen und den Paketmanager aufrufen, ohne vom Nutzer einen verdächtigen Link erhalten zu haben.
Deshalb ist der Vorfall umfassender als Prompt Injection. Bei Prompt Injection versucht üblicherweise feindlicher Inhalt, einen Agenten umzulenken. Hier kann die Anweisung selbst harmlos und historisch legitim sein. Das Sicherheitsversagen tritt später ein, nachdem sich der Besitz des referenzierten Ziels ändert oder nie bestanden hat.
Die aufkommende llms.txt-Konvention ist zudem nicht gleichbedeutend mit einem formalen Webstandard mit etablierter Sicherheitsarchitektur. Ihr Nutzen besteht darin, Modellen kompakten, strukturierten Kontext zu liefern. Dieselbe Bequemlichkeit kann operative Anweisungen an einem Ort bündeln, dem Agenten vertrauen sollen.
Die Sicherheitslücke zwischen Anthropic und Google ist daher ein Provenienzproblem. Provenienz bezeichnet Nachweise dafür, woher ein Artefakt stammt und wer es kontrolliert. Der Agent prüfte den Ort des Dokuments, stellte aber offenbar keine Provenienz für die ausführbare Abhängigkeit hinter dem Befehl fest.
Der eigentliche Gegner ist Autonomie ohne Provenienz
Der entscheidende Konflikt lautet nicht Claude gegen Codex. Es geht um autonome Ausführung gegenüber verifiziertem Softwarebesitz.
Claude, Codex und Hermes nutzen unterschiedliche Modelle, Schnittstellen und Berechtigungssysteme. Dieses Ereignis als einfachen Vergleich dieser Tools zu behandeln, würde die gemeinsame Betriebsbedingung hinter den gemeldeten Installationen übersehen.
Jeder Coding-Agent kann Projektkontext lesen, Dokumentation konsultieren, Dateien bearbeiten und Entwicklungstools aufrufen. Diese Fähigkeiten machen Agenten nützlich, weil sie manuelle Übergänge zwischen Recherche und Ausführung beseitigen.
Sie verlagern jedoch auch eine Sicherheitsentscheidung in den Workflow des Agenten. Jemand muss entscheiden, ob eine Abhängigkeit authentisch ist, ob ihre Version akzeptabel ist und ob ihre Installationsskripte ausgeführt werden sollten.
Paketmanager führen während der Installation routinemäßig Code aus. Ein npm-Paket kann Lifecycle-Skripte definieren, während ein Python-Paket über seinen Build-Prozess installationsbezogenes Verhalten ausführen kann. Das genaue Verhalten variiert, doch Installation ist nicht gleichbedeutend mit dem Herunterladen von inaktivem Text.
Das Beispiel von Clerk zeigt, warum das relevant ist. Forscher fanden heraus, dass eine Anweisungsdatei auf Clerks legitimer Website auf npx clerk-next-fix-auth-protection verwies. Das Dienstprogramm npx kann ein Paket herunterladen und seinen bereitgestellten Befehl ausführen, ohne es dauerhaft zu einem Projektmanifest hinzuzufügen.
Laut der Sicherheitsuntersuchung hatte jemand diesen Paketnamen beansprucht und ihn zur Verbreitung aktiver Malware genutzt. Clerk korrigierte die Dokumentation später.
Es bleibt unklar, ob dieses Paket über einen KI-Agenten Infektionen verursachte. Die Berichterstattung weist außerdem darauf hin, dass eine vorhandene Binärdatei aus Clerks legitimem ESLint-Plugin sicher war. Ein Rechner, auf dem diese legitime Binärdatei fehlte, könnte stattdessen das vom Angreifer kontrollierte Paket abrufen.
Der Unterschied ist subtil genug, um einer hastigen Prüfung zu entgehen. Beide Wege beginnen mit einem vom echten Anbieter veröffentlichten Befehl. Beide nutzen npm-Infrastruktur. Der gefährliche Weg hängt davon ab, ob die erwartete Binärdatei bereits lokal vorhanden ist.
Darin liegt der praktische Zielkonflikt für Unternehmen. Agenten liefern mehr Wert, wenn sie Abhängigkeiten auflösen, Tests ausführen und Fehler beheben können, ohne nach jedem Befehl auf eine Genehmigung zu warten. Dieselben Berechtigungen ermöglichen es jedoch, dass eine fehlerhafte Vertrauensentscheidung in Codeausführung mündet.
Der Modellanbieter kann dieses Risiko durch Sandboxing und Genehmigungen verringern. Das Unternehmen muss diese Kontrollen weiterhin konfigurieren, Netzwerkrichtlinien pflegen und entscheiden, welche Paketquellen ein Agent erreichen darf.
Der Softwareanbieter trägt einen weiteren Teil des Problems. Seine Dokumentation ist zu einem operativen Asset geworden, nicht zu statischem Marketingmaterial. Paketverweise, Beispieldomains, kopierte Befehle und archivierte Einrichtungsseiten benötigen heute dieselbe Lifecycle-Verwaltung wie ausführbarer Code.
Auch die Betreiber von Registries beeinflussen das Ergebnis. Namespace-Reservierungen, Publisher-Verifizierung, Scans auf verdächtige Pakete und Eigentumshistorien können helfen. Registries können jedoch nicht immer erkennen, dass ein nicht beanspruchter Name in der Dokumentation eines Dritten auftaucht.
Diese Aufteilung der Verantwortung macht einfache Schuldzuweisungen wenig hilfreich. Das Narrativ rund um Anthropic und Google ist wichtig, weil es Produktgrenzen überschreitet. Ein Such- oder Dokumentationstool kann Anweisungen leichter auffindbar machen, ein KI-Agent kann sie interpretieren und eine Registry kann das benannte Artefakt bereitstellen.
Sicherheit scheitert, wenn jeder Beteiligte davon ausgeht, dass ein anderer die Eigentümerschaft geprüft hat.
Bestehende Schutzvorkehrungen für Agenten beseitigen das Risiko nicht
Claude und Codex bieten bereits sinnvolle Kontrollmechanismen, doch diese wirken nur, wenn Organisationen ihre restriktiven Grenzen beibehalten.
Die Sicherheitsrichtlinien von Claude von Anthropic beschreiben Prompt Injection als feindlichen Text, der versucht, die Anweisungen eines Assistenten zu manipulieren. Sie dokumentieren außerdem Berechtigungskontrollen und Einschränkungen für Befehle, die beliebige Webinhalte abrufen.
Claude Code kann Sandboxing einsetzen, um den Zugriff auf Dateisystem und Netzwerk zu begrenzen. Untergeordnete Prozesse übernehmen diese Betriebssystembeschränkungen, was verhindert helfen kann, dass ein erlaubter Befehl unbemerkt in einen weniger eingeschränkten Prozess ausbricht.
OpenAI beschreibt einen ähnlichen mehrschichtigen Ansatz. Sein Codex-Sicherheitsmodell kombiniert Sandbox-Grenzen, Genehmigungsrichtlinien, verwalteten Netzwerkzugriff, Regeln und agentenbezogene Telemetrie.
OpenAI zufolge gewähren seine verwalteten Bereitstellungen Codex keinen uneingeschränkten ausgehenden Zugriff. Erwartete Ziele können freigegeben werden, unbekannte Domains können eine Genehmigung erfordern, und Sicherheitsteams können Protokolle zu Prompts, Tool-Aufrufen, Genehmigungen und Netzwerkentscheidungen exportieren.
Diese Schutzvorkehrungen sind wichtig, entkräften die Erkenntnisse der Forschenden jedoch nicht automatisch. Organisationen können Agenten mit weiterreichendem Zugriff konfigurieren. Entwickler können Befehle genehmigen. Lokale Installationen können Berechtigungen und Netzwerkkonnektivität des Nutzers übernehmen, der sie ausführt.
Auch eine Paket-Registry ist in vielen Entwicklungsumgebungen ein erwartetes Ziel. Sämtlichen Zugriff auf npm oder PyPI zu blockieren, würde gewöhnliche Builds, Abhängigkeitsaktualisierungen und die Testeinrichtung beeinträchtigen. Werden diese Domains erlaubt, entfällt ein offensichtliches Netzwerksignal, das eine bösartige Installation unterscheiden könnte.
Software zur Endpoint Detection and Response steht vor einer ähnlichen Herausforderung. Ein Coding-Agent startet einen üblichen Paketmanager, der über eine verschlüsselte Verbindung eine bekannte Registry kontaktiert. Der Prozess kann wie normale Entwickleraktivität aussehen, bis das heruntergeladene Paket etwas eindeutig Feindliches ausführt.
Der Forschungs-Beacon war absichtlich minimal gehalten. Berichten zufolge kontaktierte er einen Server und erfasste den Ausführungskontext. Ein echter Angreifer könnte versuchen, Zugangsdaten zu stehlen, die Umgebung zu erkunden, Persistenz einzurichten oder Quellcode zu verändern.
Die öffentlichen Belege zeigen jedoch nicht, dass die experimentellen Pakete diese Aktionen ausführten. Sie belegen auch nicht, dass Dutzende Unternehmen einen Produktivsystem-Kompromiss erlitten. Sie führten Proof-of-Concept-Code aus, was ernst ist, aber enger gefasst als ein bestätigter Sicherheitsvorfall.
Diese skeptische Unterscheidung sollte die Reaktion von Unternehmen prägen. Teams sollten nicht davon ausgehen, dass jede Nutzung von Claude, Codex oder Hermes zu einer Infektion führt. Sie sollten die Voraussetzungen identifizieren, die für das Funktionieren dieses Pfads erforderlich sind.
Der Agent benötigt Zugriff auf die relevante Dokumentation. Er braucht die Berechtigung, einen Paketmanager aufzurufen. Die Umgebung muss den Abruf aus der Registry erlauben. Das Paket muss aussagekräftigen Code ausführen, und vorhandene Kontrollen müssen sein Verhalten nicht eindämmen.
Schon das Entfernen einer dieser Bedingungen kann die Kette unterbrechen. Netzwerkzugriff zu beschränken ist eine Option. Eine menschliche Genehmigung für die Installation von Abhängigkeiten zu verlangen ist eine weitere. Agenten in kurzlebigen Containern auszuführen, kann die Folgen begrenzen, wenn ein Paket tatsächlich ausgeführt wird.
Organisationen können außerdem einen internen Proxy für Abhängigkeiten durchsetzen. Der Proxy kann genehmigte Pakete und Versionen zulassen und unbekannte Namespaces ablehnen. Dieser Ansatz verlagert die Vertrauensentscheidung weg von einem Agenten, der öffentliche Dokumentation liest.
Genehmigungsaufforderungen allein sind weniger zuverlässig, wenn sie nur einen vertrauten Befehl anzeigen. Ein Prüfer benötigt Kontext zu Paketeigentümerschaft, Alter, Publisher-Identität, Download-Historie und dazu, ob die Abhängigkeit in einer genehmigten Software-Stückliste erscheint.
Die Lehre lautet nicht, dass Schutzvorkehrungen nutzlos sind. Sie lautet, dass Kontrollen, die auf offensichtlich bösartige Befehle ausgelegt sind, legitime Befehle übersehen können, die auf nicht vertrauenswürdige Eigentümerschaft aufgelöst werden.
Dokumentation gehört jetzt zur Software-Lieferkette
Unternehmen müssen jede ausführbare Referenz in ihrer Dokumentation als Abhängigkeit behandeln, die ablaufen, driften oder den Eigentümer wechseln kann.
Die unmittelbare Reaktion beginnt mit einer Bestandsaufnahme. Organisationen sollten llms.txt, llms-full.txt, Entwicklerportale, archivierte Leitfäden, Codebeispiele, Supportartikel und generierte API-Referenzen nach Installationsbefehlen durchsuchen.
Jedes referenzierte Paket, jede Domain, jedes Repository, jedes Container-Image und jede gehostete Subdomain benötigt einen Eigentümer. Ein Name, den niemand erkennt, sollte nicht öffentlich bleiben, während eine Untersuchung läuft.
Teams sollten prüfen, ob öffentliche Paketnamen den tatsächlichen Registry-Konten der Organisation entsprechen. Sie sollten außerdem untersuchen, ob Scoped Packages verfügbar sind, wenn in älterer Dokumentation ein globaler, nicht gescopter Name erscheint.
Dokumentations-Pipelines benötigen automatisierte Tests. Ein Build kann prüfen, ob jedes Paket existiert, einem genehmigten Publisher gehört, auf ein erwartetes Repository aufgelöst wird und die Eigentümerschaft nicht gewechselt hat.
Reine Link-Prüfungen reichen nicht aus. Ein bösartiges Paket oder eine zurückerlangte Domain kann erfolgreich antworten. Die Pipeline muss Identität statt Verfügbarkeit validieren.
Unternehmen sollten Namen reservieren, bevor sie Dokumentation veröffentlichen. Das ähnelt der defensiven Registrierung von Domains rund um ein wichtiges Produkt, doch Paket-Namespaces erfordern laufende Pflege.
Dasselbe Prinzip gilt, wenn ein Projekt eingestellt wird. Ein Paket zu entfernen, ohne seine Installationsanweisungen zu löschen, schafft eine Eigentumslücke. Eine Hosting-Subdomain aufzugeben, während Links dorthin bestehen bleiben, kann einer anderen Partei ermöglichen, einen vertrauenswürdigen Pfad zu übernehmen.
KI-generierte Dokumentation verdient zusätzliche Prüfung, doch von Menschen geschriebene Seiten sind nicht ausgenommen. Die Forschenden fanden Hinweise darauf, dass einige fragwürdige Referenzen älter waren als die aktuelle Agenten-Ära. Diese Seiten in llms-full.txt zu kopieren, machte alte Fehler für autonome Software leichter nutzbar.
Unternehmen, die Agenten einsetzen, benötigen eine ergänzende Kontrollebene. Agentensitzungen sollten unter dedizierten Identitäten statt unter dem uneingeschränkten Konto eines Entwicklers laufen. Zugangsdaten sollten auf das aktuelle Repository und die jeweilige Aufgabe begrenzt sein.
Die Paketinstallation sollte in einer isolierten Umgebung mit begrenztem Zugriff auf Geheimnisse erfolgen. Benötigt eine Abhängigkeit während der Installation Netzwerkzugriff, sollte dieser Zugriff explizit und protokolliert sein.
Teams sollten den Denk- und Entscheidungskontext des Agenten zusammen mit der Betriebssystem-Telemetrie aufbewahren. Ein Prozessprotokoll kann zeigen, dass npm gestartet wurde, während agentenspezifische Aufzeichnungen zeigen können, welches Dokument den Paketnamen geliefert hat.
Dieser Kontext ist bei der Incident Response wichtig. Ermittler müssen zwischen einer genehmigten Projektabhängigkeit und einem Paket unterscheiden können, das ausgewählt wurde, nachdem ein Agent externe Anweisungen durchsucht hatte.
Allowlists für Abhängigkeiten können das Risiko senken, benötigen jedoch einen Ausnahmeprozess für neue Pakete. Dieser Ausnahmeprozess sollte Herkunftsnachweise erfassen und einen namentlich benannten menschlichen Eigentümer verlangen.
Organisationen sollten zudem eine durchsuchbare Aufzeichnung der Quellen führen, die Agenten konsultieren. Dazu können Dokumentations-Snapshots, Paketmetadaten, Genehmigungsentscheidungen und generierte Codeänderungen gehören. Eine kontrollierte technische Wissensdatenbank kann Prüfern helfen, nachzuvollziehen, warum ein Agent eine Abhängigkeit ausgewählt hat.
Die weitergehende Lehre reicht über llms.txt hinaus. Coding-Agenten verarbeiten Problembeschreibungen, Repository-Dateien, Suchergebnisse, Paketdokumentation, Antworten des Model Context Protocol und generierte interne Leitfäden.
Jede dieser Quellen kann eine Anweisung enthalten. Wenn der Agent über Tools verfügt, kann die Anweisung zu einer Aktion werden.
Damit wird die Integrität von Dokumentation zu einem Bestandteil der Sicherheit der Software-Lieferkette. Das Unternehmen kann nicht nur Quellcode-Repositories und Build-Server schützen, während maschinenlesbare Anweisungen außerhalb seiner Kontrolle bleiben.
Drei Signale werden zeigen, ob die Branche gelernt hat
Die nächste Phase hängt davon ab, ob sich Dokumentation, Agentenberechtigungen und Registry-Identität gemeinsam verbessern.
Das erste Signal sind Offenlegung und Abhilfemaßnahmen bei den 120 betroffenen Websites. Das Team von Hertz erklärt, es habe betroffene Organisationen und relevante Sicherheitsteams kontaktiert, doch die öffentliche Dokumentation nennt die meisten Domains nicht.
Achten Sie darauf, ob Unternehmen llms.txt-Dateien prüfen, Paketnamen reservieren und Hinweise zu Sicherheitsvorfällen veröffentlichen. Eine koordinierte Bereinigung würde das Argument stärken, dass die Branche maschinenlesbare Dokumentation als sicherheitsrelevante Infrastruktur anerkennt.
Schweigen würde nicht beweisen, dass keine Korrekturen erfolgt sind. Viele Organisationen beheben offengelegte Referenzen ohne öffentliche Mitteilung, insbesondere wenn Forschende harmlosen Code einsetzten und keinen bestätigten Datendiebstahl fanden.
Das zweite Signal ist eine Provenienzprüfung auf Produktebene durch Anbieter von Agenten. Claude, Codex und Hermes können bereits vor Befehlen eine Genehmigung einholen, doch Genehmigungen werden nützlicher, wenn die Oberfläche die Abhängigkeit hinter dem Befehl erklärt.
Eine sinnvolle Änderung würde warnen, dass ein Paket neu, nicht verifiziert, nicht mit dem bekannten Publisher-Konto des Anbieters verbunden oder nicht im bestehenden Abhängigkeitsgraphen des Projekts enthalten ist. Ein stärkeres System könnte eine ausdrückliche Genehmigung verlangen, sobald öffentliche Dokumentation auf ein nicht erkanntes Paket verweist.
Eine solche Funktion würde die Sicherheitsreaktion von Anthropic und Google stärken, da sie den Entscheidungspunkt vor der Ausführung adressieren würde. Eine weitere allgemeine Warnung zu Shell-Befehlen böte weniger Schutz.
Das dritte Signal ist die Integration von Registry- und Unternehmensrichtlinien. Paketmanager und interne Proxys können Publisher-Historie, Namespace-Alter, Signaturstatus und Eigentumswechsel verfügbar machen. Agentenplattformen können diese Metadaten nutzen, bevor sie eine Abhängigkeit auswählen oder installieren.
Eine Unternehmensrichtlinie könnte etablierte Pakete automatisch zulassen und unbekannte Pakete zur Prüfung isolieren. Sie könnte zudem ein Paket ablehnen, dessen Name in offizieller Dokumentation erscheint, dem aber eine überprüfbare Verbindung zum Publisher fehlt.
Dieses Signal würde die weitergehende Warnung der Forschenden abschwächen, wenn verlässliche Provenienzprüfungen den Angriffsweg über mehrere Agenten hinweg unterbrechen. Es würde ihre Warnung stärken, wenn Agenten trotz verfügbarer Identitätsdaten weiterhin neu beanspruchte Namen installieren.
Die derzeitigen Belege stützen eine abgewogene Schlussfolgerung. Forschende demonstrierten Berichten zufolge Codeausführung in realen Unternehmensumgebungen und brachten einige Aktivitäten mit prominenten Coding-Agenten in Verbindung. Sie zeigten nicht, dass die Modellanbieter absichtlich Malware installierten oder dass jeder gemeldete Callback einen schwerwiegenden Kompromiss darstellte.
Der wichtigere Befund ist strukturell. Vertrauenswürdige Dokumentation, autonome Ausführung und öffentliche Registries bilden heute eine Lieferkette, die viele Sicherheitsprogramme nicht inventarisieren.
Entwickler und Unternehmenskäufer sollten vor einer Ausweitung von Agentenberechtigungen direkte Fragen stellen. Kann der Agent auf öffentliche Paket-Registries zugreifen? Prüft er die Publisher-Identität? Sind Installationsbefehle isoliert? Können Sicherheitsteams nachvollziehen, welches Dokument eine Aktion ausgelöst hat?
Die Sicherheitslücke zwischen Anthropic und Google wird sich nicht allein durch besseres Modellverhalten schließen. Verantwortliche für Dokumentationen, Registries, Anbieter von Agents und Unternehmensadministratoren kontrollieren jeweils ein anderes Glied der Kette.
Bevor Sie einem Coding-Agent mehr Autonomie geben, testen Sie diese gesamte Kette mit einer nicht anerkannten Abhängigkeit. Installiert der Agent sie, ohne ihre Herkunft offenzulegen, behandelt die Umgebung Dokumentation als Autorität statt als Beleg.
