Vertrauen auf Probe: Wie DevOps KI-Agenten vor HalluSquatting schützt

Projektabhängigkeiten als Einfallstor für Schadcode zu nutzen, ist nichts Neues. Beim klassischen Typosquatting verlassen sich Angreifer auf einen zutiefst menschlichen Faktor: Tippfehler.

Sie registrieren Paketnamen, die sich nur minimal von populären Bibliotheken unterscheiden, und warten darauf, dass sich jemand bei der Angabe des Paketnamens vertippt.

Mit dem Einsatz von LLMs hat sich Cybersquatting weiterentwickelt. Durch den neuen Akteur hat die Angriffsfläche eine neue Dimension bekommen: Der Tippfehler kommt nun nicht mehr vom Menschen, sondern vom LLM. Beim sogenannten Slopsquatting registrieren die Angreifer Paketnamen, die LLMs halluzinieren. So entstehen plausibel klingende, aber nicht existierende Namen für fiktive Abhängigkeiten, die Modelle in generiertem Code empfehlen.

Dass dieses Szenario realistisch ist, belegt die Studie "We Have a Package for You!" [2]. Von 16 getesteten Modellen erfanden diese im Durchschnitt ~20 % der vorgeschlagenen Paketnamen. Die Namen existierten schlicht nicht. Bei den großen kommerziellen Modellen waren es immerhin noch ~5 % [2][3]. Besonders brisant dabei ist, dass 43 % der Halluzinationen bei zehnfacher Wiederholung derselben Anfrage jedes Mal wieder auftauchen und damit reproduzierbar sind [2][3]. Angreifer können damit systematisch testen, welche Modelle welche Namen regelmäßig "erfinden", und diese dann für ihre eigenen Zwecke verwenden.

Verwandt, aber anders gelagert, ist die Dependency Confusion: Hier nutzen Angreifer aus, dass Paketmanager Paketnamen in mehreren Namensräumen auflösen – etwa in einem privaten und einem öffentlichen Repository. Wer in der öffentlichen Registry ein Paket mit demselben Namen wie ein internes Paket anlegt, kann den Auflösungsmechanismus austricksen und eigenen Code einschleusen. Bislang setzt dieser Angriff voraus, dass die internen Paketnamen bekannt sind. Auch dafür eröffnet KI neue Wege: Werden nicht freigegebene KI-Tools – Stichwort "Shadow AI" – etwa für Code Reviews genutzt, können interne Abhängigkeiten in den Trainingsdaten der Modelle landen und von dort nach außen dringen. Was als Datenleck beginnt, endet als Angriffsvektor.

Doch Angreifer müssen nicht auf Datenlecks warten: Beim HalluSquatting kann das Modell die verwundbaren Namen zum Beispiel selbst liefern und wird so zu einem attraktiven Ziel.

Zuerst waren es Tippfehler, dann halluzinierte Paketnamen – nun geraten auch vollständige Projekte und Agenten-Erweiterungen ins Visier. Doch nicht nur der Angriffspunkt hat sich verschoben, sondern auch das Ziel: Zielten Typo- und Slopsquatting auf Paket-Ökosysteme, richtet sich HalluSquatting direkt gegen agentische Systeme.

Doch was passiert hierbei im Detail?

Die Angreifer identifizieren jegliche Ressourcen, die gerade im Trend sind. Populäre Repositories, Skills – alles, was im Kontext von Agenten-Systemen angesagt ist und häufig abgefragt wird. Anhand dieser Ressourcen berechnen sie dann statistisch, mit Hilfe von Trendanalysen, welche Namen LLMs in dem besagten Kontext mit hoher Wahrscheinlichkeit halluzinieren. Anschließend squatten (besetzen) sie die vielversprechendsten Ergebnisse und versehen die in der Ressource (ganzes Repository, Markdown-Dateien) hinterlegten Daten mit Schadcode. Dann heißt es warten, bis sich das Opfer den schädlichen Code beziehungsweise die Prompts selbst installiert [1].

Der mitgelieferte Payload kann zwei Gestalten annehmen: klassischer Schadcode, der bereits bei der Installation ausgeführt wird, oder sogenannte Prompt Injections. Dabei handelt es sich um Anweisungen, die die ursprünglichen Arbeitsaufträge überschreiben und dem Angreifer dadurch die Möglichkeit einräumen, das Agenten-System für seine eigenen Zwecke zu nutzen.

Wie zuverlässig das funktioniert, zeigt die Arbeit von Aya Spira und ihrem Team. Getestet wurden Angriffe unter anderem auf die Coding-Assistants Cursor, Cursor CLI, Windsurf, GitHub Copilot, Cline und Gemini CLI sowie auf die Assistenzsysteme OpenClaw, ZeroClaw und NanoClaw [1]. Die Modelle erzeugten in bis zu 85 % der Clone-Anfragen und in bis zu 100 % der Skill-Installationen eine nicht existierende Ressource – modellübergreifend transferierbar. Der vollständige Angriff, also das Beziehen der Ressource samt Ausführung des Payloads, gelang bei den Coding-Assistants in 20 bis 65 %, bei den Assistenzsystemen in 40 bis 100 % der Versuche. Bislang handelt es sich um eine kontrollierte akademische Demonstration mit vorheriger Offenlegung an die Hersteller – dokumentierte reale Vorfälle sind (Stand August 2026) nicht bekannt.

Da viele agentische Anwendungen Terminal- oder Shell-Zugriff haben, kann der Angreifer über den Payload beispielsweise einen Bot auf dem Gerät installieren und so ein agentisches Botnet aufbauen [1].

Die eigentliche Lehre aus HalluSquatting ist nicht, dass KI halluziniert. Halluzinationen werden erst gefährlich, wenn wir ihnen ungeprüfte Handlungsmacht geben. Genau hier greift der DevOps-Gedanke: Kontrollpunkte, die unabhängig funktionieren, egal ob der Input von einem Menschen oder einem Modell stammt.

Warum fallen uns Freigaben ausgerechnet bei KI-basierten Akteuren so leicht?
Der Automation Bias beschreibt unsere Neigung, technischen Systemen übermäßig zu vertrauen [4].

Agenten verschärfen diesen Effekt doppelt: Wirken Systeme menschlich und dynamisch, schenken wir ihnen eher Vertrauen – obwohl sie fehleranfälliger sind als statische, deterministische Programme. Anders als klassische Automatisierungen folgen sie nicht ausschließlich vorab festgelegten Abläufen. Sie planen dynamisch, verarbeiten externe Daten und rufen die verschiedensten Werkzeuge auf. Dabei entstehen viele Möglichkeiten, bei denen fehlerhafte oder manipulierte Informationen in konkrete Handlungen überführt werden. Die Folge: Ein hohes Potenzial für Incidents entsteht, und auch vorhandene Human-in-the-Loop-Freigaben verkommen durch das übermäßige Vertrauen schnell zur Routine. Im Eingangsszenario war es schließlich der Mensch, der die Installation genehmigt hat.

DevOps war nie primär eine Toolbewegung. Im Kern geht es um People, Process, Technology. Wichtig ist hierbei die Reihenfolge – die Menschen sollen im Zentrum stehen. Werkzeuge entfalten ihren Wert nur eingebettet in durchdachten Prozessen mit nachvollziehbaren Kontrollpunkten. Menschen gestalten und verantworten diese Abläufe.

Wir arbeiten seit Jahren mit Reviews, Continuous-Integration (CI) -Pipelines mit Approvals und Signaturen sowie Quality Gates. Nicht, weil wir unseren Kollegen und Kolleginnen misstrauen, sondern weil Fehler unvermeidbar sind. KI ändert daran nichts; sie verschiebt nur, wo die Fehler entstehen. Wenn wir KI-Agenten zunehmend als eine Art Teammitglied begreifen, schulden wir ihnen dieselben Dinge wie unseren menschlichen Mitstreitern: klare Verantwortlichkeiten, begrenzte Berechtigungen, Transparenz und Feedback.

Human in the Loop ist hierbei keineswegs ein Ausdruck von Misstrauen, vielmehr der Ausdruck professionellen Systemdenkens.

Konkret heißt das, sich immer wieder folgende Fragen zu stellen:

• People: Wer übernimmt Verantwortung?
• Process: Welche Prozesse (Pipeline/Automation) verhindern, dass Fehler ihre Wirkung entfalten? (Alle Fehler verhindern zu wollen, wäre utopisch.)
• Technology: Welche Werkzeuge setzen das technisch um?

Dass es dabei nicht nur um Angriffe von außen geht, zeigt der Vorfall bei PocketOS: Dort löschte ein Cursor-Agent die Produktionsdatenbank samt Backups [5].

Das Werkzeug besaß Handlungsmacht, aber weder Prozess-Gates noch eine Begrenzung seines Wirkungsbereichs. Die Parallele zu HalluSquatting ist kein Zufall: Die Wurzelursache ist dieselbe – fehlende Rechtebegrenzung. Nur der Auslöser unterscheidet sich: dort ein Angreifer, hier ein schlichter Fehler.

Die erste Stufe setzt dort an, wo eine neue Abhängigkeit vorgeschlagen wird: beim Entwickler/Anwender und seinem KI-Agenten. Als Grundregel gilt: Jeder von einem LLM vorgeschlagene externe Bestandteil ist zunächst nicht vertrauenswürdig. Das betrifft nicht nur Pakete, sondern auch Repositories, Skills, Plug-ins, MCP-Server und Agentenkonfigurationen.

Vor der Verwendung ist zu prüfen, ob das Artefakt tatsächlich zum behaupteten Projekt gehört: Seit wann existiert es? Wer sind die Maintainer? Ist das verknüpfte Repository plausibel? Stimmen Dokumentation, Veröffentlichungsverlauf und Paket-Metadaten überein? Gibt es Sicherheitsmeldungen oder auffällige Installationsskripte? Alter und Downloadzahlen liefern dabei lediglich Indizien. Ein erst wenige Wochen altes Paket mit wenigen Downloads und einem Namen, der auffällig gut zur Anfrage passt, verlangt jedenfalls besondere Aufmerksamkeit.

Autonome Agenten verschärfen das Risiko, weil sie das Zeitfenster für eine Prüfung verkleinern oder vollständig umgehen. Unbeschränkte Autopilot- oder "YOLO"-Modi haben deshalb auf produktiven Arbeitsgeräten nichts verloren. Installationen, Shell-Befehle und Änderungen an sicherheitsrelevanten Dateien sollten eine explizite Freigabe und eine technische Policy-Prüfung erfordern. Der Agent selbst sollte nur mit minimalen Berechtigungen und möglichst in einer Sandbox, einem Container oder einer Wegwerf-VM ausgeführt werden.

Auch Agentenanweisungen wie CLAUDE.md, Cursor-Regeln oder Skill-Dateien gehören ins Code Review. Sie sind nicht bloß Dokumentation: Für den Agenten können sie dieselbe Wirkung entfalten wie ausführbarer Code. Lokale Pre-Commit-Hooks, IDE-Warnungen, Secret Scanner und Dependency Scanner unterstützen diese Prüfung.

Quality Gate dieser Stufe: Keine neue externe Ressource gelangt ungeprüft und ohne nachvollziehbare Änderung in das Repository.

Sobald eine Änderung das lokale Entwicklungssystem verlässt, beginnt die zweite Stufe. Was ein Entwickler plausibilisiert hat, muss nun reproduzierbar und unabhängig geprüft werden. Dafür gelten dieselben Regeln – unabhängig davon, ob der Code von einem Menschen oder einem KI-Agenten stammt.

Neue und veränderte Abhängigkeiten sollten im Pull Request deutlich sichtbar sein und ein verpflichtendes Review auslösen. Versionen werden exakt festgeschrieben; Lockfiles gehören in die Versionsverwaltung und dürfen nicht ungesehen als automatisch erzeugtes Nebenprodukt behandelt werden. Das Pinning verhindert zwar nicht, dass erstmals ein bösartiges Paket aufgenommen wird. Es schützt aber davor, dass spätere Builds unbemerkt eine andere Version beziehen. Wo das Ökosystem es unterstützt, müssen zusätzlich Integritätswerte und Signaturen geprüft werden.

Die CI-Pipeline kontrolliert außerdem, ob Paketquelle, Name, Version und Lizenz den zentralen Policies entsprechen. Software Composition Analysis (SCA) macht bekannte Schwachstellen und transitive Abhängigkeiten sichtbar. Ergänzend können Policies neu hinzugefügte Installationsskripte, direkte Downloads oder bislang unbekannte Registries blockieren. Generell gilt das Vier-Augen-Prinzip.

Entscheidend ist, dass die Freigabe nicht zur routinemäßigen Bestätigung verkommt. Ein Mensch im Prozess ist noch kein wirksames Quality Gate – erst eine nachvollziehbare Prüfung macht ihn dazu.

Quality Gate dieser Stufe: Nur geprüfte, reproduzierbar auflösbare und policykonforme Abhängigkeiten dürfen in den Build gelangen.

Eine validierte Abhängigkeit ist noch kein vertrauenswürdiges Build-Artefakt. In der dritten Stufe wird deshalb kontrolliert, aus welchen Quellen der Build seine Bestandteile bezieht und unter welchen Bedingungen sie verarbeitet werden.

Build-Systeme sollten Abhängigkeiten nicht unkontrolliert aus beliebigen öffentlichen Registries laden. Stattdessen empfiehlt sich ein zentraler Registry Proxy oder eine private Registry, über die freigegebene Pakete bereitgestellt werden. Neue Drittanbieterpakete können zunächst in eine Quarantäne- oder Staging-Zone gelangen und erst nach erfolgreicher Prüfung für reguläre Builds freigegeben werden.

Interne Paketnamen und Namensräume dürfen niemals auf öffentliche Registries zurückfallen. Eine bloße Priorisierung nach dem Muster "intern vor öffentlich" reicht nicht aus, wenn der Paketmanager bei einem Fehlschlag dennoch die öffentliche Quelle abfragt. Besser sind reservierte Namespaces, explizite Quellzuordnungen und eine Policy, die nicht freigegebene Registries grundsätzlich blockiert.

Der Build selbst erfolgt reproduzierbar, isoliert und möglichst ohne unnötigen Netzwerkzugriff. Er erzeugt neben dem eigentlichen Artefakt eine Software Bill of Materials (SBOM), dokumentiert die verwendeten Abhängigkeiten und versieht Artefakt sowie Provenance-Nachweis mit einer Signatur. So wird nicht nur festgehalten, was gebaut wurde, sondern auch woraus, wo und unter welchen Bedingungen.

Quality Gate dieser Stufe: Aus einem validierten Commit entsteht ein nachvollziehbares, unveränderliches und attestiertes Artefakt.

In der letzten Stufe entscheidet sich, welches Artefakt eine Test-, Staging- oder Produktionsumgebung erreichen darf. Dabei gilt: Eine Dependency ist zunächst ebenso wenig vertrauenswürdig wie neu eingebrachter Quellcode. Vertrauen entsteht nicht durch Herkunftsbehauptungen, sondern durch überprüfbare Nachweise und bestandene Quality Gates.

Promotet wird deshalb ausschließlich das bereits geprüfte und signierte Artefakt – nicht derselbe Quellstand in einem neuen Build. Vor jeder Promotion werden Signatur, Herkunftsnachweis, SBOM und Policy-Ergebnisse erneut kontrolliert. Schlägt eine Prüfung fehl oder hat sich eine Risikobewertung verändert, wird die Auslieferung blockiert.

Auch nach der Freigabe endet das Dependency Management nicht. Neue Schwachstellen, kompromittierte Maintainer oder zurückgezogene Pakete können eine bereits genehmigte Komponente nachträglich zum Risiko machen. Kontinuierliches Monitoring muss deshalb sichtbar machen, welche ausgelieferten Artefakte eine betroffene Abhängigkeit enthalten. Erst diese Rückverfolgbarkeit ermöglicht eine gezielte Reaktion, einen Rollback oder einen erneuten Build.

Für besonders kritische Umgebungen ergänzt eine manuelle Freigabe die technischen Kontrollen. Sie ersetzt diese jedoch nicht. Die Entscheidung wird vom Menschen verantwortet; die Einhaltung der festgelegten Regeln erzwingt das System.

Quality Gate dieser Stufe: Nur signierte, attestierte und unverändert geprüfte Artefakte dürfen die nächste Umgebung erreichen.