Cyber-Kriminalität
Bedrohungen für die Architektur agentenbasierter KI
Agentenbasierte KI-Systeme bauen auf komplexen, mehrschichtigen Architekturen auf, wobei jede Schicht spezifische Risiken birgt. Da die Komponenten miteinander verbunden sind. Können Bedrohungen an jeder Stelle auftreten.
Save to Folio
Um die Sicherheit agentenbasierter KI-Systeme zu verstehen, muss der Aufbau ihrer mehrschichtigen Architektur analysiert und die spezifischen Risiken jeder Schicht identifiziert werden. Da diese Schichten miteinander verbunden sind, können Sicherheitsrisiken an jeder Stelle auftreten und sich potenziell im gesamten System in jeder Schicht ausbreiten:
Datenebene
Hier sind Bedrohungen möglich, die Datenspeicher, Trainingssätze und Modelle kompromittieren. Angreifer könnten diese Komponenten manipulieren, um die Anwendungslogik des agentenbasierten Systems zu verändern, oder sie nutzen, um sensible Daten zu stehlen, die das System möglicherweise zurückhält.
Vergiftung von Datenspeichern: Ein Angreifer manipuliert die Daten in den Datenspeichern des agentenbasierten Systems, etwa als Folge eines im Internet exponierten Service oder einer Fehlkonfiguration. Betrifft die Manipulation den Langzeitspeicher, kann sie das Verhalten der Anwendung grundlegend verändern. Es geht ums Ändern von Konfigurationseinstellungen zur Schwächung von Sicherheitsprotokollen, das Einfügen von bösartigem Code, der innerhalb der Anwendung ausgeführt wird, oder das Verfälschen von Daten. Die Manipulation des Kurzzeitspeichers hingegen hat unmittelbare und direkte Auswirkungen auf die Sitzung eines Nutzers. Durch die Veränderung von Sitzungsdaten kann ein Angreifer das Konto eines Nutzers übernehmen, sich als dieser ausgeben, Transaktionen manipulieren oder während der Sitzung sensible Informationen extrahieren.
Vergiftung des Trainingssatzes: Durch das Einfügen irreführender Informationen in diese Datensätze kann ein Angreifer das Lernen und Verhalten des KI-Modells subtil beeinflussen. Da KI-Modelle lernen, Entscheidungen auf der Grundlage der Trainingsdaten zu treffen, kann die Einführung von Ungenauigkeiten zu fehlerhaften Entscheidungen führen.
Inferenzangriff: Trainingsdaten können proprietäre Informationen enthalten zum Unternehmen, Ein Angreifer, dem es gelingt, solche Sets zu stehlen oder deren Inhalt durch einen Inferenzangriff zu ermitteln, könnte Zugriff auf proprietäre und intellektuelle Daten erhalten. Dafür fragt er das Modell mit sorgfältig ausgearbeiteten Eingabedaten ab, um seinen Output oder sein Verhalten auf der Grundlage verschiedener Eingaben herauszufinden. Daraus lassen sich Rückschlüsse auf die Eigenschaften der Trainingsdaten des Modells ziehen. Wenn beispielsweise eine bestimmte Eingabeänderung die Ausgabe konsistent und vorhersehbar verändert, lassen sich bestimmte Merkmale der Daten ableiten, mit denen das Modell trainiert wurde.
Modell- und Datenexfiltration: In einem solchen Fall stiehlt ein Akteur das resultierende Modell, das anhand dieser Daten entwickelt wurde, und kann es wiederverwenden, bis hin zum Betrieb einer ähnlichen agentenbasierten Bereitstellung. Angreifer können auch den Langzeit- und Kurzzeitspeicher ins Visier nehmen, um Daten zu exfiltrieren und weitere Informationen über eine laufende Anwendung zu sammeln. Der Diebstahl eines Modells macht nicht nur die technischen Abläufe der KI-Systeme eines Unternehmens zugänglich, sondern ermöglicht es dem Angreifer auch, die Services oder Produkte des Unternehmens potenziell zu replizieren. Wenn das Modell darüber hinaus einzigartige Algorithmen oder proprietäre Daten enthält, kann seine unbefugte Nutzung rechtliche und regulatorische Konsequenzen nach sich ziehen.
Modellunterwanderung: Bei Systemen, die auf externen Modellen basieren, etwa von Plattformen wie Hugging Face, besteht die Gefahr von Supply Chain-Angriffen. Bei diesen Angriffen ersetzt ein Angreifer das ursprüngliche (beabsichtigte) Modell durch seine eigene bösartige Version und manipuliert so die allgemeine Logik der Zielanwendung zu seinem Vorteil. Wenn das kompromittierte Modell beispielsweise in kritischen Entscheidungsprozessen wie Finanzprognosen oder der Analyse personenbezogener Daten verwendet wird, könnte der Angreifer die Ergebnisse zu seinen Gunsten verfälschen oder erhebliche Betriebsstörungen verursachen. Darüber hinaus werden die Integrität und Zuverlässigkeit der Anwendung beeinträchtigt.
Orchestrierungsebene
Hier zielen Angriffe auf ihre Kernfunktionen ab: die Ressourcenzuweisung und die Ausführungsplanung. Sie nutzen in der Regel Schwachstellen in der Reasoning Engine – wenn diese auf einem großen Modell basiert – oder im Speicher, wenn dieser im Internet exponiert wurde.
Missbrauch rekursiver Agentenaufrufe: Ein Schlüsselelement eines agentenbasierten Workflows ist seine Beendigungsbedingung, d. h. wenn die Ausführung zufriedenstellende Bedingungen erfüllt, sollte die Verarbeitung beendet werden. Dies wird in der Regel durch die Parameter des Planungsmanagers und die jeweilige Aufgabe festgelegt und ist einer der definierenden Parameter eines agentenbasierten Workflows. Werden diese manipuliert, entweder durch indirekte Prompt-Injection oder durch Vergiftung des Anwendungsdatenspeichers, kommt es zu Fehlverhalten der Anwendung.
Unterwanderung des Ziels: Ein agentenbasiertes System setzt Agenten ein, um ein Ziel zu erreichen, das die Reasoning Engine durch Analyse der vom Planungsmanager empfangenen Nutzeraufforderung ableitet. Ein Angreifer kann über einen der Agenten eine indirekte Prompt-Injection in der Reasoning Engine durchführen und einen bösartigen Prompt einfügen, der den Planungsmanager auffordert, das Ziel zu ändern. Auch kann der exponierte Speicher gekapert werden, um die Sitzungsdaten und das Ziel zu ändern, ohne auf eine Prompt-Injection zurückgreifen zu müssen.
Unterwanderung des Zustandsgraphen: Der Planungsmanager überwacht den aktuellen Arbeitszustand der Anwendung und plant die nächsten Ausführungsschritte. Je nach Implementierung kann der Zustandsgraph von einem fest codierten Workflow – implementiert in Frameworks wie LangGraph – bis zu einem dynamischen Graph reichen, der in Echtzeit von der Reasoning Engine generiert wird, wobei der aktuelle Ausführungszustand im Kurzzeitspeicher abgelegt wird.
Im Falle eines fest codierten Workflows könnte ein Angreifer mit Zugriff auf den Systemcode und die Bibliotheken eine Schwachstelle wie CVE-2025-3248 ausnutzen, um einen Teil des Ausführungsgraphen zu manipulieren – beispielsweise durch Ersetzen eines laufenden Teilgraphen durch einen bösartigen (Subgraph Impersonation). Ist der Kurzzeitspeicher exponiert, könnte ein Angreifer die Sitzungsdaten – einschließlich des aktuellen Ausführungsstatus – verändern, um unerwartete Verhaltensweisen auszulösen (Orchestration Poisoning). Im Falle eines dynamischen Graphen veranlasst eine sorgfältig ausgearbeitete Prompt-Injection den LLM unbemerkt die Veränderung des Ausführungsstatus in Richtung eines böswilligen Ziels (Flow Disruption).
Agentenschicht
Sie sind besonders anfällig für verschiedene Formen von Supply Chain-Angriffen.
Tool-Subversion:
Agenten interagieren über Tools mit der externen Umgebung (z. B. einer Website). Die Tool-Subversion ist ein Angriff, bei dem das erwartete Verhalten eines Tools verändert wird. Je nach Tool-Typ lassen sich mehrere Möglichkeiten identifizieren, um diesen Angriff durchzuführen.
Bei externen Tools besteht der Angriff darin, den Agenten dazu zu verleiten, das falsche Tool für die Aufgabe auszuwählen, indem entweder ein Auswahlfehler provoziert oder das bösartige Tool dem Agenten als vorteilhafter dargestellt wird. Wenn wir davon ausgehen, dass ein Tool-Repository vorhanden ist, könnte der Angreifer ein bösartiges Tool innerhalb des Repositories bewerben und den Agenten durch Social Engineering dazu bringen, dieses auszuwählen.
Eine weitere Möglichkeit wäre, die API zu kapern, die zum Abrufen des externen Tools verwendet wird – beispielsweise durch einen DNS-Angriff auf die von der API verwendete Internetdomäne. Dieser Angriff, Tool-Hijacking, ähnelt stark den Supply-Chain-Angriffen Software-Bibliotheks-Repositorys wie PyPy und npm.
Während ein richtiger Tool-Verwirrungsangriff noch aussteht – da heutige agentenbasierte KI-Systeme noch nicht vollständig autonom sind, was das Entdecken und Auswählen von Tools angeht –, könnten wir bald Varianten von Tool-Hijacking-Angriffen mit bösartigen MCP-Servern sehen. Angesichts der schnell wachsenden Verfügbarkeit von Open-Source MCP-Servern könnte ein Entwickler unachtsam einen MCP-Server für sein eigenes System bereitstellen und später feststellen, dass dieser bösartige Verhaltensweisen gegenüber der agentenbasierten Anwendung aufweist.
Selbst bei eingebetteten Tools, die keine externen Anfragen erfordern, kann es zu Subversion kommen. In diesem Fall kann eine sorgfältig ausgearbeitete Prompt-Injection den Agenten dazu verleiten, bösartigen Code zu generieren und auszuführen.
Agent-Subversion und verwandte Angriffe
Dieser Angriff besteht darin, das Verhalten eines Agenten zu verändern, entweder durch Unterwanderung des Agenten selbst oder durch vollständigen Ersatz des Agenten.
Agenten, die für ihre Arbeit auf LLMs angewiesen sind, können indirekten Prompt-Injection ausgesetzt sein, die von böswillig gestalteten Eingaben oder externen Quellen stammen können. Für LLMs kann es schwierig sein, zu unterscheiden, welche Teile der Eingabe die eigentliche Abfrage darstellen und welche Teile gekaperte Informationen sind. Infolgedessen könnten zusätzliche Anweisungen in der Textquelle versteckt sein.
In anderen Szenarien kann der Angreifer den Planungsmanager dazu verleiten, den falschen Agenten für eine bestimmte Aufgabe auszuwählen, indem er beispielsweise bösartige Agenten in das Agenten-Repository einführt, die wünschenswertere Fähigkeiten zugänglich gemacht haben. Eine weitere Möglichkeit besteht darin, eine bekannte Version eines Agenten durch eine bösartige zu ersetzen - „Agent Hijacking”.
Agentenübergreifende Informationsvergiftung
Je nach dem vom Planungsmanager definierten Workflow können Agenten direkt miteinander kommunizieren, um eine Aufgabe zu erfüllen, ohne dass dies von der Orchestrierungsebene überwacht wird, ein zusätzliches Risiko.
Ein kompromittierter Agent könnte manipuliert werden, um vergiftete Informationen einzuschleusen, die auf einen anderen Agenten abzielen, mit dem er kommuniziert, wodurch ein kaskadierender, indirekter Prompt-Injection-Angriff entsteht. Während die Durchführung eines solchen Angriffs in der Regel fundierte Kenntnisse der agentenbasierten Anwendung erfordert, ist für die Erkennung einer solchen Bedrohung eine gründliche Überprüfung aller zwischen den Agenten ausgetauschten Nachrichten erforderlich.
Angriff auf das KI-Modell des Agenten
Eine letzte Bedrohung für diese Schicht besteht in Angriffen auf das vom Agenten verwendete KI-Modell. Jeder Agent, der zur Verarbeitung unstrukturierter Texte – sei es Webinhalte oder Ergebnisse aus einem externen Datenspeicher – auf ein LLM angewiesen ist, wird möglichen indirekten Prompt-Injection-Angriffen zugänglich gemacht, die sein Verhalten verändern oder Daten aus dem System exfiltrieren können.
Es ist wichtig zu beachten, dass nicht alle KI-Modelle Sprachmodelle sind und nicht alle Agenten ein LLM verwenden. Es kann Objekterkennungsagenten geben, die für die Identifizierung bestimmter Elemente in einem Video-Feed verantwortlich sind, wie z. B. Hindernisse in Auto, Personen in Unternehmensüberwachungssystemen oder fehlerhafte Sample in Produktionsüberwachungssystemen. In diese Modelle ließen sich Straßenmarkierungen einführen, um die Fähigkeit der Straße zu folgen, zu stören, oder mithilfe von Make-up die Gesichtserkennungssysteme umgehen werden.
Systemebene
Da agentenbasierte Anwendungen nach wie vor reguläre Softwarekomponenten benötigen, um kanonische Funktionen zu gewährleisten, gelten auch hier klassische Angriffe.
Fehlkonfiguration
Fehlkonfigurationen können zu unbefugtem Zugriff auf sensible Informationen, kompromittierten Softwarekomponenten oder Service-Unterbrechungen führen. Darüber hinaus könnten sie Angreifern auch einen Zugang zu anderen Schichten verschaffen.
Software-Schwachstellen
Da die Systemschicht ebenso wie andere Schichten aus mehreren komplexen Softwarekomponenten bestehen kann, die aus verschiedenen Quellen installiert wurden, stellen Schwachstellen eine erhebliche Bedrohung für die gesamte Anwendung dar. Dazu gehören auch Supply-Chain-Angriffe, die auf Bibliotheken von Drittanbietern abzielen.
Schwache Authentifizierung
Eine schwache oder gar fehlende Authentifizierung erleichtert es einem Angreifer, Zugriff auf interne Komponenten zu erhalten, auf Systemprotokolle zuzugreifen und Berechtigungen zu erweitern. Je nach den erlangten Systemberechtigungen kann ein Angreifer sogar Daten verändern, modifizierte Software installieren oder die gesamte agentenbasierte Anwendung herunterfahren.
DoS
Wie alle anderen im Internet gehosteten Services sind auch agentenbasierte Anwendungen und ihre Schichten, einschließlich der Systemschichten, anfällig für verteilte DoS-Angriffe (DDoS).
Exponierte APIs
Darüber können Angreifern auf vertrauliche Informationen zugreifen oder DoS-Attacken starten, bösartigen Code einschleusen und sensible Daten abrufen. Diese Schwachstelle gefährdet nicht nur die Sicherheit der Anwendung, sondern stellt auch ein erhebliches Risiko für die Datenintegrität und Systemstabilität dar.
Expositionsmatrix
Um diese Bedrohungen besser kategorisieren zu können, haben wir im Originalbeitrag eine strukturierte Übersicht über die Voraussetzungen für die verschiedenen Arten von Angriffen erstellt.
Die Expositionsmatrix zeigt, ob ein Angriff von einem externen Akteur durchgeführt werden kann oder ob dafür die Kontrolle über eine bestimmte Komponente, alle Komponenten innerhalb einer bestimmten Schicht oder sogar eine andere Schicht in der Systemarchitektur erforderlich ist. Durch die Untersuchung dieser Bedingungen lässt sich ermitteln, welche Sicherheitsgrenzen für die Abwehr bestimmter Bedrohungen am wichtigsten sind.
Einige der kritischsten Angriffe erfolgen, wenn eine exponierte Infrastrukturkomponente, wie z. B. Langzeit- und Kurzzeitspeicher, ein ungeschützter UI-Endpunkt oder ein zugängliches Modell, nicht ordnungsgemäß gesichert ist. Angriffe auf die Supply Chain stellen eine weitere erhebliche Bedrohung für alle Schichten des Systems dar. Dies ist besonders problematisch, da Anwendungsentwickler oft keine direkte Kontrolle über Bibliotheken von Drittanbietern, Tool-Repositorys oder externe Modelle haben.
Empfehlungen
Wir können zwei Arten von Empfehlungen aussprechen: Beachten von Designprinzipien und Ad-hoc-Sicherheitslösungen.
Designprinzipien
- Komponentenhärtung: Jede Schlüsselkomponente muss einzeln gehärtet und geschützt werden, sowie geeignete Kontrollen aufgesetzt werden, um die Integrität der Daten aus Komponenten von Drittanbietern außerhalb der Kontrolle des Unternehmens sicherzustellen.
- Isolierung von Schichten und Komponenten: Mit zunehmender Komplexität der Technologie ist es wichtig, eine angemessene Isolierung zwischen den verschiedenen Schichten und Komponenten aufrechtzuerhalten und die Interaktion zwischen ihnen auf klar definierte Bereiche zu beschränken.
- Sichere Komponentenkommunikation: Auch die Komponentenkommunikation muss gesichert sein, vor allem bei agentenbasierten Anwendungen mit großen Sprachmodellen, um vor Prompt-Injection-Angriffen zu schützen. Die Validierung der Kommunikation zwischen Komponenten, die Prompts für Agenten oder den Orchestrator weitergeben, wird in Zukunft immer wichtiger werden.
Ad-hoc-Sicherheitslösungen
Obwohl viele Sicherheitsherausforderungen einzigartig für agentenbasierte Architekturen sind – und mit der Weiterentwicklung agentenbasierter KI-Systeme voraussichtlich noch zunehmen werden –, ist die Implementierung robuster Sicherheitskontrollen auf allen Ebenen des Ökosystems unerlässlich.
Trend Micro schützt jede dieser Ebenen, vom Orchestrator über die Agenten bis hin zu Daten- und Systemkomponenten, und gewährleistet so den Schutz des gesamten agentenbasierten Stacks.