29.03.2026
Aktualisiert 27.07.2026
Threat
Agentic Supply Chain Vulnerabilities
Kompromittierte Plugins, Connectoren, MCP-Server oder Tool-Schemas können den vertrauenswürdigen Ausführungspfad eines KI-Agenten manipulieren.
Was Agentic Supply Chain Vulnerabilities sind
Agentic Supply Chain Vulnerabilities entstehen, wenn ein KI-Agent kompromittierten oder unzureichend geprüften Komponenten vertraut. Dazu gehören neben Packages und Modellen auch Plugins, Connectoren, MCP-Server, Tool-Schemas, OAuth-Integrationen und externe APIs.
Diese Bausteine liefern nicht nur Code. Sie definieren Fähigkeiten, beschreiben Tool-Aufrufe, transportieren Kontext und erhalten Zugriffsrechte. Eine manipulierte Komponente kann daher Planung und reale Aktionen beeinflussen, ohne den Agenten selbst zu verändern.
Wie der Angriff funktioniert
Der Angriff kann bereits beim Build beginnen oder erst zur Laufzeit über einen entfernten Dienst entstehen. Entscheidend ist der Übergang von ungeprüfter Komponente zu autorisiertem Tool-Aufruf.
Integration
Ein Agent erhält eine neue Abhängigkeit
Manipulation
Update, Schema oder Dienst wird verändert
Vertrauen
Der Agent übernimmt Beschreibung und Output
Tool-Aufruf
Legitime Rechte erzeugen reale Wirkung
Mögliche Folgen
Daten fließen an Fremdsysteme
OAuth-Rechte werden missbraucht
Code wird unerwartet ausgeführt
Wie groß der Schaden wird, bestimmen vor allem die geerbten Identitäten, Scopes und Egress-Wege. Deshalb überschneidet sich dieses Risiko häufig mit Identity & Privilege Abuse und Tool Misuse.
Klassische oder agentische Supply Chain?
Klassisch
Software Supply Chain
Eine kompromittierte Abhängigkeit verändert Build-Artefakte oder ausgeführten Code.
Integrität von Source, Build und Artefakt steht im Zentrum
Wirkung folgt meist der installierten Version
Agentisch
Runtime Supply Chain
Auch entfernte Tools, Schemas und Outputs verändern Fähigkeiten und Entscheidungen.
Vertrauen kann sich ohne Deployment verändern
Tool-Rechte und natürliche Sprache vergrößern die Wirkung
Agentische Lieferketten enthalten die klassische Software-Lieferkette, reichen aber bis zu dynamischen Integrationen, Berechtigungen und Tool-Outputs im laufenden Betrieb.
Drei typische Angriffsszenarien
Ein Server verändert sein Tool-Schema
MCPEin zuvor geprüftes Tool erhält neue Parameter oder Ziele. Der Agent sendet sensible Daten an einen fremden Endpunkt.
Ein manipuliertes Update gelangt in den Build
PackageTyposquatting, ein kompromittierter Maintainer oder eine unsichere Registry bringt schädlichen Code in den Agenten-Host.
Eine Integration fordert zu breite Rechte
ConnectorEin scheinbar legitimer Connector nutzt OAuth-Scopes, die weit über den sichtbaren Workflow hinausreichen.
Was wirklich schützt
Einmalige Anbieterprüfungen reichen nicht. Teams müssen Herkunft und Versionen beim Bezug sichern, Komponenten zur Laufzeit begrenzen und Änderungen im Verhalten sichtbar machen.
Nur freigegebene Registries und Dienste nutzen, Versionen pinnen, Signaturen prüfen und Komponenten samt Tool-Schemas inventarisieren.
Eigene Identitäten, kurze Token-Laufzeiten, minimale Scopes sowie kontrollierte Daten- und Egress-Ziele pro Connector erzwingen.
Schema-Diffs, neue Ziele und ungewöhnliche Tool-Sequenzen erkennen; riskante Aufrufe isolieren oder zur Freigabe stoppen.
Eine kompromittierte Komponente darf weder unbemerkt neue Fähigkeiten erhalten noch mit geerbten Rechten auf beliebige Systeme wirken.
Ergänzend schützen Context-Aware Authentication, Secrets Management und AI Sandboxing die Grenzen zwischen Agent, Integration und Zielsystem.
Wie Teams Lieferkettenrisiken erkennen und testen
- Integrität vergleichen: Versionen, Hashes, Signaturen, SBOM und Tool-Schemas gegen den freigegebenen Stand prüfen.
- Scope-Drift alarmieren: Neue OAuth-Rechte, Ziele oder Schreibfähigkeiten als relevante Änderung behandeln.
- Build und Runtime korrelieren: Komponentenversion, Agentenlauf, Tool-Aufruf und Egress-Ziel in einem Trace verbinden.
- Kompromittierung simulieren: Manipulierte Updates, Schema-Änderungen und ausfallende Remote-Dienste gegen Isolation und Stop-Regeln testen.
Einzelne Kompromittierungsindikatoren genügen selten. Aussagekräftig wird die Erkennung durch die gemeinsame Sicht auf Provenienz, Berechtigungen und Laufzeitverhalten; dafür ist Agent Observability zentral.