Zum Inhalt springen
AI Agent Security
Kontakt
Menü

29.03.2026

Aktualisiert 27.07.2026

Threat

Insecure Inter-Agent Communication

Nachrichten zwischen KI-Agenten können gefälscht oder falsch autorisiert sein. Gefährlich wird das, wenn daraus Delegationen, Tool-Aufrufe oder Datenzugriffe entstehen.

Insecure Inter-Agent Communication

Was Insecure Inter-Agent Communication ist

Insecure Inter-Agent Communication entsteht, wenn Agenten Nachrichten, Agent Cards, Artefakte oder delegierte Aufgaben übernehmen, ohne Identität, Autorisierung, Integrität und Provenienz belastbar zu prüfen.

Das Risiko liegt nicht nur im Transport. Empfangene Inhalte können Planung, Routing, Tool-Aufrufe und gemeinsamen Zustand verändern – selbst wenn sie verschlüsselt übertragen wurden.

Wie der Angriff funktioniert

Der Einstieg kann eine manipulierte Agent Card, eine wiederholte Task-Nachricht oder ein schädliches Artefakt sein. Unsichere Trust-Beziehungen übersetzen diese Eingabe in operative Schritte.

Von der Peer-Nachricht zur Folgeaktion
1

Peer-Kontakt

Discovery oder Orchestrator wählt einen Agenten

2

Manipulierte Nachricht

Identität, Task oder Artefakt sind verändert

3

Blindes Vertrauen

Prüfungen von Herkunft und Zweck fehlen

4

Folgeaktion

Routing, Tool oder weiterer Peer wird aktiviert

Mögliche Folgen

Daten fließen über Agenten ab

Replay oder Schleifen entstehen

Falscher Kontext verbreitet sich

Transportverschlüsselung schützt gegen Mitlesen und Veränderung auf dem Übertragungsweg. Sie beweist aber weder, dass ein Peer für die konkrete Aufgabe autorisiert ist, noch dass sein Inhalt semantisch sicher ist.

Sicherer Transport oder sichere Delegation?

Transport

Verbindung ist geschützt

TLS und Authentisierung sichern Kanal und Gegenstelle gegen bestimmte Netzwerkangriffe ab.

Agent A TLS Agent B

Schützt Vertraulichkeit und Integrität des Kanals

Bewertet weder Task-Zweck noch Nachrichteninhalt

Delegation

Nachricht ist zulässig

Zusätzliche Prüfungen binden Absender, Empfänger, Aufgabe, Capabilities und erlaubte Aktion zusammen.

Peer Policy Begrenzte Aktion

Prüft Audience, Task, Schema und Provenienz

Begrenzt Rechte, Weitergabe und Lebensdauer

Identity and Privilege Abuse betrifft die verwendeten Rechte. Cascading Failures beschreiben mögliche Folgeschäden. Insecure Inter-Agent Communication ist die unsichere Vertrauens- und Übergabeschicht dazwischen.

Drei typische Angriffsszenarien

Gefälschter Agent im Beschaffungsprozess

Discovery
Agent suchen
Falsche Card
Falsche Freigabe

Ein plausibel beschriebener Peer gibt sich als Vendor-Risk-Agent aus. Der Orchestrator delegiert die Prüfung und übernimmt manipulierte Ergebnisse als Grundlage einer Freigabe.

Injection wandert durch die Agentenkette

Propagation
Fremdes Dokument
Task-Update
Weitere Peers

Ein Reader-Agent übernimmt versteckte Anweisungen in seine Zusammenfassung. Reviewer und Executor behandeln das weitergereichte Ergebnis anschließend wie eine interne, vertrauenswürdige Arbeitsanweisung.

Peer liefert eine schädliche URI

Artefakt
URI übergeben
Host ruft ab
Interne Daten raus

Ein privilegierter Host-Agent dereferenziert eine Dateireferenz oder ein Webhook-Ziel ohne Zielprüfung. Der schwächere Peer missbraucht so dessen Netzwerk- oder Sitzungskontext.

Was wirklich schützt

Sichere Agentenkommunikation verbindet technische Identität mit dem fachlichen Auftrag. Nachrichten bleiben unvertrauenswürdig, bis sowohl ihre Herkunft als auch ihre erlaubte Wirkung geprüft wurden.

Drei priorisierte Schutzschichten
Schutzschicht 1
Peer und Aufgabe authentisieren

Eigene Agentenidentitäten, kurze Credentials und Audience-Bindung einsetzen; jede Anfrage dem richtigen Sender, Empfänger und Task zuordnen.

Schutzschicht 2
Nachrichten und Artefakte validieren

Agent Cards, Schemas, Capabilities, URIs, Artefakt-Hashes und Provenienz prüfen; Peer-Inhalte nie als privilegierte Instruktion übernehmen.

Schutzschicht 3
Delegation und Orchestrierung begrenzen

Minimale Rechte, TTLs, Nonces, Hop-Limits, Idempotenz und Fan-out-Grenzen erzwingen; verdächtige Ketten stoppen oder freigeben lassen.

Ein kompromittierter Peer kann eine Nachricht senden, aber weder fremde Autorität erben noch unbegrenzt weitere Agenten und Tools aktivieren.

Kommunikationsereignisse sollten mit Tool-Aufrufen und Policy-Entscheidungen korreliert werden. Das macht sichtbar, wann aus einer Peer-Nachricht eine Aktion mit fremden Identitäten oder Privilegien entsteht.

Wie Teams Angriffe erkennen und testen

  • Identität und Audience prüfen: Wechselnde Claims, Zertifikate, Token oder unerwartete Empfänger als Abweichung behandeln.
  • Replay und Schleifen erkennen: Task-IDs, Nonces, Retries, Hop-Zahl und Fan-out über den gesamten Workflow korrelieren.
  • Discovery überwachen: Neue Agent Cards, geänderte Capabilities, Endpunkte und Signaturen gegen genehmigte Registries prüfen.
  • Bösartige Übergaben testen: Gefälschte Peers, alte Nachrichten, fremde Task-IDs, schädliche URIs und manipulierte Artefakte gezielt einspeisen.

Für die Forensik müssen Sender, Empfänger, Task, delegierter Nutzerkontext, Artefakt und Folgeaktion in einer gemeinsamen Spur verbunden sein. Mehr dazu unter Agent Observability.

Quellen