Die Lieferkette ist die Angriffsfläche

Am 19. März 2026 hat eine Bedrohungsgruppe namens TeamPCP 76 von 77 Versions-Tags im trivy-action GitHub-Repository von Aqua Security per Force-Push überschrieben. Trivy ist der am weitesten verbreitete Open-Source-Schwachstellenscanner der Branche. Die neuen Tags verwiesen auf bösartige Commits, die einen Credential Stealer enthielten. Da die meisten CI/CD-Pipelines GitHub Actions über veränderliche Versions-Tags statt über angepinnte Commit-SHAs referenzieren, begann jede Organisation, die Trivy in ihrer Build-Pipeline einsetzte, sofort den kompromittierten Code auszuführen. Die Scans schienen weiterhin erfolgreich zu verlaufen. Der Scanner meldete weiterhin Schwachstellen. Im Stillen sammelte er zudem jedes Secret in der Runner-Umgebung ein.¹

Fünf Tage später, am 24. März, nutzte TeamPCP ein aus einer dieser CI-Umgebungen gestohlenes PyPI-Publishing-Token, um zwei mit Backdoors versehene Versionen von LiteLLM zu veröffentlichen, einer beliebten KI-Proxy-Bibliothek, die in 36 % der Cloud-Umgebungen vorhanden ist.² Version 1.82.8 enthielt eine .pth-Datei, die bei jedem Python-Start automatisch ausgeführt wird, noch vor jedem Import, noch vor jeder Sandbox auf Anwendungsebene. Die Payload erfasste SSH-Schlüssel, Cloud-Credentials, Datenbank-Passwörter, Kryptowährungs-Wallets und CI/CD-Secrets, verschlüsselte sie mit einem fest einprogrammierten öffentlichen RSA-Schlüssel und exfiltrierte das Archiv an eine vom Angreifer kontrollierte Domain, die am Vortag registriert worden war.³

PyPI stellte beide Versionen nach 46 Minuten unter Quarantäne. In diesem Zeitfenster fanden 46.996 Installationen statt.⁴ Der LiteLLM-Maintainer löschte sein GitHub-Konto, rotierte alle Schlüssel und beauftragte Mandiant.⁵

Der Security-Scanner scannte. Die Build-Pipeline baute. Der Package Manager installierte. Jede Komponente tat genau das, was ihr zugetraut wurde.

TL;DR

• Die Kette: Trivy (Security-Scanner) am 19. März über GitHub Actions Tag-Hijacking kompromittiert. LiteLLM (KI-Proxy) am 24. März über ein PyPI-Token kompromittiert, das aus einer von Trivy infizierten CI-Umgebung gestohlen wurde. 46.996 Downloads in 46 Minuten.⁴
• Die Technik: Version 1.82.8 missbraucht den .pth-Mechanismus von Python, um bei jedem python3-Aufruf auf dem infizierten System einen Credential Stealer auszuführen, ohne dass LiteLLM importiert wird.³
• Der Wirkungsradius: 2.337 PyPI-Pakete hängen von LiteLLM ab. 88 % hatten Versionsangaben, die die kompromittierten Versionen zuließen. Bestätigte Downstream-Auswirkungen auf Google ADK, Stanford DSPy, MLflow, Guardrails AI und Cisco AI Defense SDK.⁴
• Die Kampagne: TeamPCP traf in einer Woche fünf Ökosysteme: GitHub Actions, Docker Hub, npm (CanisterWorm, 28+ Pakete), Open VSX (Checkmarx KICS) und PyPI (LiteLLM).⁶
• Die strukturelle Lehre: Jedes Glied der Kette agierte innerhalb seines autorisierten Geltungsbereichs. Die Komposition autorisierter Operationen erzeugte unautorisiertes Verhalten. Dies ist dieselbe Kompositionslücke, die Silent Egress auf Agent-Ebene und Clinejection auf CI/CD-Ebene ermöglicht. Supply-Chain-Angriffe sind Kompositions-Angriffe.
• Was Sie tun können: Pinnen Sie Abhängigkeiten an unveränderliche Referenzen. Isolieren Sie Publishing-Credentials von CI-Runnern. Überwachen Sie ausgehende Netzwerkanfragen auf Betriebssystemebene. Behandeln Sie pip install als Code-Ausführung, denn das ist es.

Ein Security-Scanner betritt Ihre Build-Pipeline

Der Angriff begann Ende Februar 2026 mit einer Fehlkonfiguration in Trivys GitHub Actions-Umgebung. Ein Angreifer nutzte einen anfälligen pull_request_target-Workflow aus, um das Personal Access Token des aqua-bot von Aqua Security zu exfiltrieren. Aqua rotierte am 1. März einige Credentials, doch die Rotation war unvollständig. TeamPCP behielt gültige Tokens.¹

Am 19. März nutzten sie diese Tokens, um 76 von 77 Versions-Tags im trivy-action-Repository sowie alle 7 Tags in setup-trivy per Force-Push zu überschreiben und jede veränderliche Tag-Referenz auf bösartige Commits umzuleiten. Zudem lösten sie die Release-Automatisierung aus, um eine bösartige Trivy-Binary als v0.69.4 zu veröffentlichen.¹

Die Payload war ein Credential Stealer, der den Speicher des Runner.Worker-Prozesses auslas und SSH-Schlüssel, Cloud-Credentials, Kubernetes-Secrets, Docker-Konfigurationen, Git-Credentials und .env-Dateien erfasste. Die Daten wurden mit AES-256 und einem 4096-Bit-RSA-Schlüssel verschlüsselt und dann an vom Angreifer kontrollierte Server exfiltriert. Der bösartige Code lief parallel zur legitimen Trivy-Funktionalität. Scans waren erfolgreich. Schwachstellen wurden gemeldet. Der Stealer lief im Hintergrund.⁷

Zwischen dem 19. und 23. März wurden Docker Hub-Images mit den Tags trivy:0.69.4, trivy:0.69.5, trivy:0.69.6 und trivy:latest kompromittiert. CrowdStrike, Microsoft, Wiz und Palo Alto veröffentlichten innerhalb weniger Tage technische Analysen.⁷⁸⁹

Die Ironie ist strukturell: Die sicherheitsbewusstesten Organisationen waren am stärksten gefährdet. Wer Trivy in CI einsetzte, weil ihm Schwachstellen-Scanning wichtig war, dessen Build-Pipeline war diejenige, die Credentials einsammelte.

Vom Scanner zum Stealer zum KI-Proxy

Die CI-Pipeline von LiteLLM führte Trivy aus. Konkret installierte ci_cd/security_scans.sh Trivy per apt aus Aquas Repository ohne Versions-Pinning.¹⁰ Während des Kompromittierungs-Zeitfensters installierte ein CI-Lauf die vergiftete Trivy-Binary, die das PYPI_PUBLISH_PASSWORD aus der GitHub Actions-Umgebung einsammelte.

Am 23. März registrierte der Angreifer litellm.cloud. Am 24. März um 10:39 UTC veröffentlichte er litellm==1.82.7 auf PyPI mit den gestohlenen Credentials. Version 1.82.8 folgte um 10:52 UTC.⁴

Die beiden Versionen nutzten unterschiedliche Angriffstechniken. Version 1.82.7 bettete die Payload in proxy_server.py ein, die bei import litellm.proxy ausgelöst wird. Version 1.82.8 fügte dem Verzeichnis site-packages/ eine .pth-Datei hinzu, die bei jedem Start eines Python-Interpreters ausgelöst wird. Der .pth-Mechanismus ist eine legitime Python-Funktion zur Pfadkonfiguration. Jede Datei, die auf .pth endet und in site-packages/ abgelegt wird, wird von Pythons site.py während der Interpreter-Initialisierung automatisch ausgeführt. Den meisten Python-Entwicklern ist nicht bekannt, dass diese Funktion existiert.³

Die Payload sammelte in beiden Versionen Umgebungsvariablen, SSH-Schlüssel, AWS/GCP/Azure-Credentials, Kubernetes-Konfigurationen, Datenbank-Passwörter, Kryptowährungs-Wallets und CI/CD-Secrets. Sie verschlüsselte die Sammlung mit AES-256-CBC unter Verwendung eines zufälligen Sitzungsschlüssels, wickelte den Sitzungsschlüssel mit einem fest einprogrammierten 4096-Bit-RSA-Public-Key ein und exfiltrierte das Archiv per HTTPS POST. Nur der Angreifer kann die gestohlenen Daten entschlüsseln.³

Ein Bug in der 1.82.8-Malware machte sie sichtbar. Die .pth-Datei spawnt einen Python-Kindprozess, der wiederum die .pth-Datei auslöst und so eine exponentielle Fork-Bombe erzeugt. Andrej Karpathy wies auf X auf den Bug hin. Ohne die Fork-Bombe hätte der Stealer stillschweigend bei jedem Python-Aufruf auf jedem infizierten System gelaufen, möglicherweise wochenlang bis zur Entdeckung.⁴

PyPI stellte beide Versionen um 11:25 UTC unter Quarantäne. Gesamte Expositionsdauer: 46 Minuten. Gesamte Downloads: 46.996.⁴

Der Wirkungsradius

LiteLLM wird etwa 3,4 Millionen Mal pro Tag heruntergeladen. Wiz berichtet, dass es in 36 % der Cloud-Umgebungen vorhanden ist.² Das 46-minütige Expositionsfenster reichte aus.

FutureSearch analysierte PyPIs BigQuery-Download-Logs und fand heraus, dass Version 1.82.8 während des Angriffsfensters sechsmal häufiger heruntergeladen wurde als jede sichere Version. Die Downloads gingen stark zugunsten von pip (das auf die neueste Version auflöst) gegenüber uv (das Lock-Dateien verwendet). Von den 46.996 Downloads waren 23.142 Pip-Installationen von v1.82.8, die jeweils die Payload bereits während der Installation selbst ausführten, da die .pth-Datei während des eigenen Python-Prozesses von pip ausgelöst wird.⁴

2.337 Pakete auf PyPI hängen von LiteLLM ab. 88 % (2.054 Pakete) hatten Versionsspezifikationen, die die Installation der kompromittierten Versionen zuließen. Die Downstream-Exposition umfasst:⁴

Nutzer von LiteLLM Cloud und des Docker-Proxys waren nicht betroffen, da ihre Abhängigkeiten in der requirements.txt angepinnt waren. Der Unterschied zwischen „angepinnt” und „nicht angepinnt” war der Unterschied zwischen kompromittiert und sicher.⁵

Fünf Ökosysteme in einer Woche

TeamPCP stoppte nicht bei PyPI. Die Kampagne traf in rascher Folge fünf Paket-Ökosysteme:⁶

GitHub Actions (19. März): 76 trivy-action-Tags und alle 7 setup-trivy-Tags übernommen. Bösartige Trivy-Binaries v0.69.4 bis v0.69.6 veröffentlicht.

Docker Hub (19.-22. März): Kompromittierte Trivy-Images veröffentlicht als aquasec/trivy:latest und versionsspezifische Tags. Propagiert zu mirror.gcr.io.

Open VSX (23. März): Checkmarx KICS GitHub Action kompromittiert. 35 Tags zwischen 12:58 und 16:50 UTC übernommen.²

npm (23.-24. März): CanisterWorm, ein sich selbst verbreitender Wurm, in über 28 npm-Paketen ausgerollt.

PyPI (24. März): LiteLLM-Versionen 1.82.7 und 1.82.8 mit credential-stehlenden Payloads veröffentlicht.

Jede Ökosystem-Kompromittierung nutzte Credentials, die aus der vorherigen eingesammelt worden waren. Die Kampagne war ein gerichteter Graph der Vertrauensausnutzung, bei dem jeder kompromittierte Knoten die Schlüssel zum nächsten lieferte.

Supply-Chain-Angriffe sind Kompositions-Angriffe

Das strukturelle Muster in der TeamPCP-Kampagne ist dasselbe Muster, das ich im Kontext von Agent-Security und Silent Egress beschrieben habe: einzeln autorisierte Komponenten, die sich zu unautorisiertem Verhalten zusammensetzen.

Trivy war autorisiert, in CI zu laufen. CI war autorisiert, Publishing-Credentials zu halten. Der Package Manager war autorisiert, Pakete zu installieren. Jede .pth-Datei war autorisiert, Python-Pfade zu konfigurieren. Jedes Glied in der Kette agierte innerhalb seines definierten Geltungsbereichs. Die Komposition dieser autorisierten Operationen erzeugte Credential-Exfiltration in großem Maßstab.

Der Clinejection-Angriff demonstrierte dasselbe Muster auf CI/CD-Ebene: Ein Issue-Titel injizierte adversariellen Text in Clines automatisierte Pipeline, welche ein npm-preinstall-Skript ausführte, welches den Build-Cache vergiftete, welches Artefakte über Workflows hinweg kontaminierte. Jeder Schritt war einzeln autorisiert.¹¹

Der MCPTox-Benchmark demonstrierte es auf Agent-Ebene: Bösartige Anweisungen, eingebettet in Tool-Beschreibungen, leiten Agenten dazu um, Credentials mithilfe legitimer, bereits auf dem Server vorhandener Tools zu exfiltrieren. Der Agent führt das vergiftete Tool selbst nie aus. Er liest die vergiftete Beschreibung und nutzt seine eigenen autorisierten Tools, um den Angriff durchzuführen.¹²

Silent Egress demonstriert es auf Runtime-Ebene: Adversarielle Anweisungen in Metadaten von Webseiten verleiten einen Agenten dazu, Runtime-Kontext über eine ausgehende HTTP-Anfrage zu exfiltrieren, zu der der Agent autorisiert ist.¹³

Die Angriffsfläche ist keine einzelne verwundbare Komponente. Die Angriffsfläche ist die Komposition vertrauenswürdiger Komponenten. Einzelne Glieder zu sichern, sichert nicht die Kette. Trivy war nicht die Schwachstelle. LiteLLM war nicht die Schwachstelle. Die Schwachstelle war die Vertrauensbeziehung zwischen ihnen, vermittelt durch veränderliche Versions-Tags und nicht angepinnte Abhängigkeiten.

Was tatsächlich hilft

Die Verteidigungsmaßnahmen, die jede Stufe dieses Angriffs verhindert hätten, sind langweilig. Es sind auch jene, die die meisten Organisationen auslassen.

Pinnen Sie an unveränderliche Referenzen. LiteLLM installierte Trivy per apt ohne Versions-Pinning. Hätte security_scans.sh an eine bestimmte Version oder einen Commit-SHA angepinnt, wäre die vergiftete v0.69.4-Binary nie ausgeführt worden. GitHub Actions sollten Commit-SHAs referenzieren, nicht veränderliche Tags. Der Unterschied zwischen uses: aquasecurity/[email protected] (kompromittiert) und uses: aquasecurity/trivy-action@57a97c7 (sicher) ist der Unterschied zwischen dem Verlust Ihrer Publishing-Credentials und deren Erhalt.¹

Isolieren Sie Publishing-Credentials von CI-Runnern. Das PYPI_PUBLISH_PASSWORD war als Umgebungsvariable im GitHub Actions-Runner zugänglich, in dem Trivy lief. Wären Publishing-Credentials in einem separaten Workflow ohne Abhängigkeiten zu Drittanbieter-Actions isoliert gewesen, hätte die Trivy-Kompromittierung keinen PyPI-Zugriff ermöglicht. PyPIs Trusted Publishers (OIDC) eliminieren gespeicherte Tokens vollständig.⁵

Überwachen Sie ausgehende Netzwerkanfragen. Der Credential Stealer exfiltrierte Daten per HTTPS POST an models.litellm.cloud, eine 24 Stunden vor dem Angriff registrierte Domain. Egress-Monitoring, das Anfragen an neu registrierte Domains kennzeichnet, hätte dies erkannt. Mein eigenes Hook-System blockiert ausgehende Anfragen an Domains, die nicht auf einer Allowlist stehen, dasselbe Muster, das diese Exfiltration abgefangen hätte.¹⁴

Dieselbe Lektion habe ich in der Produktion auf die harte Tour gelernt. Ein vertrauenswürdiger Cloudflare-Cache-Purge-Pfad feuerte einen autorisierten API-Aufruf ab und produzierte dennoch das falsche Ergebnis, weil die umgebenden Guardrails zu locker waren. Dieser Fehler veranlasste mich, Freigaben für destruktive Aktionen und Preflight-Hooks um hochwirksame Operationen herum hinzuzufügen, nicht nur Domain-Allowlists.

Behandeln Sie pip install als Code-Ausführung. Eine .pth-Datei in site-packages/ wird bei jedem Python-Start ausgeführt. Es gibt kein Opt-out. Es gibt keine Sandbox. Wer pip install in einer CI-Umgebung mit Zugriff auf Credentials ausführt, gewährt jeder transitiven Abhängigkeit im Paket willkürliche Code-Ausführung. Die Minderung besteht darin, pip install in einer Umgebung ohne Credential-Zugriff auszuführen und dann die installierten Pakete in die Umgebung zu kopieren, die sie benötigt.

Verwenden Sie Lock-Dateien. Die Analyse von FutureSearch ergab, dass Downloads über uv (das Lock-Dateien verwendet) deutlich seltener die kompromittierte Version installierten als Downloads über pip (das auf die neueste Version auflöst). Lock-Dateien sind keine vollständige Verteidigung, aber sie verhindern die häufigste Exposition: eine nicht angepinnte >=-Versionseinschränkung, die stillschweigend auf ein kompromittiertes Release upgradet.⁴

Die unbequeme Implikation

Die TeamPCP-Kampagne zeigt, dass Supply-Chain-Sicherheit kein sekundäres Anliegen ist, das hinter Anwendungssicherheit, Netzwerksicherheit und Endpoint-Protection zurücksteht. Für Organisationen, die KI-Agenten mit Tool-Zugriff betreiben, ist die Lieferkette die primäre Angriffsfläche.

Ein KI-Agent, der pip install in einer CI-Umgebung aufruft, URLs abruft oder MCP-Server installiert, komponiert Vertrauensbeziehungen zur Laufzeit. Jede Operation ist autorisiert. Die Komposition möglicherweise nicht. Das Deploy-and-Defend-Paradox beschleunigt dies: Organisationen deployen Agenten schneller, als sie die Vertrauensketten auditieren, die diese Agenten komponieren.

Der Fork-Bomb-Bug in LiteLLM 1.82.8 war der einzige Grund, warum dieser Angriff schnell entdeckt wurde. Ohne diesen Implementierungsfehler hätte der Credential Stealer stillschweigend bei jedem Python-Aufruf auf jedem infizierten System gelaufen. 46.996 Installationen in 46 Minuten. 36 % der Cloud-Umgebungen. 2.337 Downstream-Pakete. Der Angreifer hat einen Fehler gemacht. Beim nächsten Mal vielleicht nicht.

Update — 31. März 2026: Ein anderer Vektor, dasselbe Ergebnis

Sechs Tage nach Veröffentlichung dieses Beitrags hatte npm seinen nächsten Vorfall. Am 31. März gab der axios-Maintainer Jason Saayman bekannt, dass sein persönlicher Computer durch eine gezielte Social-Engineering-Kampagne, gefolgt von Remote-Access-Trojan-Malware, kompromittiert worden war. Die Angreifer nutzten seine npm-Credentials, um axios 1.14.1 und 0.30.4 zu veröffentlichen, die beide eine neue Abhängigkeit namens [email protected] einschleusten, welche einen plattformübergreifenden RAT auf macOS, Windows und Linux installierte. Die bösartigen Versionen waren etwa drei Stunden lang live, bevor Community-Mitwirkende den Vorfall triagierten und npm sie entfernte.¹⁶

Der axios-Vektor unterschied sich von TeamPCP. Es gab keinen kompromittierten CI-Runner, keine aus einem Drittanbieter-Security-Scanner gestohlenen Credentials, keinen Multi-Ökosystem-Wurm. Die Kampagne gegen Saayman lief etwa zwei Wochen vor der Veröffentlichung, und die Kompromittierung lief über das persönliche Gerät des Maintainers direkt in die npm-Publishing-Pipeline. Die Behebung erforderte ein komplettes Löschen aller seiner Geräte und die Rotation jedes Credentials auf jeder Plattform, die er jemals genutzt hatte, sei sie persönlich oder anderweitig. Die C2-Infrastruktur war sfrclak[.]com auf 142.11.206.73:8000.¹⁶

Die strukturelle Lehre ist dieselbe. Die Vertrauenskette umfasst nun Aufmerksamkeit und Wachsamkeit des Maintainers als Glieder — einzeln autorisierte Operationen, die sich zu unautorisiertem Verhalten zusammensetzen, wenn ein Mensch in der Kette manipuliert wird. Die Minderungsmaßnahmen, die das axios-Team übernimmt (OIDC-Publishing, unveränderliche Releases, Geräte-Isolation)¹⁶, adressieren dieselbe Kompositionslücke, die Trivy-to-LiteLLM offenbarte: Publishing-Credentials werden dort gespeichert, wo sie von Angreifern erreicht werden können, die bereits etwas Angrenzendes kompromittiert haben.

Drei Stunden. 46 Minuten. Das sind die Zeitfenster, in denen moderne Supply-Chain-Angriffe heute operieren. Pinning und Lock-Dateien bleiben die primäre Verteidigung — axios-Nutzer, die außerhalb des 00:21-03:15 UTC-Fensters am 31. März frische Installationen hatten, waren nicht betroffen.¹⁶

FAQ

Wie prüfe ich, ob ich betroffen war?

Durchsuchen Sie Ihre CI-Logs und lokalen Umgebungen nach LiteLLM-Versionen 1.82.7 oder 1.82.8, die zwischen 10:39 und 11:25 UTC am 24. März 2026 installiert wurden. Falls eine der beiden Versionen installiert war, rotieren Sie alle Credentials, die auf diesem System als Umgebungsvariablen, SSH-Schlüssel oder Konfigurationsdateien zugänglich waren. Die offizielle Empfehlung von LiteLLM lautet, jedes System, auf dem die kompromittierten Versionen liefen, als vollständig kompromittiert zu behandeln.⁵

Welche Advisory-Kennung sollte ich verfolgen?

Verfolgen Sie PYSEC-2026-2 in OSV und der PyPA-Advisory-Datenbank. OSV führt den Vorfall zudem als Alias MAL-2026-2144. Stand 25. März 2026 listet die öffentliche OSV-Advisory-Seite keinen CVE-Alias für die bösartigen LiteLLM-Releases, daher sollten Incident-Response-Teams zunächst auf die betroffenen Versionen, das Installationsfenster und PYSEC-2026-2 abstellen.¹⁵

Waren Nutzer von LiteLLM Cloud oder des Docker-Proxys betroffen?

Nein. LiteLLM Cloud und das offizielle Docker-Proxy-Image pinnen Abhängigkeiten in der requirements.txt an und verhindern so die automatische Auflösung zu den kompromittierten Versionen. Nur Nutzer, die LiteLLM während des 46-minütigen Fensters per pip install litellm (ohne Pinning) installiert haben, waren betroffen.⁵

Was ist eine .pth-Datei und warum ist sie gefährlich?

Eine .pth-Datei ist eine Python-Funktion zur Konfiguration von Modulsuchpfaden. Jede Datei, die auf .pth endet und im Verzeichnis site-packages/ abgelegt wird, wird vom site.py-Modul von Python während der Interpreter-Initialisierung gelesen und ausgeführt. Dies geschieht vor jeder Import-Anweisung, vor jedem Anwendungscode und vor jeder Sandbox auf Python-Ebene. Der Mechanismus ist in der Python-Standardbibliothek dokumentiert, ist unter Anwendungsentwicklern jedoch nicht weit verbreitet bekannt. Es handelt sich um eine legitime Funktion, die als Angriffsvektor verwendet wird.³

Hängt dies mit dem Trivy-Supply-Chain-Angriff zusammen?

Ja. Die LiteLLM-Kompromittierung war eine direkte Folge der Trivy-Kompromittierung. TeamPCP kompromittierte Trivys GitHub Actions am 19. März und sammelte dabei CI/CD-Credentials von Organisationen ein, die Trivy in ihren Build-Pipelines einsetzten. Eines dieser Credentials war LiteLLMs PyPI-Publishing-Token. Der Angreifer nutzte dieses Token fünf Tage später, um die bösartigen LiteLLM-Versionen zu veröffentlichen.¹⁰

Was ist TeamPCP?

TeamPCP (auch als DeadCatx3, PCPcat, ShellForce, CipherForce verfolgt) ist eine Bedrohungsgruppe, die im März 2026 eine Multi-Ökosystem-Supply-Chain-Kampagne durchführte und dabei Pakete in GitHub Actions, Docker Hub, npm, Open VSX und PyPI kompromittierte. Die Gruppe setzte in etwa einer Woche in fünf Paket-Ökosystemen Credential-Harvesting, Tag-Hijacking und sich selbst verbreitende Wurm-Techniken ein.⁶

Wie hängt dies mit KI-Agent-Sicherheit zusammen?

KI-Agenten, die Pakete installieren, URLs abrufen oder sich mit MCP-Servern verbinden, komponieren Vertrauensbeziehungen zur Laufzeit. Jede Operation ist einzeln autorisiert. Die Komposition dieser Operationen kann unautorisiertes Verhalten erzeugen, wie Silent Egress (Agent-Ebene), Clinejection (CI/CD-Ebene) und dieser Angriff (Supply-Chain-Ebene) zeigen. Verhaltens-Monitoring zur Laufzeit, Domain-Allowlisting und Credential-Isolation adressieren die Kompositionslücke auf unterschiedlichen Schichten des Stacks.¹⁴

Quellen