KI-Agent-Bedrohungsmodell: 7 Angriffsklassen + Verteidigungen

Multi-Agent-LLM-Systeme sind aus Sicherheitsperspektive nicht einfach „LLM plus Tools". Die Orchestrierungsschicht führt Angriffsflächen ein, die Single-LLM-Anwendungen nicht haben. Nach 18 Monaten Entwicklung von Agent-Systemen für Security-Tooling und parallelem Red-Teaming derselben Muster aus Angreifersicht habe ich mich auf ein 7-Klassen-Bedrohungsmodell festgelegt, das sauber auf die Kontrollen abbildet, die eine regulierte Umgebung benötigt. Dieser Beitrag dokumentiert das Modell, die Verteidigungen, das Observability-Minimum und das Compliance-Mapping.

Die Absicht ist nicht, vom Agent-Deployment abzuraten. Agenten sind echt nützlich, und die Security-Community braucht ein praktisches Bedrohungsmodell, das sicheren Einsatz erlaubt — keine Liste von Gründen, nicht zu deployen. Das Modell hier ist meinungsstark — es priorisiert Auditierbarkeit und Human-in-the-Loop-Disziplin gegenüber vollautonomem Verhalten. Diese Wahl ist bewusst. Autonome Agenten in einer regulierten Umgebung ohne Audit-Trail sind aktuell gegenüber einem Auditor nicht verteidigbar.

Warum Agent-Systeme sich von LLM-Anwendungen unterscheiden

Eine Single-LLM-Anwendung hat eine Vertrauensgrenze: zwischen Benutzer und Modell. Inputs überqueren diese Grenze; Outputs überqueren sie zurück. Prompt Injection, Jailbreaks und Datenexfiltration sind an dieser einen Grenze gut untersucht.

Ein Multi-Agent-System hat mehrere Vertrauensgrenzen. Benutzer zu Orchestrator, Orchestrator zu Worker-Agenten, Worker-Agenten zu Tools, Agenten zu Memory, Agenten zu anderen Agenten. Jede Grenze ist ein Ort, an dem ein Angreifer Inhalt einschleusen, Zustand beobachten oder eskalieren kann. Die Orchestrierungsschicht (oft ein eigenes Python- oder TypeScript-Framework, ein MCP-Server oder eine Workflow-Engine) ist selbst Teil der Vertrauensoberfläche.

Drei architektonische Eigenschaften von Agent-Systemen machen sie wesentlich anders als Single-LLM-Anwendungen: gemeinsamer Speicher über Turns hinweg, Tool-Aufrufe mit Seiteneffekten und Inter-Agent-Kommunikation, die der ursprüngliche Benutzer möglicherweise nie sieht. Diese Eigenschaften ermöglichen nützliches Verhalten; sie ermöglichen auch die folgenden sieben Angriffsklassen.

Die 7 Angriffsklassen

1. Cross-Agent Prompt Injection

Ein Worker-Agent verarbeitet ein Dokument, eine Webseite oder einen Tool-Output, das/die adversariale Anweisungen enthält. Der Worker-Agent emittiert eine Nachricht an den Orchestrator, die diese Anweisungen wörtlich enthält. Der Orchestrator, der den Output des Workers als vertrauenswürdigen Kontext liest, führt die Anweisungen auf einem nachgelagerten Agenten mit weiterreichenden Privilegien aus.

Verteidigung: Alle Inter-Agent-Nachrichten als nicht vertrauenswürdigen Input behandeln, bis sie eine explizite Validierungsschicht passieren. Anweisungs­förmigen Inhalt vor dem Weiterreichen an den nächsten Agenten strippen oder escapen. Strukturierte Nachrichten-Schemata (JSON mit typisierten Feldern) statt freier Textübergabe.

Detection: Jede Inter-Agent-Nachricht loggen und einen leichtgewichtigen Klassifikator für anweisungs­förmigen Inhalt laufen lassen (Imperativ-Verben, Rollen-Präfix-Muster, System-Prompt-Stil-Formulierungen). Bei Anomalie-Score alarmieren.

2. Tool Misuse

Ein Agent hat Zugriff auf ein Tool mit weiterreichender Fähigkeit als die aktuelle Aufgabe erfordert. Ein adversarialer Input überzeugt den Agenten, das Tool mit Argumenten aufzurufen, die den Input syntaktisch erfüllen, aber den beabsichtigten Einsatz überschreiten. Beispiele: ein Datenbank-Read-Tool, mit einer Query genutzt, die die gesamte User-Tabelle exfiltriert; ein Filesystem-Tool, mit dem Konfigurationsdateien außerhalb des Arbeitsverzeichnisses gelesen werden; ein HTTP-Client, der interne Admin-Endpunkte aufruft.

Verteidigung: Tool-Argument-Validierung auf Tool-Ebene, nicht auf Agent-Ebene. Der Agent schlägt vor; der Tool-Wrapper validiert und lehnt ab. Argument-Allow-Lists sind stärker als Deny-Lists für Hochrisiko-Tools. Tools, die destruktive Aktionen ausführen (löschen, schreiben, senden, ausführen), erfordern einen expliziten Bestätigungsschritt — auch um den Preis von Latenz.

Detection: Tool-Call-Audit-Log mit Eingabeargumenten, Output-Snippet, Agent-Identität und Zeitstempel. Alarme bei Tool-Aufrufen, deren Argumente von der statistischen Norm dieses Tools abweichen.

3. Memory Poisoning

Lang laufende Agent-Systeme halten Zustand über Sessions hinweg in Vektor-Stores, Dokumenten-Indexen oder Scratchpad-Memory. Ein Angreifer, der adversarialen Inhalt in dieses Memory bekommt, persistiert seinen Angriff über zukünftige Sessions hinweg — einschließlich Sessions anderer Benutzer. Der vergiftete Memory-Eintrag wird als legitimer Kontext abgerufen und beeinflusst zukünftiges Verhalten.

Verteidigung: Per-User-Memory-Isolation per Default. Cross-User-Memory nur mit expliziter Provenienz-Tagging und Admin-Freigabe. Sanitisierung jedes externen Inhalts vor Eintritt in das Memory: HTML strippen, anweisungs­förmige Formulierungen escapen, Quelle attribuieren.

Detection: Memory-Einträge tragen Quellen-Attribution (Benutzer, Session, Dokument-URI, Ingestion-Zeitstempel). Anomalie-Detection auf Retrieval-Mustern — ein Eintrag, der für viele Benutzer abgerufen wird, aber aus einer einzigen Session stammt, ist verdächtig.

4. Goal Hijacking

Ein adversarialer Input lenkt das Ziel des Agenten von der vom Benutzer formulierten Aufgabe zu einer vom Angreifer formulierten Aufgabe um. Unterscheidet sich von Prompt Injection, weil der Angriff nicht zwingend neue Anweisungen einschleust; er kann die bestehende Aufgabe einfach umrahmen. Ein Customer-Service-Agent, ursprünglich beauftragt, „dem Benutzer mit seinem Konto zu helfen", könnte umgerahmt werden zu „dem Benutzer beim Identifizieren von Schwächen in unserer Erstattungsrichtlinie zu helfen".

Verteidigung: Das Ziel des Agenten ist im System-Prompt kodiert, nicht aus User-Input abgeleitet. User-Input wird als Daten behandelt, mit denen der Agent operiert — nicht als Revision des Ziels. Goal-Anchoring-Techniken (Wieder­holung des Ziels in jedem Turn) reduzieren Drift.

Detection: Pro-Turn-Goal-Consistency-Check. Ein kleines Hilfsmodell erhält den aktuellen Turn und das ursprüngliche Ziel und emittiert einen Ähnlichkeits-Score. Drift unterhalb des Schwellwerts pausiert den Agenten und eskaliert an einen Menschen.

5. Privilege Escalation

Ein Agent mit beschränktem Tool-Zugriff kommuniziert mit einem Agenten, der weiterreichenden Zugriff hat (oft der Orchestrator oder ein spezialisierter privilegierter Worker). Der niedriger privilegierte Agent gestaltet Nachrichten so, dass der höher privilegierte Agent Aktionen außerhalb des ursprünglichen Scopes ausführt. Häufig in „Manager"-Orchestrierungs­mustern, in denen der Manager an Worker delegiert und worker-zurückgegebenen Plänen vertraut.

Verteidigung: Least-Privilege-Tool-Grants pro Agent. Privilegierte Agenten akzeptieren keine Pläne von weniger privilegierten Agenten ohne Re-Validierung gegen die ursprüngliche Benutzerintention. Privilegien­grenzen werden auf der Tool-Wrapper-Schicht durchgesetzt, nicht auf der Agent-Schicht (weil die Agent-Schicht prompt­steuerbar und somit keine Vertrauensgrenze ist).

Detection: Tool-Call-Provenienz-Trail, der zeigt, welcher Agent die Anfrage initiiert hat und welcher Agent letztlich das Tool aufgerufen hat. Diskrepanz zwischen beiden indiziert mögliche Eskalation.

6. Agent Collusion

Zwei oder mehr Agenten kombinieren Outputs auf eine Weise, die eine Beschränkung verletzt, die jeder einzeln respektiert. Ein Agent mit Berechtigung, sensible Daten zu lesen, emittiert eine Zusammenfassung; ein anderer Agent mit Berechtigung, öffentlichen Output zu schreiben, ingestiert die Zusammenfassung und veröffentlicht sie. Keiner der Agenten verletzte seine individuelle Policy; die Policy-Grenze lag auf der Orchestrierungsschicht und wurde nicht durchgesetzt.

Verteidigung: Datenfluss-Labeling. Outputs von Agenten, die sensible Daten verarbeitet haben, tragen ein Sensitivitäts-Tag. Die Output-Senke (Speicher, öffentliche Veröffentlichung, externe API) prüft das Tag, bevor sie die Daten akzeptiert. Das ist Informations­fluss-Steuerung, angewandt auf Agent-Outputs.

Detection: Tag-Verletzungs-Audit an Output-Senken. Jedes Entfernen oder Verändern eines Sensitivitäts-Tags zwischen Agenten wird geloggt und überprüft.

7. Datenexfiltration

Der klassische Exfiltrations-Angriff aus Single-LLM-Anwendungen, in Agent-Systemen verstärkt durch die größeren Kontextfenster, die Agenten akkumulieren. Ein adversariales Dokument weist den Agenten an, einen sensiblen Wert (einen API-Key, einen Kundendatensatz) in ein Tool-Argument zu kodieren, das die Vertrauensgrenze verlässt — eine HTTP-Anfrage an eine angreifer­kontrollierte URL, eine Suchanfrage, eine ausgehende E-Mail.

Verteidigung: Egress-Filterung am Tool-Wrapper. Ausgehende HTTP-Anfragen müssen einer Allow-List von Domains entsprechen. Ausgehende E-Mails müssen einer Allow-List von Empfängern entsprechen oder zur menschlichen Genehmigung in eine Queue. Sensible Werte im Agent-Kontext werden bei Ingestion getaggt, und der Tool-Wrapper lehnt Aufrufe ab, deren Argumente getaggte Werte enthalten.

Detection: Outbound-Traffic-Monitoring auf der Tool-Wrapper-Schicht. Statistische Baseline der Argument-Verteilungen pro Tool. Anomalie bei Argument-Größe, Encoding-Dichte oder Ziel wird geflaggt.

Sandbox-Muster

Drei Sandbox-Muster wiederholen sich in gut architekturierten Agent-Deployments. Sie schließen sich nicht aus; reife Systeme kombinieren alle drei.

• MCP pro Agent. Jeder Worker-Agent erhält einen MCP-Server, der genau auf die Tools beschränkt ist, die er braucht — mit Argument-Validierung auf der MCP-Schicht. Der Agent kann Tools außerhalb seines MCP-Scopes weder sehen noch aufrufen. Der MCP-Server ist die Per-Agent-Capability-Grenze.
• Least-Tool-Privilege. Jedes Tool exponiert die minimale Fähigkeit, die für die aktuelle Aufgabe erforderlich ist. Ein „File-Read"-Tool liest einen einzelnen Dateipfad, der zur Konstruktionszeit übergeben wird — keine beliebigen Pfade zur Aufrufzeit. Ein „Database-Query"-Tool führt ein Prepared Statement aus, kein beliebiges SQL.
• Argument-Validatoren. Tool-Wrapper validieren Argumente vor Invocation gegen ein typisiertes Schema. JSON Schema ist der einfachste Pfad; reichere Validierung (Regex, Range, Allow-List) schließt mehr Angriffsfläche. Validatoren, die ungültige Argumente ablehnen statt zu „reparieren", sind stärker.

Observability-Minimum

Fünf Observability-Artefakte sind das Minimum, das ein Auditor oder Incident Responder benötigt. Ohne sie ist ein Sicherheitsvorfall in einem Agent-System nicht rekonstruierbar.

1. Trace-ID-Propagation. Eine Korrelations-ID, am User-Request generiert und an jede nachgelagerte Operation angehängt: jede Agent-Nachricht, jeder Tool-Aufruf, jeder Memory-Read oder -Write, jede externe HTTP-Anfrage. Das ist der Join-Key für alles andere.
2. Tool-Call-Audit. Pro Tool-Invocation: Trace-ID, Agent-Identität, Tool-Identifier, Eingabeargumente, Output-Snippet (für Größe gekürzt), Wall-Clock-Zeitstempel, Erfolgs-/Fehlerstatus, Exception-Detail wenn vorhanden.
3. Inter-Agent-Message-Log. Pro Nachricht zwischen Agenten: Trace-ID, Quell-Agent, Ziel-Agent, Nachrichten-Payload, Zeitstempel. Genutzt für Cross-Agent-Prompt-Injection-Detection.
4. Memory-Operation-Log. Pro Memory-Read oder -Write: Trace-ID, Agent-Identität, Memory-Store, Schlüssel oder Query, Wert oder abgerufener Inhalt (gekürzt), Quellen-Attribution. Genutzt für Memory-Poisoning-Forensik.
5. Response-Attribution. Die finale benutzerseitige Antwort trägt Metadaten, die zeigen, welche Agenten welche Fragmente beigetragen haben. Der Benutzer sieht das nicht; das Audit-Log schon. Kritisch für Incident-Rekonstruktion.

Red-Team-Playbook

Eine Red-Team-Übung für ein Agent-System folgt einem vier-phasigen Muster. Die Phasen laufen pro Szenario sequenziell; mehrere Szenarien laufen parallel gegen dasselbe Ziel.

1. Aufklärung. Die Agent-Fähigkeiten enumerieren: welche Tools, welche Daten, welches Memory, welche Agenten reden mit welchen. Der exponierte System-Prompt ist das wertvollste Artefakt; viele Agent-Systeme leaken ihn durch adversariales Prompting.
2. Boundary Probing. Für jede identifizierte Grenze (User-Orchestrator, Orchestrator-Worker, Worker-Tool, Agent-Memory, Agent-Agent) Test-Inputs konstruieren, die die beabsichtigten Vertrauens­annahmen verletzen. Dokumentieren, welche Verletzungen erfolgreich sind.
3. Exploitation. Erfolgreiche Boundary-Verletzungen zu Angriffen verketten, die Angreiferziele erreichen: Datenexfiltration, Privilege Escalation, persistenter Foothold via Memory Poisoning. Jede Kette mit einem Reproduktions-Rezept melden.
4. Detection-Bewertung. Die erfolgreichen Angriffe gegen den Produktiv-Observability-Stack wiederholen. Verifizieren, dass jeder Angriff ein detektierbares Signal produziert und dass der Bereitschaftsdienst alarmiert würde. Angriffe, die in der Observability unentdeckt bleiben, sind höher priorisierte Findings als Angriffe, die erfolgreich waren.

Compliance-Mapping

Drei regulatorische Frameworks adressieren Agent-Systeme bereits direkt oder mittelbar. Betreiber, die Agenten in regulierten Umgebungen einsetzen, werden auf diese abgebildet — ob sie es wollen oder nicht.

Das Mapping ist nicht exotisch. Die sieben Angriffsklassen sind anerkannte Risiken; die Verteidigungen sind Standard-Informations­fluss-Steuerung und Observability-Muster, an den Agent-Kontext angepasst. Betreiber, die bereits reife Application Security praktizieren, finden das Mapping geradlinig. Betreiber, die ihr erstes Agent-System ohne etablierte Sicherheits-Posture deployen, sollten für die Lücke planen.

Warum das wichtig ist

Agent-Systeme werden schneller deployt, als die Security-Community defensive Leitlinien veröffentlicht. Die Asymmetrie begünstigt Angreifer kurzfristig. Das obige 7-Klassen-Modell ist nicht erschöpfend — es ist die Menge der Angriffsklassen, die ich über mehrere Deployments wiederkehrend gesehen habe. Erwarten Sie, dass das Modell sich weiterentwickelt, sobald sich Deployment-Muster ändern und neue Angriffe auftauchen.

Das Observability-Minimum und die Sandbox-Muster sind die Hebelpunkte. Ein Agent-System mit ordnungsgemäßer Trace-Propagation, Tool-Call-Auditing und Per-Agent-Capability-Scoping macht die meisten Angriffe detektierbar und viele davon direkt vermeidbar. Ein Agent-System ohne diese ist eine Black Box, die kein Auditor abnehmen wird und kein Incident Responder nach einem Breach rekonstruieren kann.

Bauen Sie die Observability-Schicht zuerst. Fügen Sie Agenten als Zweites hinzu. Die meisten Teams machen das in der falschen Reihenfolge — den Agenten ausliefern, dann bemerken, dass Incident Response unmöglich ist, dann Observability auf ein deployed System retrofitten. Retrofitting dauert länger, produziert Lücken und erfordert oft architektonische Änderungen an der Agent-Schicht, die mit Planung vermeidbar gewesen wären.