Lieferkette von KI-Agenten: Was die Leitung wissen muss

Ihr Entwicklungsteam arbeitet mit Claude Code, Cursor oder Codex. Die Freigabe lief sauber: Werkzeug geprüft, Vertrag unterschrieben, Zugänge eingerichtet. Was dabei leicht übersehen wird: Ein KI-Agent bringt nicht nur sich selbst mit. Er holt sich während der Arbeit weitere Bausteine dazu, und diese stehen in keiner Freigabeliste.

Ein aktueller Beitrag auf CIO.com beschreibt das als agentische Lieferkette. Für die Geschäftsleitung ist das keine Detailfrage der IT-Sicherheit, sondern eine Frage der Kontrolle: Wissen Sie, womit die Software arbeitet, die in Ihrem Haus Code schreibt?

Was ein Agent alles mitbringt

Früher war Lieferkettenrisiko in der Softwareentwicklung überschaubar: Open-Source-Pakete, Build-Prozesse, gelegentlich ein gekapertes Entwicklerkonto. Ein Agent dagegen stellt seine Fähigkeiten zur Laufzeit zusammen. Er greift auf Modelle, Bibliotheken, Werkzeuge, Skills und Plugins zu, dazu auf MCP-Server, also Schnittstellen, über die ein Agent externe Werkzeuge und Datenquellen anspricht. Und er handelt auf Basis dessen, was er dort findet, in Maschinengeschwindigkeit und oft in vielen parallelen Abläufen.

Der Kern des Problems: Der Werkzeugkatalog eines Agenten kann sich am Tag nach der Freigabe ändern. Der Agent vertraut dann dem, was er beim nächsten Aufruf vorfindet. Die Organisation OWASP, die verbreitete Risikolisten für Software veröffentlicht, führt Schwachstellen in dieser Lieferkette inzwischen in ihrer Top-10-Liste für agentische Anwendungen.

Warum die bisherige Freigabe nicht greift

Die gängigen Kontrollen, etwa Abhängigkeits-Scans, Software-Stücklisten und Code-Reviews, wurden für Software gebaut, die sich nach der Auslieferung nicht mehr verändert. Werkzeuge, die ein Agent erst zur Laufzeit entdeckt und aufruft, sehen diese Verfahren nicht.

Zwei Mechanismen verdienen Ihre Aufmerksamkeit:

• Geerbtes Vertrauen. Verbindet sich ein Agent mit einem Werkzeug, übernimmt er dessen Kontext und Handlungsmöglichkeiten. Schon die Beschreibung eines Werkzeugs, also der Text, anhand dessen der Agent entscheidet, wann er es nutzt, kann eine versteckte Anweisung enthalten, der er folgt.
• Nachträgliche Änderung. Ein Werkzeug besteht die Prüfung und ändert sich danach. Fachleute sprechen von einem „Rug Pull“. OWASP empfiehlt, Werkzeuge und Konfigurationen auf einen festen Stand festzuschreiben und bei Abweichungen automatisch zurückzurollen.

Eine einmalige Prüfung sagt also wenig darüber, was ein Baustein ein halbes Jahr später tut.

Keine Theorie: Was bereits passiert ist

Der Beitrag nennt mehrere Vorfälle. Im September 2025 meldete Koi Security den nach eigener Aussage ersten schädlichen MCP-Server im Umlauf: eine Kopie eines legitimen Open-Source-Projekts, die jede versendete E-Mail heimlich in Blindkopie an eine Adresse des Angreifers schickte. Rund 1.500 Mal wurde das Paket heruntergeladen, bevor es entfernt wurde. Auf Systemen, die es bereits installiert hatten, blieb es trotzdem.

Im August 2026 vergiftete ein Wurm im npm-Umfeld, dem zentralen Paketverzeichnis für JavaScript, 1.684 Versionen unter 420 Paketnamen. Im Juli 2026 wurde zudem ein MCP-Werkzeug in nginx-ui bekannt, über das sich fremder Code auf dem Server ausführen ließ.

Besonders deutlich wird das Problem bei Marktplätzen. Eine Untersuchung des Skill-Marktplatzes OpenClaw fand 1.184 schädliche Skills, 677 davon stammten von einem einzigen Konto. Die Lehre daraus: Beliebtheit und gute Platzierung in einem Marktplatz sind kein Gütesiegel. Und sobald Agenten in großem Stil aus offenen Verzeichnissen nachladen, hat die Frage „Wer hat diesen Baustein freigegeben?“ keine eindeutige Antwort mehr.

Ein Prüfrahmen, den Sie übernehmen können

Die US-Behörde CISA und die australische ASD haben gemeinsame Hinweise zur Einführung agentischer KI veröffentlicht. Sie gliedern die Risiken in fünf Kategorien: Berechtigungen, Design und Konfiguration, Verhalten, Struktur und Verantwortlichkeit. Übersetzt in Fragen: Was darf der Baustein? Wie wurde er eingerichtet? Wie verhält er sich? Womit ist er verbunden? Und wer ist verantwortlich, wenn es schiefgeht?

Gerade die letzte Frage gehört auf den Tisch der Geschäftsleitung. Sie berührt die Verantwortung, die der Beitrag Risiken von Vibe Coding: Was die Leitung verantwortet beschreibt. Begriffe wie Agent oder MCP finden Sie im Glossar.

Was das für Ihre Entscheidung bedeutet

Chance: Erweiterungen machen Coding-Agenten deutlich nützlicher, weil sie auf Werkzeuge und Daten Ihres Hauses zugreifen können. Ein Verbot aller Erweiterungen verschenkt diesen Nutzen.

Risiko: Die Lieferkette endet bei Agenten nicht mit der Freigabe. Jedes Werkzeug, jeder Skill und jeder MCP-Server kann sich ändern, solange der Agent läuft. Wer nur das Hauptwerkzeug prüft, prüft einen kleinen Teil.

Nächster Schritt: Fragen Sie Ihre IT-Leitung, ob es eine Übersicht gibt, welche Erweiterungen Ihre Agenten tatsächlich nutzen. Klären Sie, wer neue Plugins oder Skills zulassen darf und ob dafür offene Marktplätze erlaubt sind. Und legen Sie fest, wer für das Verhalten eines Bausteins nach der Freigabe zuständig ist. Dass Agentenberichte allein dafür nicht reichen, zeigt der Beitrag Wenn KI-Agenten Fehler verschweigen.

Die agentische Lieferkette ist ein laufender Prozess, keine einmalige Abnahme. Das verlangt keine tiefe Technikkenntnis der Leitung, wohl aber klare Zuständigkeiten.

Sie wollen mit Ihrem Führungsteam klären, welche Bausteine Ihre KI-Agenten nutzen dürfen und wer dafür geradesteht? Melden Sie unverbindlich Ihr Interesse an oder fragen Sie ein Inhouse-Seminar an.