Was sind agentenbasierte Schwachstellen in der Lieferkette?

Schwachstellen in der agentenbasierten Lieferkette entstehen, wenn in einer Anwendung verwendete Drittanbieter-Agenten, Tools, Modelle oder Schnittstellen bösartig sind, kompromittiert wurden oder während der Übertragung manipuliert wurden. Diese Abhängigkeiten können ausgenutzt werden, um unsicheren Code, versteckte Anweisungen oder irreführende Verhaltensweisen in die Ausführungskette des Agenten einzuschleusen.

Bei traditionellen Risiken in der Software-Lieferkette geht es um statische Abhängigkeiten, die zum Zeitpunkt der Erstellung festgelegt werden, wie in LLM03:2025 „Supply Chain Vulnerabilities“ ausführlich behandelt wird. Agentebasierte Systeme stellen jedoch häufig ihre Funktionen zur Laufzeit zusammen und laden dabei externe Tools und Agenten-Persönlichkeiten dynamisch während der Ausführung. Dadurch verlagert sich das Sicherheitsproblem vom Manifest auf den Zeitpunkt der Ausführung, wodurch sich die Angriffsfläche erheblich vergrößert.

Vorfälle dieser Art gab es bereits. Ein manipulierter Befehl wurde in der Amazon-Q-Erweiterung für VS Code, Version 1.84.0, eingebaut und erreichte Tausende von Installationen, bevor er entdeckt wurde. Ein Forscher demonstrierte denselben Mechanismus gegenüber dem MCP-Server von GitHub, indem er Befehle in den Metadaten eines Tools versteckte, sodass der Assistent private Repository-Daten ohne Wissen des Benutzers abgriff. Ein bösartiger MCP-Server auf npm gab sich als „postmark-mcp“ aus und leitete ausgehende E-Mails heimlich per BCC an den Angreifer weiter.

Warum es gefährlich ist

Eine kompromittierte Abhängigkeit kann es einer Bedrohung ermöglichen, über die Komponente hinauszuwandern, über die sie eingedrungen ist, und den daraus resultierenden Schaden zu verbreiten, beispielsweise:

• Eine schleichende Verfälschung, die durch ein manipuliertes Wissens-Plugin eines Drittanbieters verursacht wird, wobei ein Agent, der speziell manipulierte Einträge aus einem kompromittierten Indexer verarbeitet, letztendlich sensible Daten während einer ansonsten normalen Nutzung nach außen befördert.
• Falsche Werkzeug-Metadaten, die dazu führen, dass ein Agent versteckte oder bösartige Funktionen aufruft
• Gefälschte Tools und Dienste, die einen legitimen Namen so gut nachahmen, dass eine Verbindungsanfrage an einen Angreifer umgeleitet wird
• Umfassende, gleichzeitige Gefährdung, wenn eine kompromittierte Registrierungsdatenbank oder ein kompromittierter MCP-Server manipulierte Komponenten an alle Agenten verteilt, die diesen vertrauen

Typische Symptome

Diese Sicherheitslücke kann auf verschiedenen Laufzeitebenen auftreten:

• Automatisch aus einer externen Quelle abgerufene Vorlagen für Eingabeaufforderungen, die versteckte Anweisungen für die Mitarbeiter enthalten
• Einfügen von Tool-Deskriptoren, bei dem versteckte Nutzdaten in den Metadaten eines Tools oder auf der MCP-Karte als vertrauenswürdige Anweisungen interpretiert werden
• Tools und Agenten, bei denen es sich um Typosquatting-Seiten oder Fälschungen handelt und mit denen ein dynamischer Erkennungsprozess versehentlich eine Verbindung herstellt
• Drittanbieter-Agenten mit ungepatchten Sicherheitslücken, die in einen Multi-Agenten-Workflow eingebunden werden

In jedem Fall entsteht die Sicherheitslücke durch eine Komponente, deren Entwicklung oder Wartung außerhalb der direkten Kontrolle der Organisation liegt.

Sicherung der Lieferkette von Agentic

Herkunft, Isolierung und die Möglichkeit einer schnellen Abschaltung sind für Komponenten agentenbasierter Systeme noch entscheidender als in einer herkömmlichen Software-Lieferkette, da sie zur Laufzeit statt zur Erstellungszeit geladen werden.

• Manifeste, Prompts und Tool-Definitionen signieren und beglaubigen sowie SBOMs und KI-Stücklisten durch regelmäßige Beglaubigungen pflegen, wobei ausschließlich auf kuratierte, vertrauenswürdige Register zurückgegriffen wird
• Alle Abhängigkeiten auf die Whitelist setzen und festlegen, Registries wie PyPI und npm auf Pakete mit Typosquatting-Namen überprüfen und alles, was nicht signiert oder nicht verifiziert ist, automatisch ablehnen
• Führen Sie sensible Agenten in Sandbox-Containern mit strengen Einschränkungen hinsichtlich Netzwerkzugriff und Systemaufrufen aus und verlangen Sie reproduzierbare Builds.
• Stellen Sie Prompts, Orchestrierungsskripte und Speicherschemata unter Versionskontrolle mit Peer-Review und überprüfen Sie sie auf Anomalien
• Sicherstellung einer gegenseitigen Authentifizierung und Beglaubigung zwischen Agenten mittels PKI und mTLS, ohne offene Registrierung, wobei jede Nachricht zwischen den Agenten signiert und verifiziert wird
• Überprüfen Sie Signaturen, Hashes und SBOMs während der Laufzeit kontinuierlich erneut und überwachen Sie das Verhalten, die Nutzung von Berechtigungen und die Herkunft auf Anomalien.
• Pin-Aufforderungen, Tools und Konfigurationen anhand des Inhalts-Hashs und der Commit-ID festlegen und eine schrittweise Einführung mit automatischem Rollback bei Hash-Abweichungen vorschreiben
• Entwickeln Sie einen Mechanismus zur Notfall-Deaktivierung (d. h. einen „Kill-Switch“ für die Lieferkette), der ein bestimmtes Tool, eine bestimmte Eingabeaufforderung oder eine bestimmte Agent-Verbindung in allen Bereitstellungen sofort deaktiviert.
• Entwerfen Sie das System unter der Annahme, dass jedes LLM oder jede agentenbasierte Komponente irgendwann ausfallen oder ausgenutzt werden wird, und bauen Sie entsprechende Abwehrmaßnahmen ein.

Eine derart dynamische Lieferkette lässt sich im Voraus nicht vollständig überprüfen; daher können diese Kontrollmaßnahmen den Verantwortlichen helfen, eine kompromittierte Komponente schnell zu erkennen und deren Zugriffsmöglichkeiten einzuschränken.

< Zurück zu Glossar der Begriffe