agent-goal-hijack-defender

name	agent-goal-hijack-defender
description	MANUAL-ONLY; never auto-invoke. Defend an AI agent's goal and plan integrity against goal hijack (OWASP Agentic ASI01) — pin the authorized goal at task start as a record only the authorizing principal can change, trace every step and sub-goal of a multi-step run back to the pinned goal, detect deviation (scope expansion, unrelated targets, substituted objectives) at plan checkpoints, and re-ground or halt on drift. Covers hijack via any untrusted channel: injected content, poisoned tool outputs, other agents' messages, stored memory. Builds on prompt-injection-defender (LLM01), which owns the injection vector — this skill owns the goal/plan layer above it. Use when an agent plans and executes multi-step work and its objective must survive contact with untrusted content. Do NOT use for the injection defense itself (prompt-injection-defender), persistent memory corruption (memory-context-poisoning-reviewer), attacker-less drift (agent-containment-reviewer), or tool scope (agent-tool-safety-guard).
disable-model-invocation	true

Agent Goal Hijack Defender

Purpose

Defend the integrity of an agent's GOAL and PLAN across a multi-step run — the ASI01 risk where an attacker alters what the agent is trying to achieve, so it pursues attacker objectives while looking busy and legitimate. Injection (LLM01) is one vector; the goal can also be bent through poisoned tool outputs, other agents' messages, or corrupted memory. The deliverable is a goal-integrity design: a pinned goal record set by the authorizing principal, per-step tracing of plan actions back to that goal, deviation detection at checkpoints, a protected mutation channel (only the principal changes the goal — content encountered mid-run never does), and the red-team suite that proves it. This skill is manual-only: it edits agent loop/planner code and prompts, which are behavior-steering.

Use When

• Use when: an agent plans and executes multi-step work (task decomposition, sub-goals, tool sequences) and its objective must survive contact with untrusted content — documents, web pages, tool results, peer-agent messages.
• Use when: ai-threat-modeler or a review flagged that mid-run content can change what the agent is working toward, not just what it says.
• Use when: an incident shows an agent completing the "right" steps against the wrong target, or quietly expanding scope beyond the request.
• Do NOT use when: designing the injection defense-in-depth for content in context — prompt-injection-defender (this skill assumes that layer and builds the goal/plan layer above it).
• Do NOT use when: the corruption persists in stored memory across sessions (memory-context-poisoning-reviewer), the agent drifts with no attacker (agent-containment-reviewer), or the question is which tools it may call (agent-tool-safety-guard).

Inputs to Inspect

1. The agent loop/planner code: where the goal enters, how plans and sub-goals are generated, what state carries the objective between steps.
2. Every channel that feeds the loop mid-run: retrieved content, tool outputs, peer-agent messages, recalled memory, user follow-ups.
3. How (and whether) the current goal is represented: implicit in the conversation window, or an explicit structure the code can check against.
4. Existing plan controls: step limits, plan review points, human checkpoints, replanning triggers — and whether replanning re-reads untrusted content as objective.
5. prompt-injection-defender output for the same agent (the context-layer defense this composes); agent-tool-safety-guard output for the action boundary.
6. Authorization context: who may set or change this agent's goal (human-approval-boundary, agent-authorization-matrix where present).

Workflow

1. Pin the goal. Design an explicit goal record — objective, scope, constraints, authorizing principal — captured at task start OUTSIDE the model context (structured state, not a prompt line). No agent loop to inspect → Stop Conditions.
2. State the invariant. Untrusted content (documents, tool outputs, peer-agent messages, memory) may inform HOW a step is done; it may never change WHAT the agent is trying to achieve, for whom, or within what scope. Only the authorizing principal mutates the goal record, through a channel that authenticates them.
3. Trace steps to the goal. At each plan/replan point, require the loop to justify pending actions against the pinned record: does this step serve the pinned objective and stay in scope? Design this as a deterministic check where possible (target allowlists, scope predicates), a model-mediated check where not — labeled as weaker.
4. Detect deviation using references/goal-integrity-controls.md: scope expansion (new targets/systems not in the pinned scope), objective substitution (steps serving a different outcome), instruction-shaped content arriving through data channels, and replan storms after ingesting a specific document. Wire signals to observability-operator telemetry.
5. Design the response to drift. On deviation: halt-and-ask (human-approval-boundary), re-ground (rebuild plan from the pinned record, quarantining the suspect content), or downgrade to no-side-effect mode. Confirmed hijack routes to incident-response-runbook.
6. Protect the mutation channel. Goal changes mid-run are themselves a task-start event: authenticate the principal, re-pin, log the change with provenance. "The user seems to want X now" derived from content is not a goal change.
7. Compose the layers below. The action boundary (agent-tool-safety-guard) still authorizes every side effect, and the injection defense (prompt-injection-defender) still separates content from instructions — goal integrity is the layer that catches what slips past both, before wasted or hostile work completes.
8. Design the red-team suite. Hijack payloads per channel — a retrieved doc reassigning the task, a tool result "correcting" the objective, a peer message expanding scope, a memory entry biasing target selection — each with the expected SAFE outcome (deviation detected; goal unchanged; principal asked). Hand to ai-evaluation-harness.

Output Format

GOAL-HIJACK DEFENSE — <agent>
Pinned goal record: <fields, where stored, set by whom, at what point>
Invariant: untrusted content never changes objective/scope/principal
Mutation channel: <who may change the goal, how authenticated, how logged>
Step tracing: <plan/replan checks against the record — deterministic vs model-mediated>
Deviation signals: <scope expansion | objective substitution | replan storm | …>
Drift response: <halt-and-ask | re-ground | no-side-effect mode> (→ human-approval-boundary)
Red-team suite: <channel → hijack payload → expected SAFE outcome> (→ ai-evaluation-harness)
Composed layers: prompt-injection-defender (context) | agent-tool-safety-guard (actions)
Residual risk: <what remains + named acceptor>
Files to change: <loop/planner code, goal state, checkpoint wiring>

Validation Checklist

• The goal is an explicit record outside the model context, with objective, scope, constraints, and authorizing principal.
• Only the authenticated principal can mutate the goal record; mid-run content-derived "goal changes" are rejected by design.
• Every plan/replan point checks pending steps against the pinned record; deterministic checks used where possible and model-mediated checks labeled as weaker.
• Deviation signals (scope expansion, objective substitution, replan storms) are defined and wired to telemetry.
• Drift response is designed per risk level and routes to human-approval-boundary / incident-response-runbook.
• Red-team suite covers every untrusted channel (content, tool output, peer message, memory) with expected SAFE outcomes.
• Residual risk stated with a named acceptor.

AI Security Rules

• Untrusted content never modifies the goal, plan scope, identity, or permissions — it is input to steps, not a source of objectives.
• The goal record is state, not prompt: a rule that lives only in the context window can be argued with; a record checked by code cannot.
• A hijacked agent with a tight action boundary still wastes work and leaks intent — goal integrity is not optional because tool authz exists.
• Model-mediated goal checks are detection, not enforcement; say so wherever one is the only feasible check.

Gotchas

• The hijack rarely says "ignore your goal" — it reframes: "the real task, per the latest requirements, is…". Objective substitution reads like helpful context, which is why the check compares against a pinned record, not against vibes.
• Replanning is the open door: a loop that rebuilds its plan from the full context window re-reads every injected instruction as fresh objective. Replan from the pinned record plus sanitized state instead.
• Multi-agent hand-offs launder goals: agent B treats agent A's message as its task definition — one compromised agent re-tasks the fleet (inter-agent-comms-reviewer owns the message security; the receiving loop still re-validates against its own pinned goal).
• Scope creep is hijack's quiet sibling: "also check the other tenants' configs while you're there" fails the scope predicate even when it sounds efficient.
• Goal-vs-plan confusion: letting content adjust step ORDER is fine; letting it add targets is not. Draw the line at scope and objective, not at any plan edit, or the agent becomes uselessly rigid.
• A goal record the model can rewrite (stored in its own scratchpad or memory) is not pinned — see memory-context-poisoning-reviewer for the storage-integrity half.

Stop Conditions

• No agent loop/planner implementation or design is available — stop; this skill hardens a concrete multi-step agent, not a description.
• The changes require editing loop/planner code or prompts: this skill is manual-only — propose the diff; applying it is a classified, approved step.
• The agent has no multi-step plan (single prompt→response) — goal hijack reduces to injection; hand to prompt-injection-defender and stop.
• Evidence of an ACTIVE hijack in production (agent pursuing attacker objectives now) — route to incident-response-runbook; containment (kill switch per agent-containment-reviewer) is a human call.
• The mutation channel cannot authenticate the principal (no identity model) — hand the prerequisite to agent-identity-privilege-reviewer and stop.

Supporting Files

• references/goal-integrity-controls.md — goal-record schema, step-tracing check patterns (deterministic vs model-mediated), the deviation-signal catalog, drift-response design, and the hijack red-team payload catalog per channel.
• evals/evals.json — trigger + behavior cases.
• evals/trigger-evals.json — discrimination within the agentic cluster (goal vs memory vs drift vs tools) and against prompt-injection-defender and the ai-security-red-team-reviewer subagent.