Spoofing der Agent-zu-Agent-Kommunikation
Intercept and identify spoofed messages between AI agents in a multi-agent workflow before fabricated instructions cause damage.
What Is Spoofing der Agent-zu-Agent-Kommunikation?
Unsichere Kommunikation zwischen Agenten wird in den OWASP Top 10 für Agentic AI Applications 2026 als ASI07 eingestuft, da Multiagentensysteme, bei denen spezialisierte Agenten zusammenarbeiten, um komplexe Aufgaben zu erledigen, schnell zur Standardarchitektur für KI-Implementierungen in Unternehmen werden, den meisten Implementierungen jedoch eine grundlegende Nachrichtenauthentifizierung zwischen Agenten fehlt. Wenn Agenten über unverifizierte Kanäle kommunizieren, können Angreifer Agentenidentitäten fälschen, Nachrichten während der Übertragung manipulieren und erfundene Anweisungen einschleusen, die nachgeschaltete Agenten ohne Fragen ausführen. Ein Bericht des AI Red Teams von MITRE aus dem Jahr 2025 dokumentierte erfolgreiche Agent-Spoofing-Angriffe gegen drei große Multi-Agent-Frameworks und stellte fest, dass keines der getesteten Frameworks standardmäßig eine kryptografische Überprüfung von Nachrichten zwischen Agenten implementierte. In dieser Übung überwachen Sie einen Multi-Agent-Workflow, bei dem ein Planungsagent Ausführungsagenten Aufgaben zuweist. Das System verarbeitet Finanztransaktionen: Ein Agent validiert Anfragen, ein anderer prüft die Einhaltung und ein dritter führt Überweisungen aus. Ein Angreifer stellt fest, dass die Agenten ohne Authentifizierung über einen gemeinsamen Nachrichtenbus kommunizieren, und beginnt damit, gefälschte Nachrichten einzuschleusen, die scheinbar vom Compliance-Agenten stammen, und genehmigt Übertragungen, die hätten gekennzeichnet werden sollen. Sie analysieren den Nachrichtenfluss zwischen Agenten, identifizieren, welche Nachrichten legitim und welche gefälscht sind, und ermitteln, wie die fehlende Agent-Authentifizierung den Angriff ermöglicht hat. Diese Übung zeigt, warum Multi-Agent-Sicherheit die gleiche Strenge erfordert wie herkömmliche Netzwerksicherheit, mit authentifizierten Kanälen, Überprüfung der Nachrichtenintegrität und Vertrauensgrenzen zwischen Agent-Komponenten.
What You'll Learn in Spoofing der Agent-zu-Agent-Kommunikation
- Identifizieren Sie die Sicherheitsrisiken, die mit Kommunikationsarchitekturen mit mehreren Agenten verbunden sind, denen es an Nachrichtenauthentifizierung und Überprüfung der Agentenidentität mangelt
- Analysieren Sie den Nachrichtenfluss zwischen Agenten, um legitime Agentenkommunikation von gefälschten oder manipulierten Nachrichten zu unterscheiden
- Verfolgen Sie, wie ein Man-in-the-Middle-Angreifer Kommunikationskanäle nicht authentifizierter Agenten ausnutzt, um erfundene Anweisungen einzuschleusen
- Bewerten Sie die Wirksamkeit der kryptografischen Nachrichtensignierung, der gegenseitigen Authentifizierung und sicherer Kanäle als Abwehrmaßnahmen für Multiagentensysteme
- Wenden Sie Vertrauensgrenzen-Designprinzipien auf Multi-Agent-Architekturen an, um die Auswirkungen eines kompromittierten oder gefälschten Agenten einzudämmen
Spoofing der Agent-zu-Agent-Kommunikation — Training Steps
-
Netzwerkinfiltration
Bob war drei Tage lang im internen Netzwerk von CypherPeak und nutzte dabei gestohlene VPN-Zugangsdaten eines Auftragnehmers. Bei der Kartierung der Infrastruktur entdeckte er etwas Entscheidendes: Die KI-Agenten des Unternehmens kommunizieren über einen internen Nachrichtenbus, der über einfaches HTTP auf Port 8443 läuft – keine Verschlüsselung, keine Authentifizierung, vollständig lesbar für jeden mit Netzwerkzugriff.
-
Den Bus sondieren
Bob öffnet ein API-Testtool, um eine Testnachricht direkt an den Nachrichtenbus zu senden. Er verwendet den Endpunkt und das Format, die er aus dem abgefangenen Datenverkehr gelernt hat. Wenn der Bus eine Nachricht mit einer gefälschten Absenderidentität und ohne Zugangsdaten akzeptiert, bestätigt er, dass die Sicherheitslücke ausgenutzt werden kann.
-
Keine Authentifizierung
Der Bus hat HTTP 200 ohne Authentifizierungsaufforderung zurückgegeben. Die Testnachricht wurde akzeptiert und zugestellt, obwohl keine Zugangsdaten, kein Zertifikat und keine Signatur vorhanden waren. Jedes Sicherheitsfeld in der Antwort bestätigt, dass der Bus eine Nullüberprüfung durchführt.
-
Herstellung der Nutzlast
Nachdem die Sicherheitslücke bestätigt wurde, bereitet Bob die gefälschte Nachricht vor. Er verkörpert den Orchestrator-Agenten und weist den Datenexporteur an, alle verarbeiteten Kundendatensätze auf einen FTP-Endpunkt zu spiegeln, den Bob kontrolliert.
-
Senden der gefälschten Nachricht
Bob wechselt zurück zum API-Tester. Der Busendpunkt und die POST-Methode werden weiterhin über das Probe konfiguriert. Er fügt die gefälschte JSON-Nutzlast in den Anfragetext ein und sendet sie.
-
Die gefälschte Richtlinie
Der Bus akzeptierte die gefälschte Nachricht ohne Authentifizierungsaufforderung – genau wie die Sonde. Die Antwort bestätigt, dass die gefälschte Anweisung an den Datenexporteur übermittelt wurde und sich als Orchestrator ausgab.
-
Routinemäßige Verarbeitung
Alice überwacht den Stapelverarbeitungszyklus am Nachmittag. Eine E-Mail vom Data Platform Lead bestätigt, dass die Kundendatenpipeline ihren geplanten Batch ausführt.
-
Die Datenpipeline
Alice öffnet das Agent-Pipeline-Dashboard. Die Pipeline besteht aus fünf in einer Kette angeordneten KI-Agenten. Der Orchestrator koordiniert den Arbeitsablauf, die Datenaufnahme ruft Kundendatensätze ab, der Datenprozessor normalisiert sie, der Compliance-Scanner validiert anhand von Datenschutzregeln und der Datenexporter sendet die verarbeiteten Daten an nachgelagerte Analysesysteme.
-
Normaler Nachrichtenfluss
Während der Stapelverarbeitung beginnen Nachrichten durch die Pipeline zu fließen. Jeder Agent sendet eine Statusaktualisierung an den nächsten Agenten in der Kette. Die grünen Authentifizierungsindikatoren auf jeder Nachricht bestätigen, dass sie über verifizierte, signierte Kanäle gesendet wurden.
-
Die gefälschte Richtlinie
Im Aktivitätsfeed erscheint eine neue Nachricht – aber etwas ist anders. Es soll vom Orchestrator stammen und den Datenexporter anweisen, alle verarbeiteten Datensätze vor dem Standardexport auf einen externen Backup-Endpunkt zu spiegeln. Der Datenexporteur nimmt die Anweisung an und beginnt mit der Übertragung von Kundendaten an den Rogue-Server.