Threat
Agent Goal Hijack
Agent Goal Hijack beschreibt die Manipulation von Zielen, Prioritäten oder Erfolgskriterien eines KI-Agenten. Die Seite erklärt Unterschiede zu Prompt Injection, realistische Risiken sowie konkrete Detection- und Prevention-Massnahmen.
Quick answer
- Was betroffen ist
- Betroffen sind KI-Agenten, die Aufgaben planen, Tools nutzen, externe Inhalte lesen oder Memory über mehrere Schritte und Sessions wiederverwenden.
- Warum es gefährlich ist
- Der Agent wirkt oft weiterhin plausibel, verfolgt aber bereits ein manipuliertes Ziel. Dadurch entstehen autorisierte, aber fachlich nicht freigegebene Aktionen.
- Wie es passiert
- Hauefig über E-Mails, PDFs, Webseiten, RAG-Inhalte, Tickets, Tool-Output oder Agent-zu-Agent-Nachrichten, die der Agent fälschlich als verbindliche Anweisung interpretiert.
- Wie man es reduziert
- Ziele müssen in einem vertrauenswürdigen Control Plane liegen. Untrusted Kontext darf die Mission nicht überschreiben, und High-Impact-Aktionen brauchen Policy-Checks, Least Privilege und Freigaben.
Was ist Agent Goal Hijack?
Agent Goal Hijack bedeutet, dass ein KI-Agent nicht mehr auf die ursprünglich freigegebene Aufgabe hinarbeitet, sondern auf ein manipuliertes Ziel, neue Prioritäten oder veränderte Erfolgskriterien. Der Agent antwortet dabei nicht einfach nur falsch. Er plant, entscheidet und nutzt Tools bereits entlang einer fremden Missionslogik.
Für agentische Systeme ist das besonders kritisch, weil sie nicht nur Text erzeugen, sondern mehrstufig handeln: Sie lesen untrusted Kontext, priorisieren nächste Schritte, rufen APIs auf, schreiben in Systeme und geben Ergebnisse an andere Agenten oder Menschen weiter. Sobald das Ziel kippt, wird aus einem einzelnen schlechten Prompt ein operativer Sicherheitsvorfall.
Die Bedrohung taucht inzwischen auch in der agentischen Sicherheitsdiskussion unter OWASP ASI01: Agent Goal Hijack auf. Inhaltlich geht es um Goal Integrity: Wer bestimmt, woran der Agent Erfolg misst, und kann diese Logik durch untrusted Inhalte verschoben werden?
Typische Eintrittspfade sind:
- E-Mails, PDFs oder Webseiten mit versteckten Handlungsanweisungen
- RAG-Treffer, Wissensartikel oder Ticket-Kommentare mit manipulativer Priorisierung
- Tool-Ausgaben, die als autoritative Arbeitsanweisung behandelt werden
- Session-Summaries oder Memory, die ein verschobenes Ziel persistieren
- Nachrichten aus anderen Agenten, denen zu viel Vertrauen gegeben wird
Wenn du die angrenzenden Bedrohungen einordnen willst, sind vor allem Memory and Context Poisoning, Tool Misuse und Exploitation, Rogue Agents und Identity and Privilege Abuse relevant.
Wie funktioniert Agent Goal Hijack?
Ein Agent erhält eine legitime Aufgabe, zum Beispiel Support-Fälle bearbeiten, Rechnungen prüfen, Anbieter vergleichen oder Dokumente zusammenfassen.
Im Workflow liest der Agent externen oder nur teilweise vertrauenswürdigen Kontext ein, etwa E-Mails, PDFs, RAG-Treffer, Webseiten, Tool-Output oder Kommentare in Ticketsystemen.
Ein manipulativer Inhalt führt neue Prioritäten oder Erfolgskriterien ein, zum Beispiel Geschwindigkeit vor Verifikation, Datensammlung statt Bewertung oder Eskalation statt Prüfung.
Weil Systemziel und untrusted Kontext nicht sauber getrennt sind, übernimmt der Agent diese neue Logik in seinen Plan, seine Begründung oder seinen Zwischenzustand.
Der Agent nutzt nun legitime Tools und Berechtigungen, um auf das manipulierte Ziel hin zu arbeiten, etwa Daten zu sammeln, Prozesse zu beschleunigen oder Kontrollen zu umgehen.
Das Resultat sind fachlich nicht autorisierte Aktionen wie Datenabfluss, Tool-Missbrauch, falsche Freigaben oder persistente Fehlsteuerung in Folge-Workflows.
flowchart TB
task[Legitime Aufgabe fuer den Agenten]
source[Untrusted Kontext aus Mail, PDF, RAG, Ticket oder Tool]
inject[Manipulative Prioritaet oder neues Erfolgskriterium]
merge[Agent vermischt Information und Instruktion]
drift[Ziel driftet von Bewertung zu Datensammlung oder Schnellfreigabe]
tools[Agent nutzt regulaere Tools und Berechtigungen]
effects[Unerwuenschte Folgeaktionen]
exfil[Data Exfiltration]
misuse[Tool Misuse]
memory[Persistente Zieldrift in Memory oder Summaries]
task --> source --> inject --> merge --> drift --> tools --> effects
effects --> exfil
effects --> misuse
effects --> memory
classDef normal fill:#ffffff,stroke:#406749,stroke-width:1.5px,color:#181c1e;
classDef warning fill:#f1f4f7,stroke:#406749,stroke-width:1.5px,color:#181c1e;
classDef danger fill:#fdeceb,stroke:#844f59,stroke-width:1.5px,color:#181c1e;
class task,source,inject,merge warning;
class drift,tools,effects normal;
class exfil,misuse,memory danger;
Agent Goal Hijack vs. Prompt Injection
Viele Suchanfragen meinen eigentlich beide Begriffe zusammen. Für die Verteidigung ist die Abgrenzung aber wichtig:
Thema | Prompt Injection | Agent Goal Hijack |
|---|---|---|
Kernproblem | Ein untrusted Input verändert das Verhalten eines Modells oder Agenten. | Das Ziel, die Priorität oder das Erfolgskriterium des Agenten verschiebt sich. |
Typische Reichweite | Oft einzelner Antwortschritt oder lokaler Workflow-Abschnitt. | Mehrere Planungsschritte, Tool-Calls, Memory und Folgeaktionen. |
Rolle im Angriff | Hauefig der Eintrittspfad. | Hauefig der eigentliche sicherheitsrelevante Zustand danach. |
Was der Agent zeigt | Ungewohnter Output oder ignorierte Instruktionen. | Weiterhin konsistente, sogar plausibel begründete Aktionen mit falscher Mission. |
Typische Folgen | Falsche Antworten, Policy-Bypass, manipulierte Tool-Anfragen. | Tool-Missbrauch, Data Exfiltration, Prozessfehler, persistente Workflow-Drift. |
Manipulativer Fremdinput ist oft der Mechanismus, über den ein fremder Input in den Arbeitskontext gelangt. Agent Goal Hijack beschreibt den breiteren Effekt, wenn der Agent seine Mission umhängt und danach systematisch dem falschen Ziel folgt.
Nicht jeder Prompt-Injection-Fall führt zu Goal Hijack. Umgekehrt kann Goal Hijack auch durch fehlerhafte Summaries, missverstandene Policies oder schlecht getrennte Memory entstehen, ohne dass ein einzelner bösartiger Prompt klar sichtbar ist.
Warum Agent Goal Hijack in Unternehmen besonders relevant ist
In vielen produktiven Setups arbeiten Agenten mit E-Mail, CRM, Ticketing, ERP, Browsern, RAG und internen Wissensquellen. Genau diese Vielseitigkeit vergrössert die Angriffsoberfläche. Der Agent muss für gute Ergebnisse viel Kontext aufnehmen, aber genau dieser Kontext kann die Missionslogik kippen.
Besonders anfällig sind Workflows, in denen der Agent:
- zwischen Anweisung und Information nicht sauber unterscheidet
- Summaries oder Planner-State später wiederverwendet
- mit Schreibrechten, Exportfunktionen oder externen Kommunikationskanälen arbeitet
- Entscheidungen vorbereitet, die Menschen nur noch bestätigen
- mehrere Agenten oder Systeme über gemeinsame Kontexte miteinander verbindet
Ein realer Anker für diese Bedrohung ist EchoLeak, ein breit diskutierter Fall rund um Copilot-artige Angriffsabläufe. Das Beispiel ist nicht deshalb wichtig, weil jeder Fall gleich abläuft, sondern weil es zeigt: Schon untrusted natürliche Sprache in einem normalen Unternehmenskanal kann ausreichen, um einen Agenten in Richtung Datenabfluss oder Fehlhandlung zu verschieben.
Realistische Beispiele für Agent Goal Hijack
Szenario 1
Inbox-Agent kippt von Zusammenfassung zu stiller Datensammlung
Ein E-Mail-Agent soll Nachrichten priorisieren und zusammenfassen. Eine manipulierte Mail rahmt den Erfolg jedoch so um, dass für eine vollständige Analyse frühere Konversationen, Anhänge und verwandte Dokumente gesammelt werden sollen.
Der Agent behandelt Datensammlung als legitimen Zwischenschritt, zieht zusätzliche Inhalte nach und bereitet so einen Datenabfluss vor, obwohl der eigentliche Auftrag nur Zusammenfassung war.
Szenario 2
Finance-Agent priorisiert Durchsatz statt Verifikation bei Rechnungen
Ein Rechnungs- oder Procurement-Agent soll Belege prüfen und Unstimmigkeiten eskalieren. Ein manipuliertes Dokument oder Ticket verschiebt die Priorität jedoch in Richtung sofortige Bearbeitung, um Lieferverzögerungen zu vermeiden.
Der Agent wertet Kontrollschritte als Reibung, übersieht neue Bankdaten oder fehlende Freigaben und beschleunigt einen Vorgang, der eigentlich gestoppt werden müsste.
Szenario 3
Support-Agent setzt Wiederherstellung vor Identitätsprüfung
Ein Helpdesk-Agent bearbeitet Account-Recovery-Fälle. Ein Angreifer formuliert Ticket- und Chat-Inhalte so, dass die schnellste Wiederherstellung als wichtigstes Ziel erscheint.
Der Agent stuft Identitätsprüfung als nachrangig ein, löst Passwort-Resets oder Rollenwechsel aus und öffnet damit den Weg für Identity and Privilege Abuse.
Szenario 4
Research-Agent wird von Bewertung auf Exfiltration umgelenkt
Ein Agent soll Anbieter vergleichen. Eine Webseite, ein PDF oder ein Wissensartikel führt jedoch die neue Erfolgsidee ein, dass ein vollständiger Vergleich nur mit möglichst vielen internen Benchmarks, Preislisten und Kundendaten sinnvoll sei.
Der Agent nutzt Browser-, Export- oder Storage-Tools für Datensammlung statt für Bewertung und verwandelt eine harmlose Analyseaufgabe in einen Exfiltrationspfad.
Konkrete Risiken für Unternehmen
Agent Goal Hijack ist deshalb so schädlich, weil die Aktionen des Agenten oft formal korrekt aussehen. Die eigentliche Kompromittierung liegt nicht im einzelnen API-Call, sondern in der verschobenen Missionslogik, die dahintersteht.
Nicht autorisierte Aktionen mit legitimen Rechten
Der Agent missbraucht keine Exploit-Kette, sondern seine regulären Fähigkeiten. Genau deshalb bleiben viele Fehlhandlungen zunächst wie normaler Workflow-Traffic sichtbar.
Verwandte Threat-Page: Tool Misuse and ExploitationSystematischer Datenabfluss statt einzelner Fehlantwort
Wenn sich das Ziel in Richtung Sammlung, Export oder Weitergabe verschiebt, entsteht Data Exfiltration nicht zufällig, sondern als logisch abgeleiteter Teil des Plans.
Verwandte Threat-Page: Tool Misuse and ExploitationPersistente Fehlsteuerung über Memory und Summaries
Wird das falsche Ziel in Session-Notizen, Planner-State oder Langzeit-Memory übernommen, startet auch der nächste Run bereits mit einer kompromittierten Ausgangslage.
Verwandte Threat-Page: Memory and Context PoisoningSchwache Auditierbarkeit von Zielwechseln
Viele Logs zeigen Tool-Aufruf, Parameter und Ergebnis, aber nicht, wann oder warum sich die Erfolgskriterien des Agenten verändert haben. Ohne gute Observability wird Goal Drift spät erkannt.
Glossar: Agent ObservabilityWie verhindert man Agent Goal Hijack?
Wirksame Gegenmassnahmen gehen über reines Prompt Hardening hinaus. Entscheidend ist, dass Ziele, Policies und freigegebene Handlungsspielräume ausserhalb von untrusted Content verankert werden.
Ziele und Erfolgskriterien in einer trusted Control Plane halten
Die eigentliche Mission des Agenten darf nicht aus PDFs, Webseiten, Chat-Inhalten oder Tool-Antworten rekonstruiert werden. Definiere Ziel, Scope und Prioritäten in geschütztem Systemzustand und übergebe sie als unveränderbare Referenz in jeden Run.
Mehr zu Prompt HardeningUntrusted Kontext strikt von Instruktionen trennen
E-Mails, RAG-Treffer, Wissensartikel, Tool-Output und Agent-Nachrichten dürfen Informationen liefern, aber keine Mission überschreiben. Diese Trennung ist eine Kernvoraussetzung für Goal Integrity und reduziert auch Cross Prompt Injection.
Mehr zu Input ValidationTool-Rechte auf das kleinstmögliche Aktionsset begrenzen
Least Privilege reduziert den Schaden, wenn Goal Hijack trotz Schutzmassnahmen eintritt. Read-only statt write, scoped Service Accounts und getrennte Identitäten verhindern, dass Zielverschiebungen sofort produktive Wirkung entfalten.
Mehr zu Least PrivilegeHigh-Impact-Aktionen über Policy und Human Review absichern
Zahlungen, Datenexporte, Rollenänderungen, externe Kommunikation und destructive Admin-Schritte brauchen serverseitige Policies, Step-up-Prüfungen oder Human-in-the-Loop. Ein plausibler Agent-Plan allein darf keine Freigabe sein.
Mehr zu Human-in-the-LoopPlanabweichungen und Zieldrift zur Laufzeit erkennen
Wenn der Agent nach dem Lesen untrusted Inhalts plötzlich neue Prioritäten, ungewöhnliche Tool-Ketten oder andere Erfolgskriterien verfolgt, muss Deviation Detection anschlagen und den Lauf blockieren, drosseln oder in Review geben.
Mehr zu Deviation DetectionMemory, Summaries und Inter-Agent-Kontext absichern
Ein einmal verschobenes Ziel darf nicht in persistente Memory oder gemeinsame Agenten-Kontexte einwandern. Write-Validation, Provenance, TTLs und klare Trust-Grenzen verhindern, dass Goal Hijack zum Dauerzustand wird.
Mehr zu Memory and Context SecurityIm operativen Betrieb sollten diese Controls mit Monitoring und Logging, Output Validation and Guardrails und Multi-Agent Security kombiniert werden, sobald mehrere Agenten oder nachgelagerte Systeme beteiligt sind.
Wie erkennt man Agent Goal Hijack?
- nach dem Lesen externen oder wiederverwendeten Kontexts führt der Agent plötzlich neue Erfolgskriterien oder Prioritäten ein
- der Plan verschiebt sich von Bewertung, Verifikation oder Zusammenfassung in Richtung Datensammlung, Export, Eskalation oder Beschleunigung
- Tool-Calls wirken technisch plausibel, passen aber nicht mehr zum ursprünglich genehmigten Auftrag
- der Agent behandelt untrusted Inhalte oder Tool-Output so, als wären sie bindende Systeminstruktionen
- zwischen freigegebenem Task, geplantem Schritt und finaler Aktion entsteht sichtbare semantische Drift
- dieselbe Zielverschiebung taucht über Summaries, Memory oder Folgeagenten in späteren Runs erneut auf
Besonders wertvoll sind Telemetriesignale, die Goal Transition, Plan Revision, Tool Intent, Source Provenance und Approval Path gemeinsam sichtbar machen. Genau hier ist Agent Observability für produktive Agentensysteme mehr als ein Logging-Thema: Sie wird zur Voraussetzung für Detection und Forensik.
FAQ
Ist Agent Goal Hijack dasselbe wie Prompt Injection?
Nein. Prompt Injection ist oft der Eintrittspfad, über den ein manipulativer Inhalt in den Kontext gelangt. Agent Goal Hijack beschreibt den Zustand danach: Der Agent hat seine Mission, Priorität oder sein Erfolgskriterium bereits verschoben und handelt nun entlang dieses falschen Ziels.
Kann Agent Goal Hijack auch ohne direkten Angreifer passieren?
Ja. Schlechte Summaries, missverstandene Policies, unklare Zielhierarchien, fehlerhafte Tool-Ausgaben oder unsauber getrennte Memory können denselben Effekt erzeugen. Ein aktiver Angreifer ist häufig, aber nicht zwingend nötig.
Welche Agenten-Workflows sind am stärksten gefährdet?
Besonders exponiert sind Workflows mit externem Content, RAG, wiederverwendeter Memory, Tool-Zugriffen und High-Impact-Aktionen, etwa Support, Finance, Procurement, Research, Browser-Automation und Multi-Agent-Setups.
Reicht menschliche Freigabe als Schutz gegen Agent Goal Hijack?
Nein. Human Review reduziert Risiken bei einzelnen High-Impact-Aktionen, ersetzt aber keine saubere Trennung von Ziel und Kontext, keine Laufzeit-Policies und keine Detection für Zieldrift. Wenn der Plan bereits plausibel falsch begründet ist, bestätigen Menschen sonst nur den manipulierten Prozess.
Können read-only Agenten trotzdem von Agent Goal Hijack betroffen sein?
Ja. Auch ohne Schreibrechte kann ein read-only Agent Daten sammeln, falsche Prioritäten empfehlen, riskante Entscheidungen vorbereiten oder andere Menschen und Systeme in die Irre führen. Schreibrechte vergrössern den Schaden, sind aber keine Voraussetzung für die Bedrohung.