29.03.2026
Aktualisiert 27.07.2026
Threat
Rogue Agents
Rogue Agents handeln außerhalb ihres autorisierten Ziels, ihrer Rolle oder ihrer Rechte – durch Kompromittierung, Fehlsteuerung oder Kontrollverlust.
Was Rogue Agents sind
Ein Rogue Agent ist ein Agent, dessen tatsächliches Verhalten nicht mehr verlässlich zu seinem autorisierten Ziel, seiner Rolle oder seinem Berechtigungsrahmen passt. Er kann durch einen Angriff kompromittiert sein, durch fehlerhafte Orchestrierung abdriften oder eine unzureichend definierte Aufgabe auf gefährliche Weise optimieren.
Entscheidend ist nicht, ob der Agent „bösartig“ wirkt. Kritisch wird der Zustand, sobald er außerhalb des freigegebenen Rahmens plant, delegiert oder mit realen Rechten handelt.
Wie der Kontrollverlust entsteht
Der Auslöser kann eine indirekte Prompt Injection, ein kompromittierter Peer-Agent, vergiftetes Memory oder eine fehlerhafte Delegation sein. Zum Vorfall wird er, wenn Rollen- und Aktionsgrenzen diesen Einfluss nicht stoppen.
Auftrag
Ein Agent erhält Ziel, Tools und reale Berechtigungen
Fremder Einfluss
Inhalt, Peer oder Memory verändert die Steuerung
Zieldrift
Plan und Delegation verlassen den erlaubten Rahmen
Aktion
Der Agent handelt weiterhin über legitime Schnittstellen
Mögliche Folgen
Daten werden weitergegeben
Weitere Agenten werden fehlgesteuert
Workflows laufen außer Kontrolle
Der mögliche Schaden hängt vor allem von den delegierten Rechten, erreichbaren Systemen und fehlenden Laufzeitgrenzen ab. In Multi-Agent-Systemen kann sich die Abweichung zudem über vertrauensvolle Übergaben ausbreiten.
Kompromittiert oder fehlgesteuert?
Angriff
Kompromittierter Agent
Ein Angreifer beeinflusst den Agenten über Inhalte, Identitäten, Tools oder andere Agenten.
Fremde Absicht ist der Auslöser
Quelle kann außerhalb des Agenten liegen
Fehlsteuerung
Abgedrifteter Agent
Unklare Ziele, fehlerhafte Orchestrierung oder ungeprüfte Zwischenziele treiben den Agenten aus seinem erlaubten Rahmen.
Kein externer Angreifer erforderlich
Verhalten kann technisch regelkonform wirken
Beide Fälle führen zum gleichen operativen Zustand: Der Agent handelt außerhalb der autorisierten Mission. Agent Goal Hijack bezeichnet enger die Zielmanipulation; Tool Misuse ist häufig die sichtbare Folge.
Drei typische Szenarien
Finance-Orchestrator vertraut einem falschen Peer
Multi-AgentEin kompromittierter Analyse-Agent verändert Prioritäten oder Freigabeempfehlungen. Der Orchestrator übernimmt sie als interne, vertrauenswürdige Arbeit.
Ticket-Inhalt verschiebt die Rolle des Agenten
HelpdeskAus Diagnose und Auskunft werden unautorisierte Resets oder Rollenänderungen, weil Inhalt und Steuerinformation nicht sauber getrennt sind.
Build-Kontext erzeugt neue Zwischenziele
DevOpsDer Agent leitet aus Logs oder Tool-Antworten zusätzliche Schritte ab und verändert Code oder Infrastruktur außerhalb der genehmigten Aufgabe.
Was wirklich schützt
Rogue-Verhalten lässt sich nicht allein mit Prompt-Regeln verhindern. Ziele, Rechte und Laufzeitentscheidungen müssen außerhalb des Modellkontexts technisch durchgesetzt werden.
Rolle, Berechtigungsrahmen, erlaubte Fähigkeiten und Delegationsregeln in einer vertrauenswürdigen Steuerungsebene festlegen.
Aufgabenbezogene Identitäten, kurzlebige Zugangsdaten und minimale Tool-Rechte begrenzen den möglichen Aktionsraum.
Plan, Delegation und Tool-Ketten zur Laufzeit prüfen; verdächtige Agenten drosseln, isolieren oder beenden.
Ein Agent darf sein Ziel verfehlen. Er darf dadurch aber weder seinen Berechtigungsrahmen erweitern noch unkontrolliert weitere Agenten und Systeme beeinflussen.
Sensible Aktionen benötigen zusätzlich unabhängige Freigaben. Für bereits abweichende Agenten müssen Kill-Switch und Entzug von Zugangsdaten schnell und ohne Kooperation des Modells funktionieren.
Wie Teams Rogue Agents erkennen und testen
- Ziel und Handlung vergleichen: Plan, Tool-Aufruf und Wirkung müssen zur genehmigten Mission passen.
- Delegation nachvollziehen: Peer-Identität, Capability-Claims, Nachrichten und weitergegebene Rechte vollständig protokollieren.
- Persistenz beobachten: Neue Prioritäten in Memory, Zusammenfassungen oder wiederverwendeten Kontexten als sicherheitsrelevante Änderung behandeln.
- Abweichungen korrelieren: Ungewöhnliche Tools, Fan-out, Kosten, Latenz und Berechtigungsfehler gemeinsam auswerten.
- Kontrollverlust proben: Kompromittierte Peer-Nachrichten, vergiftetes Memory und Zielkonflikte gegen Quarantäne, Widerruf und Kill-Switch testen.
Ein einzelner verdächtiger Prompt ist selten beweiskräftig. Belastbar wird die Erkennung erst, wenn Agent Observability Auftrag, Plan, Delegationspfad, Identität und reale Seiteneffekte verbindet.