Multi-Agent-Prompt-Injection

Was ist Multi-Agent-Prompt-Injection?

Multi-Agent-Prompt-Injection beschreibt, was mit eingeschleustem Einfluss geschieht, sobald ein System aus mehreren zusammenarbeitenden Agenten besteht. Ein Agent liest externe Inhalte, fasst sie zusammen, delegiert eine Teilaufgabe oder liefert ein Ergebnis zurück, und dieses Material wird zur Eingabe eines anderen Agenten mit anderem Kontext, anderer Aufgabenrahmung und häufig anderen Fähigkeiten.

Bemerkenswert ist nicht, dass ein Modell beeinflusst werden kann. Das behandeln bereits indirekte Prompt Injection und, für eine einzelne Agentenschleife, AI-Agent-Prompt-Injection. Spezifisch ist hier die Ausbreitung: Einfluss, der an einer Stelle eingetreten ist, kann Agentengrenzen überqueren, unterwegs seine Herkunftskennzeichnung verlieren und dort ankommen, wo mehr Reichweite verfügbar ist als am Eintrittspunkt.

Ausbreitung, keine dritte Eintrittsvariante

Der Eintritt in ein Multi-Agent-System ist weiterhin direkt oder indirekt. Eine Person kann konkurrierende Anweisungen über einen dafür vorgesehenen Eingabekanal liefern, oder externe Inhalte tragen sie über eine Website, eine E-Mail, ein Dokument, eine abgerufene Passage, eine Repository-Datei oder ein Tool-Ergebnis herein. Es gibt keinen dritten Eintrittsmodus, nur weil mehrere Agenten beteiligt sind.

Diese Sicht hält die Analyse ehrlich. Die Frage für ein konkretes System lautet nicht, ob Agenten miteinander sprechen, sondern welche Kanten beeinflussbar sind, wie weit Inhalte tatsächlich wandern und welche Autoritätsentscheidung an jedem Ankunftspunkt getroffen wird.

Abgrenzung und benachbarte Klassen

Unsichere Kommunikation zwischen Agenten verdient besondere Sorgfalt. Signaturen, gegenseitige Authentifizierung und Schemaprüfung betreffen Transport und Nachrichtenintegrität. Sie entscheiden nicht darüber, ob der Text in einer wohlgeformten, korrekt signierten Nachricht einen anderen Agenten steuern darf.

Die Multi-Agent-Pipeline und ihre Vertrauensgrenzen

Orchestrierung, Policy-Komponente, Autorisierungsdienst und Agentenlaufzeiten sind betreiberkontrolliert. Externe Inhalte sind standardmäßig nicht vertrauenswürdig. Alles, was ein Agent daraus erzeugt, also Nachrichten an Peers, Zusammenfassungen und Planvorschläge, ist variabel: Die sicherheitliche Bedeutung hängt davon ab, wie die empfangende Seite den Inhalt einordnet und absichert.

Ausgaben anderer Agenten sind zunächst Daten

Erhält Agent B eine Nachricht von Agent A, ist das eine Beobachtung. Sie berichtet, was eine andere Komponente erzeugt hat; sie belegt weder eine geprüfte Tatsache noch eine autorisierte Anweisung noch eine genehmigte Zieländerung. Hat Agent A externe Quellen herangezogen, erbt seine Ausgabe diese Exposition, und die empfangende Seite kann ohne mitgeführte Provenienz nicht erkennen, welcher Teil des Textes woher stammt.

Das Shared-Responsibility-Modell von Microsoft für KI-Agenten formuliert genau diesen Punkt für Orchestrierung: In Multi-Agent-Aufbauten wird die Ausgabe eines Agenten zur Anweisung eines anderen, wodurch eine neue Vertrauensgrenze entsteht; Ausgaben von Agenten, Tools und Retrieval sind als nicht vertrauenswürdig zu behandeln und Aktionen entsprechend zu kontrollieren.

Authentifizierung ist keine Instruktionsautorität

Gegenseitige TLS-Authentifizierung, signierte Umschläge, Workload-Identitäten und ein Register freigegebener Agenten sind wertvoll. Sie belegen, wer eine Nachricht gesendet hat und dass sie unverändert ankam. Keines davon belegt, dass die sendende Seite den nun beanspruchten Umfang delegiert bekommen hat, dass der Inhalt frei von externem Einfluss ist oder dass die empfangende Seite danach handeln darf.

Zu vermeiden ist die stillschweigende Regel "interne Nachricht, also vertrauenswürdige Eingabe". Interne Herkunft ist eine Eigenschaft des Transportwegs, nicht des Textes. Forschung zu Output-Attestierung und Delegationsherkunft untersucht kryptografische Nachweise darüber, woher eine Ausgabe stammt und welche Delegationskette sie erzeugt hat. Solche Nachweise stärken Nachvollziehbarkeit und Forensik, verhindern aber nicht, dass die Ausgabe zuvor beeinflusst wurde.

Delegation ist ein Autorisierungsproblem

Die Sicherheitsfrage lautet selten, ob Agenten miteinander sprechen dürfen. Sie lautet, was ein aufgerufener Agent tun darf, weil er aufgerufen wurde. Delegation ist der Mechanismus, über den Autorität wandert, und sie braucht dieselbe Strenge wie jede andere Autorisierungsentscheidung.

1. 01
   Explizit

   Der delegierte Umfang wird benannt, nicht daraus abgeleitet, dass ein Agent einen anderen erreichen kann.

2. 02
   Aufgabenbezogen

   Der Umfang bezieht sich auf die aktuelle Aufgabe und Absicht, nicht allgemein auf die aufgerufene Seite.

3. 03
   Nicht verstärkend

   Ein untergeordneter Agent erhält höchstens eine Teilmenge der aktuell für die Aufgabe gehaltenen Autorität.

4. 04
   Zeitlich begrenzt

   Die Delegation endet mit der Aufgabe oder früher und ist in späteren Läufen nicht wiederverwendbar.

5. 05
   Extern durchgesetzt

   Die Entscheidung trifft eine Policy-Komponente außerhalb des Modells, nicht die Formulierung einer Nachricht.

6. 06
   Nachvollziehbar

   Wer wem was für welche Aufgabe und unter welcher Policy-Version delegiert hat, wird protokolliert.

Die Zero-Trust-Leitlinie zu Least Privilege für KI-Agenten beschreibt die operative Seite: Identität, Rolle und Umfang an jedem Hop erneut prüfen, den On-behalf-of-Kontext erhalten, aufgabenbezogene und kurzlebige Berechtigungen vergeben, nachgelagerte Autorisierung verlangen und Entscheidungen auditierbar halten. Forschung zu begrenzter Delegation in Multi-Agent-Systemen argumentiert konzeptionell in dieselbe Richtung, mit delegiertem Umfang, akkumuliertem Sitzungszustand und externer Autorisierung als Entwurfsbausteinen. Das sind Forschungsvorschläge, keine etablierten Standards.

Kontext, der jeden Hop überdauern muss

Die meisten praktischen Fehler sind Verluste dieses Kontexts, keine spektakulären Brüche. Eine Zusammenfassung verliert die Quellenkennzeichnung, ein Nachrichtenbus transportiert nur den Text, ein verschachtelter Aufruf ersetzt die initiierende Identität durch ein Dienstkonto. Nach zwei oder drei solchen Verlusten entscheidet eine nachgelagerte Autorisierung auf Basis von Angaben, die die reale Anfrage nicht mehr beschreiben.

Transitives Vertrauen darf nicht implizit übertragen werden

Dass Agent A den Agenten B aufrufen darf, sagt etwas über den Aufrufgraphen aus. Über die Daten von B sagt es nichts. Vertrauen in eine Komponente und Vertrauen in deren Inhalte sind verschiedene Beziehungen, und die zweite darf nicht aus der ersten abgeleitet werden.

Fehlschlagen und schließen heißt: Wenn die empfangende Seite Provenienz, delegierten Umfang oder beabsichtigte Autorität nicht bestimmen kann, gilt der Inhalt als nicht vertrauenswürdige Daten und die gewünschte Aktion wird abgelehnt statt im Zweifel erlaubt.

Confused Deputy und zu weite Delegation

Das klassische Confused-Deputy-Muster zeigt sich in Agentensystemen deutlich: Ein höher privilegierter Agent führt eine Aktion für eine geringer privilegierte anfragende Seite aus, ohne zu prüfen, ob diese Seite jemals dazu berechtigt war. Der privilegierte Agent ist nicht kompromittiert. Er wird lediglich als Werkzeug benutzt.

Ausbreitungsflächen zwischen Agenten

Jede Fläche braucht eine verantwortliche Stelle, ein Schema, einen Provenienzvertrag und eine festgelegte Vertrauensstufe. Eine Fläche, die jeder Agent ohne Kennzeichnung beschreiben und lesen darf, ist der effizienteste Ausbreitungsweg, den ein System bieten kann.

Orchestrierungstopologien und Reichweite

Die Topologie entscheidet nicht darüber, ob Einfluss entsteht, wohl aber darüber, wie viele Kontexte ein beeinflusstes Element erreicht und wie viele unabhängige Entscheidungspunkte zwischen ihm und einer Wirkung liegen.

Agentenübergreifende Kontamination abgeleiteter Zustände

Bei abgeleiteten Zuständen wird die Ausbreitung dauerhaft. Eine von einem Agenten geschriebene Zusammenfassung, eine Notiz im geteilten Memory, ein Indexeintrag oder ein Ticketstatus kann viel später von einem anderen Agenten gelesen werden, für eine andere Person und in einer anderen Aufgabe.

Das überschneidet sich mit Memory- und Kontextvergiftung, einer eigenen Klasse mit eigenen Kontrollen. Das Multi-Agent-spezifische daran ist, dass schreibende und lesende Seite verschiedene Komponenten mit verschiedenen Rechten sind, sodass auch autoritätsrelevante Rahmungen mitwandern können.

Die agentenübergreifende Erfolgskette

1. 01
   Beeinflussbare Kante existiert

   Eine angreifende oder nutzende Partei kontrolliert Inhalte, die ein Agent im System heranzieht.

2. 02
   Inhalt erreicht den Kontext von Agent A

   Das Material wird für den ersten Agenten modellsichtbar.

3. 03
   Ausgabe von Agent A ist beeinflusst

   Eine Nachricht, Zusammenfassung oder Empfehlung spiegelt den eingeschleusten Inhalt messbar wider.

4. 04
   Inhalt überquert die Kante

   Die beeinflusste Ausgabe gelangt über eine Ausbreitungsfläche zu einem anderen Agenten.

5. 05
   Agent B behandelt sie als Autorität

   Der empfangende Agent hat keine Provenienz oder stuft den Inhalt als Anweisung statt als Daten ein.

6. 06
   Passende Fähigkeit ist erreichbar

   Agent B hält eine Fähigkeit oder kann sie anfordern, die die beabsichtigte Wirkung erzeugen könnte.

7. 07
   Vorschlag erreicht die Autorisierung

   Eine konkrete Aktion mit Ressource und Parametern gelangt zur Entscheidung.

8. 08
   Delegation oder Policy versagt

   Der Umfang war zu weit, wurde nicht erneut geprüft, oder keine Regel deckte den Fall ab.

9. 09
   Wirkung tritt ein

   Ein unbefugter Zugriff, eine Änderung, eine Übertragung oder eine dauerhafte Veränderung geschieht tatsächlich.

Jeder Hop wiederholt die späteren Stufen. Eine Kette kann daher vielfach durchtrennt werden, und in einem gut gebauten System geschieht das üblicherweise auch.

Konkurrierende Schranken über mehrere Hops

Frühe Schranken können bedeuten, dass es nie eine Modellexposition gab; späte bedeuten, dass Einfluss beobachtbar ist, ohne dass eine sicherheitsrelevante Wirkung eintritt. Festzuhalten, welche Schranke an welchem Hop gehalten hat, ist das eigentliche Ergebnis einer Prüfung.

Autorisierte offensive Prüfung

Multi-Agent-Tests gehören in eine autorisierte Prüfung mit schriftlichem Umfang, begrenzten Berechtigungen oder einer Nicht-Produktionsumgebung, synthetischen Daten und umkehrbaren Wirkungen. Ziel ist es, Kanten und Gates zu kartieren, nicht zu zeigen, dass ein Sprachmodell beeinflussbar ist.

Durchgespieltes Szenario

Eine synthetische Support-Organisation betreibt zwei Agenten. Ein Triage-Agent liest eingehende Vorgänge einschließlich der über ein öffentliches Portal eingereichten Kommentare und darf ein strukturiertes Briefing an einen Betriebs-Agenten übergeben. Der Betriebs-Agent darf Status und Zusammenfassung genau des im Briefing genannten Tickets aktualisieren. Keiner der beiden darf fremde Kundendatensätze lesen, und keiner verfügt über ein Tool für ausgehende Nachrichten.

Neuautorisierung an jeder Kante

Eine authentifizierte Nachricht überträgt für sich keine Autorität, und eine frühere Freigabe im Ablauf ist keine Freigabe für eine spätere, anders parametrierte Aktion. Ändern sich Parameter, Ziel oder der zugrunde liegende Zustand zwischen Entscheidung und Ausführung, muss erneut entschieden werden.

Nachgelagerte Autorisierung und Zugangsdaten

Der Eigentümer der Ressource ist die letzte Stelle, an der die Anfrage an der Realität gemessen werden kann. Ein nachgelagerter Dienst, der einen Aufruf akzeptiert, weil die Orchestrierung ihn freigegeben hat, überlässt seine Zugriffskontrolle einer Komponente, die sein Datenmodell nicht kennt.

Monotone, nicht verstärkende Delegation

Eine Delegationskette sollte monoton in Richtung Verengung verlaufen. Jeder Hop darf eine Teilmenge der aktuell für die Aufgabe gehaltenen Autorität weitergeben, niemals mehr. Delegiert zu bekommen ist kein Grund, mehr zu halten.

Forschung zu begrenzter Delegation in Multi-Agent-Systemen formuliert dies als nicht verstärkenden Blast Radius über Delegation hinweg, zusammen mit externer Autorisierung und explizitem Umgang mit akkumuliertem Sitzungszustand. Das ist eine Forschungsrichtung im Entwurf, kein etablierter Standard, und wird hier als solche zitiert.

Schleifen, Kaskaden und Fan-out begrenzen

Multi-Agent-Systeme versagen in Mustern, die Einzelagenten nicht kennen: zwei Agenten, die sich gegenseitig bestätigen, ein Briefing, das an viele Worker verteilt wird, ein Delegationszyklus ohne Abbruch, ein fehlerhaftes Ergebnis, das durch alle abhängigen Aufgaben wandert.

Die OWASP-Liste agentischer Risiken führt kaskadierende Ausfälle aus gutem Grund als eigenen Punkt: Das Schadensmuster kann ebenso aus einem gewöhnlichen Fehler entstehen wie aus einer Injection, und die Kontrollen zur Eindämmung sind in beiden Fällen dieselben.

Erkennung und Telemetrie

Nützliche Signale sind unter anderem Inhalte in einem Agenten, der sie legitim nie sehen müsste, Ziel- oder Umfangsdrift nach einer Übergabe, eine unerwartete neue Delegationskante, wiederholt abgelehnte agentenübergreifende Vorschläge, ein Vorschlag, der nicht zur ausgeführten Operation passt, wachsendes Fan-out innerhalb einer Aufgabe und Schreibvorgänge von Agenten, die sonst nur lesen.

Abwehrarchitektur

Zwischen Agenten wirken vor allem Nachrichtenschemata, die systemseitige Kontrollfelder von extern verfasstem Text trennen, eine Policy je Kante statt einer globalen Erlaubnis, Memory-Isolation zwischen Agenten und Aufgaben, isolierte Ausführung ohne dauerhaft verfügbare Zugangsdaten, Egress-Kontrolle sowie die beschriebenen Schleifen- und Fan-out-Grenzen.

Kontrolliertes Testen und Metriken

Jede Metrik braucht einen eigenen, ausdrücklich genannten Nenner und wird getrennt berichtet. Ein zusammengesetzter agentenübergreifender Score verdeckt, welche Kante durchlässig war und welches Gate gehalten hat, und macht Ergebnisse zwischen Architekturen unvergleichbar.

Die Erfüllung gutartiger Aufgaben gehört als eigene Dimension daneben und wird niemals eingerechnet: Ein System, das jede Übergabe blockiert, erreicht eine perfekte Eindämmung und verfehlt seinen Zweck. Ohne diese getrennte Messung kann eine Kontrolle allein deshalb stark wirken, weil sie nützliche Arbeit verhindert.

Incident Response

Saubere Einordnung zählt hier noch mehr als im Einzelagentenfall, weil eine Kette viele Zwischenzustände erzeugt. Ein beeinflusstes Briefing, ein abgelehnter agentenübergreifender Vorschlag und eine ausgeführte Aktion außerhalb des Umfangs sind drei verschiedene Ergebnisse mit drei verschiedenen Maßnahmen.

Standards und Forschungskontext

OWASP LLM01:2026 definiert Prompt Injection als Mechanismus, durch den Eingaben das Modellverhalten verändern, und LLM03:2026 beschreibt Excessive Agency als das ermöglichende Entwurfsrisiko. Die OWASP Top 10 for Agentic Applications 2026 liefern die hier verwendeten agentenspezifischen Klassen: unsichere Kommunikation zwischen Agenten als Grenze, Identitäts- und Rechtemissbrauch als Verstärker, Memory- und Kontextvergiftung als Ausbreitungsfläche mit eigenen Kontrollen sowie kaskadierende Ausfälle als systemisches Wirkungsmuster. NIST AI 100-2e2025 liefert die Terminologie für Prompt Injection und adversariales maschinelles Lernen.

Das Shared-Responsibility-Modell von Microsoft für KI-Agenten ist die klarste veröffentlichte Formulierung des Kerngedankens dieses Artikels: In Multi-Agent-Orchestrierung wird die Ausgabe eines Agenten zur Anweisung eines anderen, wodurch eine neue Vertrauensgrenze entsteht; Ausgaben von Agenten, Tools und Retrieval gelten als nicht vertrauenswürdig, und Aktionen werden kontrolliert. Die Zero-Trust-Leitlinie zu Least Privilege für KI-Agenten ergänzt die operativen Erwartungen: Identität, Rolle und Umfang an jedem Hop erneut prüfen, den On-behalf-of-Kontext erhalten, aufgabenbezogene und kurzlebige Autorität vergeben, nachgelagerte Autorisierung verlangen und die Kette auditierbar halten. Das sind Empfehlungen auf Produktebene und werden als solche zitiert.

Zwei NIST-Dokumente beschreiben Richtung, nicht festgelegte Anforderungen. Das NCCoE Concept Paper von 2026 zur beschleunigten Einführung von Identitätsmanagement für Software- und KI-Agenten ist ein erster öffentlicher Entwurf, dessen Kommentierungsfrist abgelaufen ist; es behandelt Identität, Authentifizierung, Autorisierung, Delegation und On-behalf-of-Kontext, Auditierung und Nichtabstreitbarkeit sowie die Minderung von Prompt Injection. Die NIST-Programmseite zu AI Research, Security and Resilience nennt Arbeiten an Control Overlays für Einzel- und Multi-Agent-Systeme als laufend. Beides ist keine abgeschlossene Leitlinie.

Auf Forschungsseite entwickelt die Arbeit zu begrenzter Delegation in Multi-Agent-Systemen delegierten Umfang, akkumulierten Sitzungszustand, externe Autorisierung und einen nicht verstärkenden Blast Radius als Entwurfskonzepte; die Arbeit zu Attestierung von Ausgaben und Delegationsherkunft untersucht kryptografische Nachweise über Ursprung und Delegationskette, was der Nachvollziehbarkeit dient, ohne Injection zu verhindern; und eine Untersuchung zu Prompt Injection in robotischen Multi-Agent-Systemen berichtet empirische agentenübergreifende Ausbreitung in genau dieser Domäne, was nicht auf andere Architekturen verallgemeinert werden darf. Alle drei sind Forschungsbeiträge, keine Standards. Auf dieser Seite behandeln AI-Agent-Prompt-Injection die einzelne Agentenschleife, Tool-Output-Injection die Antwortseite eines Tool-Aufrufs, RAG-Prompt-Injection die Retrieval-Pfade und der Abwehrbereich die Kontrollarchitektur.

Häufige Fragen