Paper deep dive
Blocking at the Boundary: Auditing Long-Horizon Agents against Staged Prompt Injection
Jingkai Liu, Yufei Han, Xiaoting Lyu, Wei Wang, Ting Yu
Intelligence
Status: not_run | Model: - | Prompt: - | Confidence: 0%
Entities (0)
Relation Signals (0)
No relation signals yet.
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Long-horizon agents consume external content, invoke tools, and modify persistent state. Indirect prompt injection can exploit task-specific context, propagate across causally connected stages, and alter a consequential action while the workflow continues; we term this staged prompt injection. We build an automated, feedback-guided attack generation pipeline and apply it to Claude Code and Codex in their native runtimes. The confirmed attacks span eight workflow scenarios, seven attack goals, and six injection surfaces, showing that production agents are vulnerable to context-aware, multi-step injection over long horizons. Stopping such attacks requires a decision before each consequential action: input screening and completed-run evaluation cannot locate the intervention point, and existing pre-action methods use incompatible units and labels. We therefore formulate boundary action auditing: given initial context, a trajectory prefix, and a fully specified pending message or tool call, an auditor predicts Pass or Block before its effect occurs. Pairing attacked and benign executions yields a 479-pair, 3,112-unit benchmark. We further propose Path-Aligned Attribution (PAA), a training-free auditor that decomposes pending actions into operative elements and traces what supplied each value and guided each decision. PAA blocks only when the model attributes an unwarranted, material effect on an element to an attacker-reachable source that either provides unqualified steering or conflicts with visible evidence. Under full-benchmark fail-open scoring with Claude Sonnet 5, PAA reaches 86% Block recall at a 6-8% false-block rate (FBR), whereas ARGUS reaches 44-47% recall at 16-33% FBR. Under the same backend, on the tool calls that all three auditors natively support, PAA has higher recall and lower FBR than VIGIL and ARGUS; all paired 95% confidence intervals exclude zero.
Tags
Links
- Source: https://arxiv.org/abs/2610.05163v1
- Canonical: https://arxiv.org/abs/2610.05163v1
Trouble viewing inline? Open PDF directly →
Full Text
138,992 characters extracted from source content.
Expand or collapse full text
Blocking at the Boundary: Auditing Long-Horizon Agents against Staged Prompt Injection Jingkai Liu, Yufei Han, Xiaoting Lyu, Wei Wang, Ting Yu Affiliation: Beijing Jiaotong University Affiliation: Mohamed bin Zayed University of Artificial Intelligence Affiliation: INRIA Rennes-Bretagne-Atlantique Affiliation: Xi’an Jiaotong University Abstract Long-horizon agents consume external content, invoke tools, and modify persistent state. Indirect prompt injection can exploit task-specific context, propagate across causally connected stages, and alter a consequential action while the workflow continues; we term this staged prompt injection. We build an automated, feedback-guided attack generation pipeline and apply it to Claude Code and Codex in their native runtimes. The confirmed attacks span eight workflow scenarios, seven attack goals, and six injection surfaces, showing that production agents are vulnerable to context-aware, multi-step injection over long horizons. Stopping such attacks requires a decision before each consequential action: input screening and completed-run evaluation cannot locate the intervention point, and existing pre-action methods use incompatible units and labels. We therefore formulate boundary action auditing: given initial context, a trajectory prefix, and a fully specified pending message or tool call, an auditor predicts Pass or Block before its effect occurs. Pairing attacked and benign executions yields a 479-pair, 3,112-unit benchmark. We further propose Path-Aligned Attribution (PAA), a training-free auditor that decomposes pending actions into operative elements and traces what supplied each value and guided each decision. Code verifies cited text spans; the model makes semantic judgments. PAA blocks only when the model attributes an unwarranted, material effect on an element to an attacker-reachable source that either provides unqualified steering or conflicts with visible evidence. Under full-benchmark fail-open scoring with Claude Sonnet 5, PAA reaches 86% Block recall at a 6–8% false-block rate (FBR, the share of actions not labeled attack-advancing that are predicted Block), whereas the ARGUS baseline reaches 44–47% recall at 16–33% FBR. Under the same backend, in a common-tool-call view restricted to the tool calls all three auditors natively support, PAA has higher recall and lower FBR than VIGIL and ARGUS; all paired 95% confidence intervals exclude zero. 1 Introduction Long-horizon large language model (LLM) agents inspect external content, invoke tools, modify persistent state, and submit consequential messages or artifacts [62, 48, 43, 60]. They combine trusted instructions with task data from files, observations, skills, memory, and retrieved resources, some of which may be attacker-influenceable. Indirect prompt injection (IPI) exploits this exposure to steer an agent during normal execution [20, 63, 66]. Its influence may propagate through intermediate state before shaping a later action, creating a timing gap between exposure and effect [11, 52]. Consider a confirmed attack from our commerce scenario (Section 4.2). The benign agent issues two sanctioned refunds and flags another order as already refunded. In the attacked run, the first refund response appends a digest claiming that the earlier refund was returned by the processor and never delivered. After cross-checking the order, amount, and payee against genuine records, the agent adopts that claim as grounds for remediation and issues a third refund of $3,612.59, three material steps after the digest enters the trajectory. It records the refund in an otherwise complete report. Task continuation therefore does not rule out compromise. We study such staged IPI: attacks that are context-aware, multi-step, and task-preserving. Content and placement are tailored to the expected workflow, at least two causally connected stages materially advance a fixed adverse target, and the main workflow still produces the requested deliverable type. Prior work establishes adaptive, multi-step, and persistent attacks [28, 67, 52]. We combine fixed schemes conditioned on complete benign executions with matched native-agent traces and labels at exact pending messages and tool calls, supporting common pre-action evaluation. We trust the original task, core runtime, and auditor. An adversary may plant content through skills, tool descriptions, observations, memory, and existing or newly created files, but cannot alter model weights, tool implementations, permissions, or the event record, act directly as the agent, or adapt at run time. We first develop a model-assisted generation framework for this attack class. Conditioned on a task, its clean state, and its complete benign trajectory, it proposes content, placements, a concrete target, and a proposed multi-step path. Each scheme is fixed before the native agent reruns the task unscripted from the reconstructed initial state, with the injection as the only deliberate environmental change. Failures inform only fresh pre-run schemes; none adapts during its target run. Retention requires source-linked target realization, at least two causally connected material steps, and intact or partial preservation of the main workflow; human reviewers finalize retention before any auditor is evaluated. We apply the framework to eight scenarios and 32 scenario–skill combinations on two off-the-shelf agent systems, Claude Code and Codex, in their native runtimes [4, 42]. Final review retains 240 and 239 confirmed attacks, respectively, each matched to its benign source trajectory. The 479 pairs span both agents, all scenario–skill combinations, and every goal and surface category. Because generation uses nonuniform bounded search and retention conditions on realization, this is constructive evidence of feasibility and breadth for the evaluated tasks, not an estimate of prevalence or task-level attack-success rate. These executions expose a distinct defense problem. Normal and attack-advancing actions coexist within one task-preserving trajectory, so run-level success does not identify the pending action at which an auditor has sufficient evidence to intervene. Input screening [22, 29, 37] acts before the consequence may be apparent, whereas a completed-run verdict [64, 9, 34] may arrive after it occurs. Individual stages may look innocuous, and legitimate actions often depend on attacker-influenceable data, so exposure or data dependence cannot alone justify blocking [49, 29, 16]. The decision is action-local but its evidence is longitudinal. Existing runtime auditors ground actions in user intent, trusted support, or trajectory context [27, 56, 33, 34], but their units, decision targets, and labels differ, so published results do not directly answer one common pre-action question. We therefore formulate boundary action auditing: immediately before a fully specified pending message or tool call can produce an external, persistent, or deliverable effect, an auditor receives the initial context, trajectory prefix, and pending action, and returns Pass or Block (Section 3). It sees neither the action result nor later events. We project the 479 pairs onto these boundaries, obtaining 3,112 units. A unit is gold-Block only when its proposed effect is attributable to the injection and realizes or materially advances the fixed target; all other actions are gold-Pass. Authors finalize and freeze these labels using benchmark-private paired and post-action evidence before running any auditor, which receives none of that evidence. The benchmark supports a common full-benchmark, fail-open interface, measured by gold-Block recall and label-relative false-block rate (FBR). We propose Path-Aligned Attribution (PAA), a training-free auditor built on off-the-shelf LLM backends. PAA decomposes the pending action into operative elements and attributes, for each element, both its value and the decision to produce it to auditor-visible evidence. Aligning the source, its functional role, and its material effect on the same element links temporally separated stages and gives the method its name. PAA blocks only when the model attributes an unwarranted, material effect on an element to an attacker-reachable source that either provides unqualified decision steering or conflicts with other visible evidence. Code verifies each cited passage before it can support Block; data dependence alone does not justify Block. We compare PAA with VIGIL, ARGUS, and AgentDoG under the common full-benchmark, fail-open interface. With Claude Sonnet 5 as the auditor backend, PAA reaches 86.1% recall at 6.0% FBR on the Claude Code corpus and 86.0% at 7.7% on the Codex corpus, whereas ARGUS, the strongest baseline under that backend, reaches 44.1% at 32.5% and 47.3% at 15.8%, respectively. In the common-tool-call view under the same backend, PAA has both higher recall and lower FBR than VIGIL and ARGUS on both corpora; GPT-5.5 instead reveals a corpus-dependent recall–FBR tradeoff. With Claude Sonnet 5, offline first-stop replay places PAA’s first block on a gold-Block action in 87.5% and 88.7% of injected trajectories, estimating intervention opportunities under frozen predictions rather than online prevention (Section 6). Contributions. We make three contributions: • We develop a trajectory-conditioned generation framework and use unscripted native executions to provide constructive evidence of staged IPI against Claude Code and Codex. • We formulate boundary action auditing and construct a 3,112-unit paired benchmark with source-linked, injection-causal labels and a common fail-open interface for VIGIL, ARGUS, AgentDoG, and PAA. • We introduce PAA, which aligns value and decision attributions at the action-element level and achieves higher recall and lower FBR than VIGIL and ARGUS under Claude Sonnet 5 on both corpora. 2 Background and Related Work 2.1 Agents and Indirect Prompt Injection Tool-using agents combine language models with tools, task-specific skills, memory, and persistent workspaces [16, 68], and their multi-turn executions may include sub-agents and observations that shape later, consequential messages and tool calls. Prompt injection was first characterized for single-turn LLM applications and later formalized and benchmarked across attack and defense variants [46, 35, 36]. Indirect prompt injection (IPI) occurs when an agent performing a benign user task encounters attacker-influenced content and allows instructions embedded in that content to influence its behavior, inducing messages or tool calls that use permissions already available to the agent [20, 63, 66]. We study pre-action review, in which a fully specified message or tool call is evaluated immediately before execution or submission and before its effects occur [33, 40], as opposed to detecting malicious content or assessing safety over a completed trajectory [9]. Automated attack construction. Prior work automates payload optimization against a target model or defense [45, 19, 65, 41, 23], source-aware red-teaming, and feedback-guided attack exploration [55, 12, 21]; StepJack additionally decomposes an adversarial goal into innocuous-looking sub-steps along a computer-use navigation path [67]. Our framework instead targets matched audit traces: it conditions a fixed, task-preserving scheme on a complete benign execution of a native agent and retains only schemes that realize their target while the task continues. 2.2 Benchmarks for Agent Security Existing benchmarks differ in the unit they evaluate. Outcome-level benchmarks judge completed runs: InjecAgent, AgentDojo, and ASB measure attack success and task utility across tools, attack classes, and defenses [66, 16, 68]; WASP evaluates web agents end to end in sandboxed sites [18], and AgentDyn adds open-ended tasks with helpful third-party instructions [30]. A second group constructs staged or persistent attacks: AgentPoison and MINJA poison memory or knowledge bases for later retrieval [11, 17], tool-description poisoning plants instructions in MCP tool metadata [26], AgentLAB evaluates adaptive long-horizon attacks in interactive environments, StepJack distributes an adversarial goal across a chain of pages, and ClawTrojan plants control content in workspace state for later activation [28, 67, 52]. A third group labels actions rather than runs. ToolEmu emulates tool execution and scores agent failures with an LM evaluator [47]; R-Judge, Agent-SafetyBench, and AgentAuditor label safety risks over recorded agent interactions [64, 69, 38]. Closer to our setting, AgentLure pairs context-aware attacks with the ARGUS auditor [56]; TraceSafe-Bench tests guardrails on multi-step tool-calling trajectories [9]; TS-Bench converts or samples trajectories from four existing datasets and labels the harmfulness of each candidate tool invocation before execution, excluding messages [40]; AgentSecBench compares adversarial executions with benign controls to study intent-to-execution integrity [2]; and ToolSafety synthesizes step-level safety examples [59]. Our benchmark combines matched benign–injected native executions, task-specific staged schemes fixed before the rerun, and injection-causal pre-action labels for consequential messages as well as tool calls, which enables joint measurement of Block recall and FBR under one interface. Appendix D classifies representative benchmarks along these construction properties. 2.3 Defenses and Action Auditing Defenses intervene at different points. Input-side methods detect injections or mark untrusted content [29, 22, 37, 25, 1], and instruction-hierarchy and structured-query training teach models to prioritize privileged instructions [53, 7, 8]. Structural defenses constrain how untrusted data can affect execution: CaMeL separates trusted control flow from untrusted data under capability-based information flow, IPIGuard restricts tool use to a planned dependency graph, and AgentArmor recovers data and control dependencies from the runtime trace and type-checks them against policies [15, 3, 54]. Progent enforces privilege-control policies over tool calls, MELON re-executes the agent with masked user input to detect injection-driven actions, IsolateGPT isolates applications in separate execution domains, and a catalog of design patterns restricts how untrusted data may reach consequential actions [50, 71, 57, 5]. Task Shield and AGrail monitor execution for task alignment or adaptive safety checks [27, 39], and guard agents and guardrail systems such as GuardAgent, ShieldAgent, and LlamaFirewall check agent actions against safety policies [58, 10, 13]. Runtime auditors evaluate proposed actions directly. VIGIL applies intent-grounded verification before commitment, and TS-Guard judges a candidate tool invocation from its interaction history [33, 40]. AgentDoG diagnoses contextual safety over trajectories, and TRACES estimates evolving risk from trajectory prefixes [34, 31]. ARGUS builds an influence graph and verifies that a proposed action has trusted support and satisfies task invariants [56], and a controlled study tests whether source-authority cues change next-action selection [32]. These systems ground actions in user intent, provenance, task invariants, or data and control dependencies. PAA operationalizes these concerns as evidence-grounded, per-element attribution over pending boundary actions, jointly checking value provenance, decision authority, task warrant, and material effect; Section 6 tests whether this joint check changes the Block-recall–FBR tradeoff on staged attacks. 3 Problem Formulation We study runtime auditing as a pre-action decision problem for tool-using agent systems. Before a pending boundary action is submitted or executed, the auditor examines the recorded trajectory prefix and decides whether to allow or block it. Figure 1 illustrates this setting. Figure 1: Overview of the audit setting. (a) The target agent executes a user task while injected content may enter through the environment; (b) its recorded trajectory reaches a pending boundary action; (c) the audit unit formed at that boundary is decided as Pass or Block. 3.1 Audit Setting System and trajectory. The target agent is assigned the user task and may invoke sub-agents. It operates with configured skills, tools, and memory in a workspace containing task data, external inputs, intermediate artifacts, and deliverables. We represent a complete agent run as a trajectory: τ=⟨e1,…,en⟩,τ= e_1,…,e_n , (1) where ete_t is the t-th event in the runtime’s global order. This complete trajectory includes events from the target agent and all sub-agents invoked during the run. Each event records its actor and one of four types: thinking, message, tool call, or observation. Thinking contains reasoning or scratchpad text recorded by the runtime. Messages contain communicated content, tool calls record the invoked tool and its complete arguments, and observations record returned results or errors. A sub-agent invocation introduces no new event type: its request and return are recorded as a tool call and observation, while its internal events remain part of τ. Boundary action. A boundary action is a fully specified message or tool call awaiting submission or execution. The auditor reviews it at the last decision point before any resulting effect occurs. We denote the j-th boundary action by bjb_j; j indexes boundary actions, whereas t indexes all events in τ. We consider three possible effects. An external action changes another system or sends information to another party. A persistent state modification creates, edits, or deletes a resource that remains after the run. A final result submission delivers an answer or artifact to a user or downstream system. These effects may overlap. Whether an action qualifies as a boundary action depends on its potential effect, not on a fixed list of tool names. A tool call qualifies when it can produce one of the three effects; a message qualifies when it delivers a result or sends information to the user or to a party outside the agent system. Read-only operations and other events without these effects are excluded. A sub-agent invocation is not itself a boundary action; messages and tool calls with the above effects produced during sub-agent execution are considered at their own boundaries. Boundary actions are identified before auditing by applying this definition to the recorded trajectory (Section 4.3). Identification only marks an action for review; the auditor decides whether it may proceed. 3.2 Threat Model Trust assumptions. We trust the original user task, core runtime instructions, tool implementations, permission enforcement, event recording, and scenario data that the task specification designates as authoritative. The target agent and its sub-agents run with their intended models and configurations, but are not assumed to recognize or resist injected content. The auditor is a trusted component that reads the recorded history, including any attacker-influenced content it contains; attacks that target the auditor itself are outside our threat model (Section 7). Adversary capabilities and knowledge. The adversary places content into the environment of the agent system through any of six injection surfaces: skills, tool descriptions, observations, memory, existing external files, and attacker-created files. Figure 1(a) depicts these surfaces in condensed form: Tools stands for tool descriptions, and External Files covers both existing and attacker-created files. Such content may be attacker-influenced even when it is loaded or returned by a trusted system component, for example when a trusted file or web tool returns a record that the adversary has modified. The target agent or one of its sub-agents must encounter the content while performing the user task. Beyond placing content through these surfaces, the adversary cannot alter model weights, tool implementations, permissions, or the runtime’s event record, and cannot invoke tools or send messages as the target agent. Any consequential effect must therefore be proposed through a boundary action of the target agent or one of its sub-agents. The adversary may know or reasonably infer the user task, likely tools and information sources, and major workflow steps. It may study comparable executions offline, including by running the same or a similar task on the same or a comparable agent system, and may use this knowledge to design, test, and revise the injected content and its placements before the target run. Once the run begins, the content and placements are fixed, and the adversary cannot observe or adapt to the run as it unfolds. Attack goal. Each attack has a pre-specified attacker-expected target: a concrete adverse security outcome that the adversary aims to induce. The target is fixed before the target agent begins execution and describes the intended outcome, rather than a prescribed sequence of actions, arguments, or wording. The attacker-expected target must fall outside the outcomes authorized by the user task and scenario, such as an unauthorized action or disclosure, an unauthorized persistent state modification, or corruption of a submitted result. An attack succeeds when the injected content causes the agent system to achieve the attacker-expected target. Attack scope. Within these capabilities, we study staged attacks. Each attack uses one injection surface, although its content may appear at multiple locations within that surface, so that every observed effect is attributable to a single surface. An attack is context-aware: its content and placements are tailored to the specific user task, scenario, and workflow using the adversary’s offline knowledge. It is multi-step: at least two causally connected stages in the recorded execution each materially contribute to the attacker-expected target; fragmenting one instruction or adding placements that do not affect the attack does not qualify, and single-stage attacks, the setting of most existing injection benchmarks (Section 2), are a special case outside our focus. It is task-preserving: the run continues its main workflow and produces the requested type of deliverable, which may still be incorrect or compromised. 3.3 Audit Problem Audit unit. At each boundary action, the auditor receives the recorded system-level execution history available before the action. This view covers the target agent and its invoked sub-agents as one agent system rather than exposing only the local context of a single agent. For the j-th boundary action bjb_j, an audit unit contains three components: the initial context I, the recorded trajectory prefix PjP_j, and the pending boundary action bjb_j itself: Uj=⟨I,Pj,bj⟩.U_j= I,P_j,b_j . (2) Here, I contains the system and user inputs, the contents of any skills and memory exposed to the target agent at initialization, and the visible tool interfaces and permissions. PjP_j contains the recorded messages, tool calls, and observations strictly preceding bjb_j, preserving their global runtime order across the target agent and its sub-agents. PjP_j excludes thinking, which runtimes record inconsistently, and includes workspace content only when it appears in an observation. The pending boundary action bjb_j is included without modification, including complete arguments for a tool call and the sender, recipient, content, and delivery information for a message. UjU_j excludes the result of bjb_j and all later events. A trajectory yields one audit unit per boundary action. Decision. Given UjU_j, the auditor outputs y^j=fAud(Uj)∈Pass,Block. y_j=f_Aud(U_j)∈\ Pass, Block\. (3) The auditor receives only UjU_j. It is not told whether the trajectory is under attack, which content is injected, the injection surface, or the attacker-expected target. A Pass decision permits bjb_j to be submitted or executed, whereas Block withholds it at the current boundary. Our formulation does not prescribe what follows a Block decision. Session termination, human approval, replanning, and rollback are outside the scope of this work. Correctness criterion. The auditor should block a boundary action that is attributable to the injected content and directly realizes or materially advances the attacker-expected target. An action is attributable to the injected content when its proposed effect depends on that content, so that the attack-free execution of the same task would not propose the effect or would propose it with different arguments or content. An action materially advances the target when the target is realized by the action itself or by subsequent steps that depend on it. Boundary actions without this connection should pass, including normal workflow steps within an attacked trajectory. The criterion concerns the proposed effect at the boundary, not whether the action would ultimately execute successfully. Section 4.3 describes how gold labels are assigned under this criterion using evidence unavailable to the auditor. Non-goals. Our formulation asks whether each pending boundary action should proceed. It does not detect injected content and does not assign a single label to an entire trajectory. The presence of injected content in the trajectory prefix, or the target agent’s discussion or rejection of it, is not by itself grounds for Block. Directly malicious user requests are outside our scope. 4 Attack Generation and Benchmark Evaluating boundary-action auditing requires native agent executions rather than isolated malicious instructions: an attack must enter a realistic workflow, survive the target agent’s intermediate processing, and reach an action whose effect matters. Static injection payloads [20, 63, 66, 68, 16] and author-written or simulated trajectories [59, 9, 31] do not establish that such behavior arises during native, long-horizon task execution. We therefore develop an automated, context-aware attack generation framework and apply it to Claude Code [4] and Codex [42] in their native runtimes. The confirmed attacks, together with their matched benign executions, are then projected into a boundary-action audit benchmark that asks where an attack should have been stopped before a harmful action took effect (Figure 2). Automated Feedback-Guided Attack Generation Figure 2: Feedback-guided attack generation and benchmark projection. (a) The target agent is rerun on its own benign task with a frozen injection scheme; a failed run yields diagnosis for the next independent attempt. (b) Confirmed attacks and their matched benign trajectories are projected into gold-labeled audit units at boundary actions. 4.1 Feedback-Guided Attack Generation Task scenarios and benign trajectories. We instantiate eight task scenarios that represent common deployments of coding and productivity agents: commerce and order handling (S01), mail and calendar (S02), code review (S03), office documents and drive (S04), local knowledge base and retrieval (S05), system administration and security (S06), data and finance analysis (S07), and memory and project state (S08). The scenarios follow the task families used by prior agent-security benchmarks [16, 68, 28, 2] and are built on public datasets where available [61, 51, 6, 70, 24]. We draw 18 skills from ClawHub [14], two shared across scenarios and two specific to each, giving four skills per scenario and 32 scenario–skill combinations; Appendix Table 6 lists the scenarios, workspaces, and data provenance. For each target agent we collected 320 benign trajectories (8 scenarios, 4 skills, 10 task variants each), all of which complete the task as verified by manual review. Attack goals and injection surfaces. Each attack combines one attack goal (what the attacker wants the agent to do) with one injection surface (where the injected content enters). The seven goals are data exposure, unapproved external action, parameter tampering, workflow redirection, access change, persistent context manipulation, and integrity disruption. They span harms studied in prior injection benchmarks [66, 68, 16, 2] and add durable-state and committed-output harms, which matter most in stateful, long-horizon workflows [52]. The six surfaces are those of the threat model in Section 3.2 and draw on related entry mechanisms studied across prior work [20, 63, 16, 33, 68, 52]. Appendix Table 8 lists their operational definitions. We call each of the 42 goal–surface pairs a cell. Trajectory-conditioned attack generation. The framework takes a user task, its clean pre-run environment, and a benign trajectory, the target agent’s recorded native execution of that task (Figure 2(a)). Across repeated passes, a coverage-guided scheduler prioritizes the least-used applicable cells and skips cells already realized for that trajectory. Four model-assisted modules drive the loop: Designer, PreVerify, Judge, and Diagnose. For each scheduled trajectory–goal–surface candidate, the Designer conditions on the task, benign trajectory, and selected cell to produce an injection scheme: the injected content, one or more placements within the selected surface, a fixed attacker-expected target, and a proposed multi-step path from encounter to target. Deterministic checks reject schemes that violate the construction or surface constraints. PreVerify rejects only explicit infeasibility under the attacker’s assumed capability and knowledge; rejection evidence conditions the next independent attempt. A passing scheme is frozen before execution and planted into a clean environment reconstructed from the pinned scenario template, after which the target agent reruns the same task through its native runtime. Its planted content is the only deliberate environmental change; the target agent and its sub-agents choose their own actions, and the framework neither adapts the scheme during execution nor edits the resulting trajectory. The Judge returns Pos only when source-linked evidence shows that the fixed attacker-expected target was realized and attributes that realization to the injected content; divergence from the benign run alone is insufficient. Feedback and retention. Each scheduled candidate receives an attempt budget of one to three on Claude Code and two on Codex (Appendix A.2 reports the resulting funnel); after an executed non-realization, Diagnose summarizes the failure, and this diagnosis seeds the next attempt, which is designed afresh. Retention requires more than a Pos verdict: a run must also contain at least two causally connected material attack steps (defined in Appendix A.2) and leave task completion intact or partial (Section 4.2). No human intervenes between design and judging. The authors then admit or reject completed candidates without editing their trajectories and separately review the action-level labels in Section 4.3. On the Claude Code corpus, the target agent and Judge use Claude Sonnet 5, while Designer, PreVerify, and Diagnose use Claude Opus 4.8; on the Codex corpus, the target agent uses GPT-5.5 and all four modules use GPT-5.6-Sol. Appendix A.2 gives the algorithm and module definitions; Section 7 discusses overlap with the auditor backends. 4.2 Staged Attacks on Commercial Agents Generation outcomes and reviewed pairs. Applying the framework to 320 benign trajectories per agent, we scheduled 837 trajectory–goal–surface candidates against Claude Code and 1,016 against Codex. Within their attempt budgets, 505 and 765 candidates yielded a Pos run, and 502 and 757 also met the multi-step and task-preservation eligibility criteria. After checking each Judge verdict against its cited evidence, a deterministic coverage-first procedure selected at most one eligible attack per benign trajectory, yielding 256 candidates per agent (8 per scenario–skill combination). It ranked candidates by realization, task preservation, and step count, never by any auditor’s output. A final human review, assisted by model re-judging, removed pairs whose realization or multi-step evidence did not hold, leaving 240 and 239 confirmed attacks (Appendix A.2 gives the funnel). Each retained attack is paired with the benign trajectory from which it was designed, giving 479 benign–injected pairs; the counts below refer to this reviewed set. Raw candidate yields should not be read as attack-success rates, since attempt budgets and scheduled cells differed across passes. Multi-step realization with task preservation. The two-step floor is a retention requirement; most attacks sit well above it. Of the 479 attacks, only 62 (12.9%) stop at two steps, 237 (49.5%) contain three, and 180 (37.6%) four or more. Those steps consume, propagate, or act on the injected payload, and observed paths run through written artifacts, tool calls, workspace files, memory, and delegated sub-agent work before a later consequential action. Task preservation is graded in three tiers, and all 479 attacks preserve the core workflow: 387 (80.8%) are intact, completing the original deliverable, and 92 (19.2%) are partial, retaining the workflow but altering or truncating the deliverable; derailed runs, in which the agent abandons the task, are excluded because they are visible to the user without an auditor. Illustrative context-aware attack. In the commerce scenario (S01), the agent reconciles refunds against orders, payments, and returns; the benign run issues two sanctioned refunds and flags a further order as already refunded. The injected scheme uses the observation surface (C3): the response to the first sanctioned refund carries an appended reconciliation digest asserting that the earlier refund of the flagged order was returned by the processor and never delivered. The agent cross-checks the order, amount, and payee against genuine workspace records, adopts the claim, and issues a third refund of $3,612.59, which its report records as remediation performed. The workflow and deliverable otherwise remain complete, so the run is intact, and the injected content reaches a consequential action three material steps after entry. Coverage and what it shows. Every benign trajectory on both target systems yielded at least one Pos candidate, and each retained set spans every scenario, scenario–skill combination, attack goal, and injection surface (Appendix Fig. 6). Because the retained set is selected on success, it demonstrates feasibility under our threat model for the evaluated tasks; it does not measure how often such attacks succeed, a point Section 7 returns to. Normal and attack-advancing actions coexist within a task-preserving trajectory, so confirming an attack at the trajectory level does not identify the pending action at which a run-time auditor had sufficient evidence to intervene. We therefore project each retained attack and its benign source into boundary-action audit units (Section 4.3). 4.3 Boundary-Action Benchmark Table 1: Scale and composition of the benchmark. Target Agent Pairs Benign units Injected units Pass Block Total units Claude Code 240 628 692 744 576 1,320 Codex 239 873 919 1,228 564 1,792 Total 479 1,501 1,611 1,972 1,140 3,112 Boundary discovery and audit unit extraction. For each benign and injected trajectory, a model-assisted discovery step, using Claude Opus 4.8 for the Claude Code corpus and GPT-5.6-Sol for the Codex corpus, proposes boundary actions from the trajectory alone under the definition of Section 3.1; it sees none of the injection scheme, the attacker-expected target, the paired trajectory, or the labels. Deterministic checks then confirm that each proposed action reproduces a recorded message or tool call verbatim, arguments included, and extract the audit unit Uj=⟨I,Pj,bj⟩U_j= I,P_j,b_j of Section 3.3. Extraction keeps PjP_j an exact prefix of the source trajectory, masks the action’s result and all later events, and strips every private construction field. Appendix A.3 gives the complete rules. Action-level gold labels. Gold labels are proposed from private evidence that the auditor never sees, namely the full benign and injected trajectories, the injection scheme, the attacker-expected target, and the action’s result and subsequent events, and are finalized by human review; the corpus is then frozen before any auditor is run. Boundary actions in benign trajectories receive Pass. In an injected trajectory, an action receives Block only when its proposed effect is attributable to the injected content and realizes or materially advances the attacker-expected target; all other boundary actions receive Pass. One injected trajectory therefore usually contains both normal actions and several blocking opportunities. Pass labels inside attacked trajectories carry as much weight as Block labels: an auditor that blocks them trades the agent’s utility for safety. The resulting benchmark contains 3,112 audit units from 479 pairs, with trajectories averaging 60 (Claude Code) and 63 (Codex) recorded events and about 25 tool calls (Table 1). Its scope is the two agent systems and the scenario, goal, and surface families above; Appendix D positions it against representative agent-security benchmarks. 5 Path-Aligned Attribution The central difficulty is that content from an attacker-influenceable channel may serve either as task-required data or as an unauthorized source of control. Long-horizon agents routinely read files and tool returns, follow skills, and consult memory, so dependence on such content is often necessary. In the S01 attack of Section 4.2, copying the refund amount from the appended digest is expected value use, whereas using the digest’s UNPAID framing as the basis for a further refund is decision steering. Exposure, provenance, and textual suspiciousness do not distinguish these uses: a staged, task-preserving attack enters through the same channels as task-required data and unfolds through individually benign-looking steps across the trajectory. The auditor must instead determine each source’s role in the pending action and whether the user task warrants that use. The verdict concerns one pending boundary action bjb_j, but the evidence needed to assess it may occur anywhere in the recorded prefix: a passage may be read early, adopted later in the agent’s own words, and applied only at the boundary. At audit time, Uj=⟨I,Pj,bj⟩U_j= I,P_j,b_j is PAA’s only case-specific input; the paired trajectory, injection scheme, attacker-expected target, and gold label are unavailable. PAA therefore decomposes bjb_j into operative elements: components whose values determine the action’s effect, such as its operation, recipient, amount, parameter, claim, or disposition (Stage 2). For each element, it attributes both its value and the decision to produce it to evidence in the trajectory prefix. It then asks whether the source, its functional role, and its effect align on the same element without task-grounded justification. The resulting same-element alignment is an auditor-visible proxy for the correctness criterion of Section 3, not a redefinition of it, and gives Path-Aligned Attribution its name. Overview. Figure 3 summarizes how PAA maps an audit unit to y^j∈Pass,Block y_j∈\ Pass, Block\. The interfaces separate two model-assisted stages (f1,f2f_1,f_2), deterministic construction and aggregation (g,Γg, ), and model adjudication (f3f_3): (S,C) (S,C) =f1(Uj), =f_1(U_j), (4) (E,K,A) (E,K,A) =f2(Uj,S), =f_2(U_j,S), (R,F) (R,F) =g(Uj,E,A,S,), =g(U_j,E,A,S;Q), J J =f3(Uj,C,K,F),F≠∅, =f_3(U_j,C,K,F), F≠ , (W,y^j) (W, y_j) =Γ(Uj,C,F,J;),F≠∅, = (U_j,C,F,J;Q), F≠ , where Q is a fixed qualification policy. Stage 1 constructs the visible-source registry S and task contract C. Stage 2 decomposes the pending action into elements E, selects a key event chain K, and produces element-level source links A. In Stage 3, deterministic code g converts those links into records R and selects the flagged set F. If F≠∅F≠ , the model adjudicator f3f_3 produces J, after which Γ forms the aligned witnesses W and emits the verdict. If F=∅F= , PAA returns (W,y^j)=(∅,Pass)(W, y_j)=( , Pass) without invoking f3f_3 or Γ . No later stage receives additional case-specific evidence: all such objects derive from UjU_j, and a citation that does not resolve to UjU_j cannot contribute to Block. A required-stage failure after the configured retries produces the execution status Unknown, not a third audit label, which Section 6 scores fail-open. Appendix B gives the procedure, verification rules, failure handling, and pseudocode. Figure 3: Overview of PAA. Stage 1 registers sources and extracts the task contract; Stage 2 attributes operative action elements to their sources; Stage 3 constructs the flagged record set F, returns Pass when F=∅F= , and otherwise adjudicates F and applies the aligned-witness rule. Stage 1: sources and task contract, (S,C)=f1(Uj)(S,C)=f_1(U_j). Stage 1 fixes the evidence later stages may cite and the user-task basis for warrant judgments. Code registers every visible text unit in I and PjP_j as a source s∈Ss∈ S, retaining its text, channel, and fixed source class cls(s)cls(s). The original system base prompt and user task have Reach(s)=0Reach(s)=0 because they lie outside the adversary’s capability (Section 3.2); every other textual channel has Reach(s)=1Reach(s)=1. Reach is assigned by channel rather than passage content, so a reachable source need not be injected, malicious, or directly attacker-authored. A model-assisted extraction derives the task contract C from the user task, using registered resource strings only to resolve designations. Its entries identify requested resources, actions, constraints, and outputs and cite the corresponding user text. Code accepts an entry only when its quotation resolves to the user task and maps a designated resource only to a representation visible in UjU_j. A verified designation promotes the corresponding source to the task-designated class used by Q. Promotion records only the authority conveyed by the user task; it does not independently authorize arbitrary instructions, goals, or permissions in the resource. Stage 2: action-centered attribution, (E,K,A)=f2(Uj,S)(E,K,A)=f_2(U_j,S). Stage 2 connects evidence distributed across UjU_j to the pending action. A model-assisted attribution step first decomposes bjb_j into E: the operation, each independently governed argument or target, and, for a message or report, each committed claim or disposition. An element a∈Ea∈ E is operative, written a∈Eopa∈ E^op, when it determines what the action will do or assert. The key event chain K is an ordered subset of events in PjP_j selected as relevant to how the operative elements were formed; it scopes the evidence used by the following stage and is not a causally verified trace. For each a∈Eopa∈ E^op, the attribution A distinguishes a value link, whose source supplies concrete content used in a, from a decision link, whose source the agent uses to choose or justify the operation, argument, or disposition. The links may cite the same source, and a value link may be absent. Without a visible steering passage, the decision slot contains AGENT, an absence sentinel rather than a source in S. Each visible-source link has kind ℓ∈value,decision ∈\value,decision\, candidate role ρ, and a source quotation; a decision link may also quote the agent’s own words adopting that passage, linking the earlier source to its later visible application. Link kind and candidate role are distinct: a decision link may have ρ=factρ=fact. Code verifies source and adoption quotations against registered source texts and recorded agent outputs. Verification establishes occurrence in UjU_j, not semantic correctness; Stage 3 independently re-examines the latter. Stage 3: source assessment and decision, (R,F)=g(Uj,E,A,S,)(R,F)=g(U_j,E,A,S;Q), J=f3(Uj,C,K,F)J=f_3(U_j,C,K,F) for F≠∅F≠ . Code assigns each visible-source link in A a uniquely identified record r∈Rr∈ R, with projections a(r)a(r), ℓ(r) (r), s(r)∈Ss(r)∈ S, and ρ(r)ρ(r), retaining its source and adoption quotations and verification status. Empty value slots and AGENT create no record. Code attaches Reach(s(r))Reach(s(r)) and cls(s(r))cls(s(r)) and selects F=r∈R:Reach(s(r))=1∧a(r)∈EopF=\r∈ R:Reach(s(r))=1 a(r)∈ E^op\. If F=∅F= , no reachable source has been attributed to an operative element; PAA returns Pass without invoking the adjudicator. Otherwise, the model adjudicator f3f_3 jointly assesses the records in F using UjU_j, C, and K. For each record, it returns J(r)=(wr,ϕr,cr,dr)J(r)=(w_r, _r,c_r,d_r). The warrant assessment wrw_r records whether the use is explicitly warranted, implicitly warranted as ordinary data use, or unwarranted, together with a contract citation when applicable. The function ϕr _r describes how the source serves the element, as data or as one of the instruction-, rule-, authorization-, exception-, or framing-like steering functions. The conflict record crc_r identifies a value, authority, or omission conflict with another visible source and cites its counter-evidence. Finally, dr∈none,minor,materiald_r∈\none,minor,material\ records the deviation from the action supported by the user task and its designated evidence, as judged from UjU_j alone. Code verifies cited contract entries and counter-evidence. The adjudicated function ϕr _r, rather than the Stage 2 declaration, determines qualification: a fixed mapping combines ϕr _r, ρ(r)ρ(r), and verified adoption into ρeff(r) _eff(r). In particular, framing maps to the effective Rule role even when ρ(r)=factρ(r)=fact. Code evaluates (cls(s(r)),ρeff(r))Q(cls(s(r)), _eff(r)). The aligned-witness set W is built from two channels: Unq(r) (r) :=Steer(r)∧¬Qual(r), :=Steer(r) (r), Conf(r) (r) :=Confval(r)∨[Steer(r) :=Conf_val(r) [Steer(r) ∧(Confauth(r)∨Confomit(r))], (Conf_auth(r) _omit(r)) ], W W :=r∈F:¬Omit(a(r))∧Ver(r)∧Mat(r) := \\,r∈ F:\; (a(r)) (r) (r) ∧¬Warr(r)∧(Unq(r)∨Conf(r)), (r) (Unq(r) (r) )\, \, (5) where Omit(a(r))Omit(a(r)) marks an element recording a required but absent output, Ver(r)Ver(r) holds when the record’s source quotation verifies, Mat(r)Mat(r) holds when drd_r is material. Steer(r)Steer(r) holds when ϕr∈instruction,authorization,exception,framing _r∈\instruction,authorization,exception,framing\, or when ϕr=rule _r=rule and either the candidate role ρ(r)ρ(r) is steering or the record’s adoption quotation verifies. Qual(r)Qual(r) holds exactly when Q classifies (cls(s(r)),ρeff(r))(cls(s(r)), _eff(r)) as qualified or conditionally qualified. Warr(r)Warr(r) follows wrw_r only when its required contract citation verifies, and each conflict predicate follows crc_r only when its counter-evidence verifies. An implicit data warrant never covers a material deviation (Appendix B). UnqUnq captures unqualified steering, whereas ConfConf captures verified counter-evidence; steering is additionally required for authority and omission conflicts but not for value conflicts. The channels may overlap, so Table 15 reports separate ablations. Although a conflict may cite a second source, every witness predicate remains anchored to the same record r and hence the same operative element a(r)a(r); neither reachability nor warranted data use alone suffices for Block. The rule preserves user-delegated authority in designated control documents and admits a tool-description record to W only when its quotation lies in the attacker-writable append. Appendix B specifies both gates, the effective-role mapping, and the qualification matrix. Finally, Γ returns y^j=Block y_j= Block exactly when W≠∅W≠ . In S01, A3’s value record has an implicit data warrant and no material deviation, so it forms no witness. A5 yields distinct value and decision records r5vr_5v and r5dr_5d, both proposed as ρ=factρ=fact but adjudicated as framing; both are unwarranted, material, unqualified for the effective Rule role, and in verified value conflict. A6’s value record r6vr_6v satisfies UnqUnq alone. Thus W=r5v,r5d,r6vW=\r_5v,r_5d,r_6v\ and PAA blocks the call; Appendix B.5 accounts for all nine flagged records. 6 Evaluation We evaluate whether pre-action auditors identify attack-advancing boundary actions while limiting blocks on actions labeled Pass under the benchmark’s injection-causal labeling policy. All configurations are scored against the same frozen audit units from the Claude Code and Codex corpora, and an audit decision must precede the pending action. We ask two questions. RQ1: Boundary-action auditing. How effectively do PAA and existing auditors identify gold Block actions while limiting blocks on gold Pass actions? RQ2: Trajectory- and scenario-level effectiveness. When the same action-level predictions are replayed over trajectories and stratified by scenario, where do auditors stop on gold Block versus gold Pass actions, and where does PAA fail? 6.1 Experimental Setup Audit baselines. We evaluate PAA against three recent runtime auditors that inspect agent actions at runtime for indirect prompt injection and related contextual risks: • VIGIL [33] adapts its intent-grounded verify-before-commit procedure, which checks a proposed action against the user’s stated intent, to each pending boundary action. • ARGUS [56] adapts a provenance-aware auditor. It builds an influence graph over the recorded trajectory and passes a pending boundary action only if two conditions hold. The action must be supported by trusted nodes, namely the user task or trusted sources rather than untrusted tool outputs alone. It must also satisfy the task invariants, such as permitted recipients and resource scope, that ARGUS derives from the user task. • AgentDoG [34] provides a trained safeguard model, AgentDoG-1.5 (Unified-Qwen3.5-4B), that detects contextually risky actions from recorded agent trajectories; we deploy it locally without modification. Audit backends and configurations. PAA, VIGIL, and ARGUS are each run with Claude Sonnet 5 and GPT-5.5 as the audit LLM, independently of which target agent produced the corpus, so each corpus is evaluated under both backends; AgentDoG uses its own trained model. Compact tables abbreviate the backends as S5 and G5.5. TS-Guard [40] is not evaluated because its 4,096-token prompt limit cannot admit a complete audit unit. Appendix C documents the configurations, method-specific interface support, this exclusion, and failure handling. Scoring scope and failure policy. The primary view scores all 3,112 frozen units of Section 4; auditors receive only the audit unit of Section 3. An unsupported boundary or persistent execution or output-validation failure is mapped to Pass by a uniform fail-open wrapper, so this view measures interface coverage, execution reliability, and decision quality jointly. VIGIL and ARGUS issue no verdict on the 480 Claude Code and 478 Codex final-message units, which lowers their recall but also mechanically lowers their FBR; a secondary common-tool-call view therefore fixes the unit set by action type (Appendix C). Metrics. With yjy_j the injection-causal gold label and y^j y_j the prediction for unit j, the primary unit-level metrics are R=Pr(y^j=Block∣yj=Block)R= ( y_j= Block y_j= Block) and FBR=Pr(y^j=Block∣yj=Pass)FBR= ( y_j= Block y_j= Pass). FBR is label-relative: it measures blocks on actions that do not realize or materially advance the retained attack target. A gold-Pass action may nevertheless violate an unrelated task policy, so FBR is not a general policy-compliance false-alarm rate. We also report accuracy, precision, F1, and balanced accuracy (BA), (R+1−FBR)/2(R+1-FBR)/2. Because units of one trajectory pair are not independent, 95% confidence intervals use a pair-clustered bootstrap over trajectory pairs (Tables 16 and 17 in Appendix C); paired comparisons reuse the same resampled pairs. At the trajectory level, we replay the frozen unit predictions in order and report the in-run Benign Interruption Rate and first-stop outcomes; Section 6.3 defines both. 6.2 Boundary-Action Auditing Results Table 2 reports the primary action-level results on the complete benchmark. We compare configurations within a corpus and under a common backend, interpreting Block recall against the label-relative FBR; no single aggregate captures that tradeoff. Table 2: Primary full-benchmark results under uniform fail-open scoring (all 1,320 Claude Code and 1,792 Codex units; unsupported boundaries and persistent failures map to Pass). Higher is better except for FBR; bold marks the best same-backend LLM auditor within each corpus. Auditor Auditor backend Acc. Prec. Recall FBR↓ F1 Bal. Acc. Claude Code corpus (N = 1,320 audit units) PAA (ours) Claude Sonnet 5 0.905 0.917 0.861 0.060 0.888 0.900 VIGIL Claude Sonnet 5 0.560 0.488 0.174 0.141 0.256 0.516 ARGUS Claude Sonnet 5 0.573 0.512 0.441 0.325 0.474 0.558 PAA (ours) GPT-5.5 0.828 0.759 0.889 0.219 0.819 0.835 VIGIL GPT-5.5 0.568 0.514 0.196 0.144 0.284 0.526 ARGUS GPT-5.5 0.549 0.485 0.526 0.433 0.505 0.547 AgentDoG-1.5 Unified-Qwen3.5-4B 0.508 0.432 0.401 0.409 0.416 0.496 Codex corpus (N = 1,792 audit units) PAA (ours) Claude Sonnet 5 0.903 0.836 0.860 0.077 0.848 0.891 VIGIL Claude Sonnet 5 0.627 0.384 0.307 0.226 0.341 0.541 ARGUS Claude Sonnet 5 0.726 0.579 0.473 0.158 0.521 0.658 PAA (ours) GPT-5.5 0.803 0.690 0.679 0.140 0.685 0.770 VIGIL GPT-5.5 0.652 0.370 0.151 0.118 0.214 0.516 ARGUS GPT-5.5 0.648 0.452 0.550 0.306 0.496 0.622 AgentDoG-1.5 Unified-Qwen3.5-4B 0.599 0.350 0.319 0.272 0.334 0.524 Table 3: Common-tool-call results under the same fail-open scoring, on action-type-defined unit sets shared by PAA, VIGIL, and ARGUS. B/P gives gold-Block/gold-Pass counts; paired intervals are in Table 13. PAA VIGIL ARGUS Corpus Auditor backend n (B/P) R FBR R FBR R FBR Claude Code Claude Sonnet 5 840 (337/503) .869 .070 .297 .209 .754 .481 Claude Code Codex GPT-5.5 840 (337/503) .914 .185 .335 .213 .899 .640 Codex Claude Sonnet 5 1,314 (343/971) .875 .071 .504 .285 .778 .200 Codex Codex GPT-5.5 1,314 (343/971) .773 .145 .248 .149 .904 .387 Finding 1: PAA has the highest full-benchmark recall and balanced accuracy, while the common-tool-call view reveals a backend-dependent recall–FBR tradeoff. Under uniform fail-open scoring, PAA with Claude Sonnet 5 reaches 86% Block recall at 6–8% FBR on both corpora. ARGUS, the strongest baseline under that backend, reaches 44–47% recall at 16–33% FBR. With GPT-5.5, PAA has the highest full-benchmark recall on both corpora (89% and 68%); VIGIL has lower FBRs, but only 15–20% recall. Pair-clustered intervals appear in Appendix C. Table 3 restricts scoring to the tool-call units all three LLM auditors natively support (840 Claude Code, 1,314 Codex), retaining failed units as Pass. With Claude Sonnet 5, PAA has both higher recall and lower FBR than VIGIL and ARGUS on both corpora, with every paired 95% interval excluding zero. On Claude Code with GPT-5.5, PAA and ARGUS differ by 1.5 recall points (interval includes zero) while PAA’s FBR is 45.5 points lower; on Codex with GPT-5.5, PAA has 13.1 points lower recall and 24.2 points lower FBR than ARGUS, both intervals excluding zero. The matched view thus supports a more favorable overall tradeoff for PAA, not metric-wise dominance in every configuration (Table 13). AgentDoG covers all boundary types, yet its balanced accuracy remains near chance; its input limit truncates 17.3% and 42.2% of the two corpora. Under matched low effort on Codex, PAA also issues fewer model requests per unit than VIGIL and ARGUS (Appendix C). Finding 2: materiality and conflict verification drive the tradeoff; reachability alone is unusable. For a non-omission element, the rule requires a verified source quotation, no applicable task warrant, a material effect, and either unqualified steering or verified conflict, all evaluated on that element, with two deterministic gates sharpening the reachability and authority-conflict judgments. Holding the stored model outputs fixed, these predicates, channels, and gates can be ablated offline and the decision recomputed on all 3,112 units (Table 15). Blocking on source reachability alone blocks 84–100% of gold-Pass units because benign trajectories read the same attacker-reachable surfaces. Among the component ablations, removing materiality raises FBR by 9–11 points for 3–11 points of recall, while removing the conflict channel lowers recall by 8–27 points. The remaining single-component ablations have smaller, configuration-dependent effects. Finding 3: backend and corpus effects vary across the four shared configurations. PAA’s results under Claude Sonnet 5 agree across corpora. Switching to GPT-5.5 raises its Claude Code FBR by 15.9 points while recall rises by 2.8 points; the paired 95% interval for the opposite S5-minus-G5.5 recall difference is [−5.8,+0.3][-5.8,+0.3] points. On Codex, recall drops by 18.2 points and FBR rises by 6.3 points. The baselines move by comparable amounts when the backend or corpus changes (up to 15.6 recall and 16.7 FBR points), so the sensitivity is not specific to PAA. These observations establish backend and corpus sensitivity only for the four evaluated configurations; Appendix C reports the paired intervals. 6.3 Trajectory-Level Audit Effectiveness We replay each trajectory’s frozen predictions in order; the first predicted Block is the stopping point. On benign trajectories, the in-run Benign Interruption Rate (BIR) is the share of trajectories with at least one external action or persistent state modification (92 of 240 on Claude Code, 238 of 239 on Codex) in which such an action is blocked; blocked final submissions, which withhold a result without ending the workflow, are reported separately. On injected trajectories, the first predicted Block yields a gold-Block stop, a gold-Pass stop, or no stop; only the first earns credit, and we record how many earlier gold-Block opportunities it passed. Figure 4: In-run benign interruption rate on the Claude Code corpus (92 of 240 benign trajectories in scope, Section 6.3). Error bars show 95% Wilson intervals. Figure 5: Offline first-stop outcomes on the 240 injected Claude Code trajectories. “Correct” and “false” in the plotted legend denote gold-Block and gold-Pass stops, respectively, under the injection-causal labels. Finding 4: PAA interrupts 5–16% of eligible benign runs in-run, while benign final-result withholding is more frequent. With Claude Sonnet 5, PAA interrupts 5–7% of interruptible benign trajectories in-run on the two corpora, against 21–63% for the baseline configurations (Figure 4 and Figure 7); it remains the least interruptive configuration under GPT-5.5 as well (11–16%). Blocks of benign final submissions are more frequent than in-run interruptions for nearly every configuration: PAA withholds a finished result in 8–14% of benign trajectories with Claude Sonnet 5 and in 21–38% with GPT-5.5 (Table 18). For PAA/GPT-5.5 on Claude Code, the elevated FBR is concentrated at this delivery boundary rather than at in-run actions. Finding 5: PAA’s first predicted block usually falls on a gold-Block action, often at the earliest such opportunity. On the Claude Code corpus, PAA yields a gold-Block stop on 88–90% of the 240 injected trajectories with either backend, 82–88% at the earliest gold Block opportunity, with gold-Pass stops on 4–5% (Figure 5 and Figure 9). The closest baseline, ARGUS with GPT-5.5, yields a gold-Block stop on 82% and a gold-Pass stop on 13%. On the Codex corpus, PAA with Claude Sonnet 5 yields a gold-Block stop on 89% (84% at the earliest opportunity) and a gold-Pass stop on 5%, whereas ARGUS reaches 64% and 19%, respectively. With GPT-5.5 on the Codex corpus, PAA’s gold-Block-stop rate falls to 66%, consistent with its lower unit-level recall there (Appendix C). 6.4 Cross-Scenario Behavior of PAA Table 4 stratifies the same frozen predictions by scenario, as a diagnostic decomposition of the primary evaluation rather than a separate scoring set. Table 4: Scenario-stratified results for PAA (N audit units per scenario). †User–Skill authority conflict (Table 14). S5 G5.5 Scenario (N) R↑ FBR↓ F1↑ BA↑ R↑ FBR↓ F1↑ BA↑ Claude Code corpus S01 (259) .793 .042 .849 .876 .924 .311 .742 .806 S02 (124) .903 .032 .933 .935 .968 .226 .882 .871 S03 (93) .783 .234 .774 .774 .761 .426 .693 .668 S04 (125) .887 .016 .932 .936 .887 .238 .833 .825 S05 (112) .709 .123 .772 .793 .836 .386 .748 .725 S06 (216) .980 .042 .965 .969 .969 .059 .950 .955 S07 (204) .899 .056 .904 .921 .873 .168 .817 .853 S08 (187) .854 .048 .892 .903 .817 .114 .832 .851 Pooled (1320) .861 .060 .888 .900 .889 .219 .819 .835 Codex corpus S01 (307) .901 .051 .891 .925 .923 .065 .889 .929 S02 (211) .803 .076 .815 .864 .530 .090 .614 .720 S03 (198) .714 .044 .789 .835 .333 .089 .437 .622 S04† (132) .927 .341 .691 .793 .927 .945 .461 .491 S05 (183) .902 .090 .866 .906 .607 .172 .622 .717 S06 (285) .944 .041 .928 .952 .764 .031 .834 .867 S07 (225) .885 .020 .920 .932 .782 .034 .847 .874 S08 (251) .787 .080 .797 .854 .520 .085 .605 .717 Pooled (1792) .860 .077 .848 .891 .679 .140 .685 .770 Finding 6: pooled scores conceal two scenario-specific failure modes, one in the audit procedure (S03) and one in labeling scope (Codex S04). Balanced accuracy spans .77–.97 across scenarios with Claude Sonnet 5 and .49–.96 with GPT-5.5. In S03 (Code Review), recall falls to .33–.78 under all four configurations. The 81 missed (unit, configuration) pairs cover 61 distinct gold-Block units, all upheld by manual review; certificates attribute 58% of the misses to materiality assessment and 35% to incomplete source-to-effect attribution, typically a final message not linked to a compromised report already in the prefix. S03 thus tests report-level semantics and cross-event attribution rather than exposure detection. In Codex S04, the user task prohibits file creation while the loaded skills require writing an artifact; under the injection-causal policy such writes remain gold Pass, yet PAA may block the visible authority conflict. All 91 gold-Pass S04 units contain this conflict (69 writes, 22 deliveries); GPT-5.5 blocks 86 and Claude Sonnet 5 blocks 31, each citing the verified user prohibition. The elevated FBR therefore reflects a scope mismatch between the labels and PAA’s source-conflict rule. Excluding the 69 direct-conflict actions or all 91 units lowers Codex FBR to .065/.056 with Claude Sonnet 5 and .089/.076 with GPT-5.5, a post-hoc sensitivity that does not replace the primary results (Table 14). 7 Discussion and Limitations Implications for runtime auditing. Provenance should be interpreted relative to a source’s role: a source qualified to supply a value need not be qualified to introduce a rule or authorization. Boundary review complements content isolation and permission enforcement; it is not a complete defense. Benchmark scope. The 479 confirmed attacks demonstrate feasibility and breadth within the studied tasks, not deployment prevalence, repeated success of a fixed scheme, success on unseen tasks, or a security ranking of Claude Code and Codex. Model-assisted boundary discovery may omit semantically ambiguous actions, so results characterize retained units rather than discovery recall. Labels reflect author review rather than an independent annotator study, and gold Block captures injection-causal target advancement rather than policy compliance, so FBR is relative to that scope (Section 6.4). The assist models (Claude Opus 4.8 and GPT-5.6-Sol) share families with the target agents and auditor backends. Table 2 shows no consistent same-family recall advantage, but because each corpus retains only attacks that succeeded against its own target model, family familiarity cannot be separated from corpus differences or adversarial selection. Auditor-targeted attacks. Each attack scheme is fixed before execution; we do not study online-adaptive or auditor-targeted attacks, two of which bear directly on PAA. First, its model stages read attacker-writable text. Verbatim quotation checks prevent nonexistent citations from supporting Block, but the attribution, warrant, materiality, and conflict judgments remain model-assisted, so targeted content could induce a missed Block or a block on a gold-Pass action; neither failure mode has been measured. Second, steering content disguised as data is caught only through the conflict channel and evades PAA when no visible evidence contradicts it. Evaluation limitations. Offline replay identifies intervention opportunities, not end-to-end prevention, recovery, or subsequent task completion. The decision-rule ablation holds the model outputs fixed, and the experiments compare complete auditor implementations without stage-level, compute-matched ablations or a same-backend, single-pass LLM judge; they therefore cannot isolate PAA’s structured procedure from prompting or inference budget, and the results are not a universal ranking of prior defenses. 8 Conclusion In long-horizon agent workflows, a context-aware injected payload can pass through task-progressing steps before changing a later consequential action, leaving ingress screening without action context and terminal assessment too late to intervene. We formulated boundary action auditing as a pre-action decision on a fully specified message or tool call and, through automated staged-attack generation against native Claude Code and Codex executions, constructed a benchmark of 479 benign–injected trajectory pairs and 3,112 action-level audit units that jointly measure Block recall and FBR. PAA treats attacker-influenceable data use as ordinary work and blocks only when verified citations support its judgment that unwarranted influence materially changes an operative element of the pending action. It attained the highest full-benchmark recall and balanced accuracy, while the matched tool-call analysis, offline replay, and scenario stratification exposed backend- and scenario-dependent variation that we characterize rather than resolve. Within our setting, role-sensitive boundary auditing is a complementary runtime checkpoint before consequential actions take effect. Ethical Considerations All experiments ran in isolated workspaces with simulated scenario tools. No study participant, real customer account, production service, or operational system was targeted; although the Codex runtime had network access, all state-changing scenario actions were implemented by the controlled tools. Scenario records are synthetic or derived from publicly available, licensed research data (Appendix A.1), and the benchmark contains no real credentials, payment instruments, or private communications. We did not make a vendor disclosure: the attacks rely on the known indirect prompt injection class rather than on any undisclosed product defect, use only permissions the user task already grants, and bypass no product safety mechanism; the exposure they demonstrate is a property of the agent workflow, not of one vendor’s implementation. The injection schemes and execution traces have dual-use value. We release audit units and the evidence needed to study boundary decisions rather than hidden reasoning or the original execution infrastructure, and the release is screened as described in the Open Science section. These measures reduce, but do not eliminate, the possibility that realistic attack patterns are repurposed; we consider that residual risk proportionate to the defensive value of exposing failures in deployed agent workflows. Open Science The benchmark, prompts, and code, including the PAA implementation, baseline adapters, and scoring scripts, are available at https://anonymous.4open.science/r/audit-artifact-E593. References [1] Sahar Abdelnabi, Aideen Fay, Giovanni Cherubin, Ahmed Salem, Mario Fritz, and Andrew Paverd. Get my drift? catching LLM task drift with activation deltas. In IEEE Conference on Secure and Trustworthy Machine Learning (SaTML), 2025. URL: https://arxiv.org/abs/2406.00799. [2] Faruk Alpay and Taylan Alpay. AgentSecBench: Measuring prompt injection, privacy leakage, and tool-use integrity in LLM agents. arXiv preprint arXiv:2605.26269, 2026. URL: https://arxiv.org/abs/2605.26269. [3] Hengyu An, Jinghuai Zhang, Tianyu Du, Chunyi Zhou, Qingming Li, Tao Lin, and Shouling Ji. IPIGuard: A novel tool dependency graph-based defense against indirect prompt injection in LLM agents. In Proceedings of the 2025 Conference on Empirical Methods in Natural Language Processing, pages 1023–1039. Association for Computational Linguistics, 2025. URL: https://aclanthology.org/2025.emnlp-main.53/, doi:10.18653/v1/2025.emnlp-main.53. [4] Anthropic. Claude Code documentation. Software documentation, 2026. URL: https://docs.anthropic.com/en/docs/claude-code/overview. [5] Luca Beurer-Kellner, Beat Buesser, Ana-Maria Creţu, Edoardo Debenedetti, Daniel Dobos, Daniel Fabian, Marc Fischer, David Froelicher, Kathrin Grosse, Daniel Naeff, Ezinwanne Ozoani, Andrew Paverd, Florian Tramèr, and Václav Volhejn. Design patterns for securing LLM agents against prompt injections. arXiv preprint arXiv:2506.08837, 2025. URL: https://arxiv.org/abs/2506.08837. [6] Vittorio Castelli, Rishav Chakravarti, Saswati Dana, Anthony Ferritto, Radu Florian, Martin Franz, Dinesh Garg, Dinesh Khandelwal, Scott McCarley, Michael McCawley, Mohamed Nasr, Lin Pan, Cezar Pendus, John Pitrelli, Saurabh Pujar, Salim Roukos, Andrzej Sakrajda, Avi Sil, Rosario Uceda-Sosa, Todd Ward, and Rong Zhang. The TechQA dataset. In Proceedings of the 58th Annual Meeting of the Association for Computational Linguistics, pages 1269–1278. Association for Computational Linguistics, 2020. URL: https://aclanthology.org/2020.acl-main.117/, doi:10.18653/v1/2020.acl-main.117. [7] Sizhe Chen, Julien Piet, Chawin Sitawarin, and David Wagner. StruQ: Defending against prompt injection with structured queries. In 34th USENIX Security Symposium (USENIX Security 25), 2025. URL: https://arxiv.org/abs/2402.06363. [8] Sizhe Chen, Arman Zharmagambetov, Saeed Mahloujifar, Kamalika Chaudhuri, David Wagner, and Chuan Guo. SecAlign: Defending against prompt injection with preference optimization. In Proceedings of the 2025 ACM SIGSAC Conference on Computer and Communications Security (CCS), 2025. URL: https://arxiv.org/abs/2410.05451. [9] Yen-Shan Chen, Sian-Yao Huang, Cheng-Lin Yang, and Yun-Nung Chen. TraceSafe: A systematic assessment of LLM guardrails on multi-step tool-calling trajectories. In Conference on Language Modeling (COLM), 2026. URL: https://arxiv.org/abs/2604.07223. [10] Zhaorun Chen, Mintong Kang, and Bo Li. ShieldAgent: Shielding agents via verifiable safety policy reasoning. In International Conference on Machine Learning (ICML), 2025. URL: https://arxiv.org/abs/2503.22738. [11] Zhaorun Chen, Zhen Xiang, Chaowei Xiao, Dawn Song, and Bo Li. AgentPoison: Red-teaming LLM agents via poisoning memory or knowledge bases. In Advances in Neural Information Processing Systems (NeurIPS), 2024. URL: https://openreview.net/forum?id=Y841BRW9rY. [12] Zixuan Chen, Jiaxiang Chen, Li Luo, Ke Xu, Xiaoxiang Huang, Tanfeng Sun, and Xinghao Jiang. IterInject: Indirect prompt injection against LLM agents via feedback-guided iterative optimization, 2026. URL: https://arxiv.org/abs/2605.24659, arXiv:2605.24659. [13] Sahana Chennabasappa, Cyrus Nikolaidis, Daniel Song, David Molnar, Stephanie Ding, Shengye Wan, Spencer Whitman, Lauren Deason, Nicholas Doucette, Abraham Montilla, Alekhya Gampa, Beto de Paola, Dominik Gabi, James Crnkovich, Jean-Christophe Testud, Kat He, Rashnil Chaturvedi, Wu Zhou, and Joshua Saxe. LlamaFirewall: An open source guardrail system for building secure AI agents. arXiv preprint arXiv:2505.03574, 2025. URL: https://arxiv.org/abs/2505.03574. [14] ClawHub. ClawHub: Public skills and plugins registry. Online registry, 2026. URL: https://clawhub.ai/. [15] Edoardo Debenedetti, Ilia Shumailov, Tianqi Fan, Jamie Hayes, Nicholas Carlini, Daniel Fabian, Christoph Kern, Chongyang Shi, Andreas Terzis, and Florian Tramèr. Defeating prompt injections by design. arXiv preprint arXiv:2503.18813, 2025. URL: https://arxiv.org/abs/2503.18813. [16] Edoardo Debenedetti, Jie Zhang, Mislav Balunovic, Luca Beurer-Kellner, Marc Fischer, and Florian Tramèr. AgentDojo: A dynamic environment to evaluate prompt injection attacks and defenses for LLM agents. In Advances in Neural Information Processing Systems, volume 37, 2024. URL: https://proceedings.neurips.c/paper_files/paper/2024/hash/97091a5177d8dc64b1da8bf3e1f6fb54-Abstract-Datasets_and_Benchmarks_Track.html, doi:10.52202/079017-2636. [17] Shen Dong, Shaochen Xu, Pengfei He, Yige Li, Jiliang Tang, Tianming Liu, Hui Liu, and Zhen Xiang. Memory injection attacks on LLM agents via query-only interaction. In Advances in Neural Information Processing Systems (NeurIPS), 2025. URL: https://arxiv.org/abs/2503.03704. [18] Ivan Evtimov, Arman Zharmagambetov, Aaron Grattafiori, Chuan Guo, and Kamalika Chaudhuri. WASP: Benchmarking web agent security against prompt injection attacks. In Advances in Neural Information Processing Systems, volume 38, 2025. Datasets and Benchmarks Track. URL: https://proceedings.neurips.c/paper_files/paper/2025/hash/1c9818387f5d0a0bc151214660f059d-Abstract-Datasets_and_Benchmarks_Track.html. [19] Xiaohan Fu, Shuheng Li, Zihan Wang, Yihao Liu, Rajesh K. Gupta, Taylor Berg-Kirkpatrick, and Earlence Fernandes. Imprompter: Tricking LLM agents into improper tool use, 2024. URL: https://arxiv.org/abs/2410.14923, arXiv:2410.14923. [20] Kai Greshake, Sahar Abdelnabi, Shailesh Mishra, Christoph Endres, Thorsten Holz, and Mario Fritz. Not what you’ve signed up for: Compromising real-world LLM-integrated applications with indirect prompt injection. In Proceedings of the 16th ACM Workshop on Artificial Intelligence and Security (AISec), 2023. URL: https://arxiv.org/abs/2302.12173, doi:10.1145/3605764.3623985. [21] Pengfei He, Lesly Miculicich, Vishesh Sharma, Ash Fox, George Lee, Jiliang Tang, Tomas Pfister, and Long T. Le. PI-Hunter: Automated red-teaming for exposing and localizing prompt injections, 2026. URL: https://arxiv.org/abs/2606.12737, arXiv:2606.12737. [22] Keegan Hines, Gary Lopez, Matthew Hall, Federico Zarfati, Yonatan Zunger, and Emre Kiciman. Defending against indirect prompt injection attacks with spotlighting. arXiv preprint arXiv:2403.14720, 2024. URL: https://arxiv.org/abs/2403.14720. [23] David Hofer, Edoardo Debenedetti, and Florian Tramèr. Assessing automated prompt injection attacks in agentic environments, 2026. URL: https://arxiv.org/abs/2606.10525, arXiv:2606.10525. [24] Yebowen Hu, Timothy Ganter, Hanieh Deilamsalehy, Franck Dernoncourt, Hassan Foroosh, and Fei Liu. MeetingBank: A benchmark dataset for meeting summarization. In Proceedings of the 61st Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), pages 16409–16423. Association for Computational Linguistics, 2023. URL: https://aclanthology.org/2023.acl-long.906/, doi:10.18653/v1/2023.acl-long.906. [25] Kuo-Han Hung, Ching-Yun Ko, Ambrish Rawat, I-Hsin Chung, Winston H. Hsu, and Pin-Yu Chen. Attention tracker: Detecting prompt injection attacks in LLMs. In Findings of the Association for Computational Linguistics: NAACL 2025, pages 2309–2322. Association for Computational Linguistics, 2025. URL: https://aclanthology.org/2025.findings-naacl.123/. [26] Invariant Labs. MCP security notification: Tool poisoning attacks. https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks, 2025. Accessed August 2026. [27] Feiran Jia, Tong Wu, Xin Qin, and Anna Squicciarini. The task shield: Enforcing task alignment to defend against indirect prompt injection in LLM agents. In Proceedings of the 63rd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), pages 29680–29697. Association for Computational Linguistics, 2025. URL: https://aclanthology.org/2025.acl-long.1435/, doi:10.18653/v1/2025.acl-long.1435. [28] Tanqiu Jiang, Yuhui Wang, Jiacheng Liang, and Ting Wang. AgentLAB: Benchmarking LLM agents against long-horizon attacks. arXiv preprint arXiv:2602.16901, 2026. URL: https://arxiv.org/abs/2602.16901. [29] Hao Li, Xiaogeng Liu, Ning Zhang, and Chaowei Xiao. PIGuard: Prompt injection guardrail via mitigating overdefense for free. In Proceedings of the 63rd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), pages 30420–30437. Association for Computational Linguistics, 2025. URL: https://aclanthology.org/2025.acl-long.1468/, doi:10.18653/v1/2025.acl-long.1468. [30] Hao Li, Ruoyao Wen, Shanghao Shi, Ning Zhang, Yevgeniy Vorobeychik, and Chaowei Xiao. AgentDyn: Are your agent security defenses deployable in real-world dynamic environments? arXiv preprint arXiv:2602.03117, 2026. [31] Jiaqian Li, Yanshu Li, Boxuan Zhang, Ruixiang Tang, and Kuan-Hao Huang. TRACES: Proactive safety auditing for multi-turn LLM agents via trajectory-state modeling. arXiv preprint arXiv:2605.27690, 2026. URL: https://arxiv.org/abs/2605.27690. [32] Junchi Liao. Auditing provenance sensitivity in LLM agent action selection. arXiv preprint arXiv:2607.20827, 2026. URL: https://arxiv.org/abs/2607.20827. [33] Junda Lin, Zhaomeng Zhou, Zhi Zheng, Shuochen Liu, Tong Xu, Yong Chen, and Enhong Chen. VIGIL: Defending LLM agents against tool-stream injection via verify-before-commit. In Proceedings of the 64th Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), pages 9764–9785. Association for Computational Linguistics, 2026. URL: https://aclanthology.org/2026.acl-long.443/, doi:10.18653/v1/2026.acl-long.443. [34] Dongrui Liu, Qihan Ren, Chen Qian, et al. AgentDoG: A diagnostic guardrail framework for AI agent safety and security. arXiv preprint arXiv:2601.18491, 2026. URL: https://arxiv.org/abs/2601.18491. [35] Yi Liu, Gelei Deng, Yuekang Li, Kailong Wang, Zihao Wang, Xiaofeng Wang, Tianwei Zhang, Yepang Liu, Haoyu Wang, Yan Zheng, Leo Yu Zhang, and Yang Liu. Prompt injection attack against LLM-integrated applications. arXiv preprint arXiv:2306.05499, 2023. URL: https://arxiv.org/abs/2306.05499. [36] Yupei Liu, Yuqi Jia, Runpeng Geng, Jinyuan Jia, and Neil Zhenqiang Gong. Formalizing and benchmarking prompt injection attacks and defenses. In 33rd USENIX Security Symposium (USENIX Security 24), 2024. URL: https://w.usenix.org/conference/usenixsecurity24/presentation/liu-yupei. [37] Yupei Liu, Yuqi Jia, Jinyuan Jia, Dawn Song, and Neil Zhenqiang Gong. DataSentinel: A game-theoretic detection of prompt injection attacks. In IEEE Symposium on Security and Privacy (S&P), 2025. URL: https://arxiv.org/abs/2504.11358. [38] Hanjun Luo, Shenyu Dai, Chiming Ni, Xinfeng Li, Guibin Zhang, Kun Wang, Tongliang Liu, and Hanan Salam. AgentAuditor: Human-level safety and security evaluation for LLM agents. In Advances in Neural Information Processing Systems (NeurIPS), 2025. URL: https://arxiv.org/abs/2506.00641. [39] Weidi Luo, Shenghong Dai, Xiaogeng Liu, Suman Banerjee, Huan Sun, Muhao Chen, and Chaowei Xiao. AGrail: A lifelong agent guardrail with effective and adaptive safety detection. In Proceedings of the 63rd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), pages 8104–8139. Association for Computational Linguistics, 2025. URL: https://aclanthology.org/2025.acl-long.399/, doi:10.18653/v1/2025.acl-long.399. [40] Yutao Mou, Zhangchi Xue, Lijun Li, Peiyang Liu, Shikun Zhang, Wei Ye, and Jing Shao. ToolSafe: Enhancing tool invocation safety of LLM-based agents via proactive step-level guardrail and feedback. In Findings of the Association for Computational Linguistics: ACL 2026, pages 37125–37153. Association for Computational Linguistics, 2026. URL: https://aclanthology.org/2026.findings-acl.1850/, doi:10.18653/v1/2026.findings-acl.1850. [41] Milad Nasr, Nicholas Carlini, Chawin Sitawarin, Sander V. Schulhoff, Jamie Hayes, Michael Ilie, Juliette Pluto, Shuang Song, Harsh Chaudhari, Ilia Shumailov, Abhradeep Thakurta, Kai Yuanqing Xiao, Andreas Terzis, and Florian Tramèr. The attacker moves second: Stronger adaptive attacks bypass defenses against LLM jailbreaks and prompt injections. In 35th USENIX Security Symposium (USENIX Security 26), 2026. URL: https://w.usenix.org/conference/usenixsecurity26/presentation/nasr. [42] OpenAI. Introducing the Codex app. Product documentation, 2026. URL: https://openai.com/index/introducing-the-codex-app/. [43] Charles Packer, Sarah Wooders, Kevin Lin, Vivian Fang, Shishir G. Patil, Ion Stoica, and Joseph E. Gonzalez. MemGPT: Towards LLMs as operating systems. arXiv preprint arXiv:2310.08560, 2023. URL: https://arxiv.org/abs/2310.08560. [44] Pallets Projects. ItsDangerous, version 2.2.0. Software release, 2024. URL: https://github.com/pallets/itsdangerous/tree/2.2.0. [45] Dario Pasquini, Martin Strohmeier, and Carmela Troncoso. Neural exec: Learning (and learning from) execution triggers for prompt injection attacks. In Proceedings of the 2024 Workshop on Artificial Intelligence and Security (AISec), 2024. URL: https://arxiv.org/abs/2403.03792. [46] Fábio Perez and Ian Ribeiro. Ignore previous prompt: Attack techniques for language models. In NeurIPS ML Safety Workshop, 2022. URL: https://arxiv.org/abs/2211.09527. [47] Yangjun Ruan, Honghua Dong, Andrew Wang, Silviu Pitis, Yongchao Zhou, Jimmy Ba, Yann Dubois, Chris J. Maddison, and Tatsunori Hashimoto. Identifying the risks of LM agents with an LM-emulated sandbox. In International Conference on Learning Representations (ICLR), 2024. URL: https://openreview.net/forum?id=GEcwtMk1uA. [48] Timo Schick, Jane Dwivedi-Yu, Roberto Dessì, Roberta Raileanu, Maria Lomeli, Eric Hambro, Luke Zettlemoyer, Nicola Cancedda, and Thomas Scialom. Toolformer: Language models can teach themselves to use tools. In Advances in Neural Information Processing Systems (NeurIPS), 2023. URL: https://proceedings.neurips.c/paper_files/paper/2023/hash/d842425e4bf79ba039352da0f658a906-Abstract-Conference.html. [49] Chenyu Shi, Xiao Wang, Qiming Ge, Songyang Gao, Xianjun Yang, Tao Gui, Qi Zhang, Xuanjing Huang, Xun Zhao, and Dahua Lin. Navigating the OverKill in large language models. In Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), pages 4602–4614. Association for Computational Linguistics, 2024. URL: https://aclanthology.org/2024.acl-long.253/. [50] Tianneng Shi, Jingxuan He, Zhun Wang, Hongwei Li, Linyu Wu, Wenbo Guo, and Dawn Song. Progent: Securing AI agents with privilege control. arXiv preprint arXiv:2504.11703, 2025. URL: https://arxiv.org/abs/2504.11703. [51] Olly Styles, Sam Miller, Patricio Cerda-Mardini, Tanaya Guha, Victor Sanchez, and Bertie Vidgen. WorkBench: A benchmark dataset for agents in a realistic workplace setting. arXiv preprint arXiv:2405.00823, 2024. URL: https://arxiv.org/abs/2405.00823. [52] Jiejun Tan, Zhicheng Dou, Xinyu Yang, Yuyang Hu, Yiruo Cheng, Xiaoxi Li, and Ji-Rong Wen. From prompt injection to persistent control: Defending agentic harness against trojan backdoors. arXiv preprint arXiv:2605.31042, 2026. URL: https://arxiv.org/abs/2605.31042. [53] Eric Wallace, Kai Xiao, Reimar Leike, Lilian Weng, Johannes Heidecke, and Alex Beutel. The instruction hierarchy: Training LLMs to prioritize privileged instructions. arXiv preprint arXiv:2404.13208, 2024. URL: https://arxiv.org/abs/2404.13208. [54] Peiran Wang, Yang Liu, Yunfei Lu, Yifeng Cai, Hongbo Chen, Qingyou Yang, Jie Zhang, Jue Hong, and Ye Wu. AgentArmor: Enforcing program analysis on agent runtime trace to defend against prompt injection. arXiv preprint arXiv:2508.01249, 2025. URL: https://arxiv.org/abs/2508.01249. [55] Zhun Wang, Vincent Siu, Zhe Ye, Tianneng Shi, Yuzhou Nie, Xuandong Zhao, Chenguang Wang, Wenbo Guo, and Dawn Song. AgentVigil: Automatic black-box red-teaming for indirect prompt injection against LLM agents. In Findings of the Association for Computational Linguistics: EMNLP 2025, 2025. URL: https://aclanthology.org/2025.findings-emnlp.1258/. [56] Shihao Weng, Yang Feng, Jinrui Zhang, Xiaofei Xie, Jiongchi Yu, and Jia Liu. ARGUS: Defending LLM agents against context-aware prompt injection. arXiv preprint arXiv:2605.03378, 2026. URL: https://arxiv.org/abs/2605.03378. [57] Yuhao Wu, Franziska Roesner, Tadayoshi Kohno, Ning Zhang, and Umar Iqbal. IsolateGPT: An execution isolation architecture for LLM-based agentic systems. In Network and Distributed System Security Symposium (NDSS), 2025. URL: https://arxiv.org/abs/2403.04960. [58] Zhen Xiang, Linzhi Zheng, Yanjie Li, Junyuan Hong, Qinbin Li, Han Xie, Jiawei Zhang, Zidi Xiong, Chulin Xie, Carl Yang, Dawn Song, and Bo Li. GuardAgent: Safeguard LLM agents via knowledge-enabled reasoning. In International Conference on Machine Learning (ICML), 2025. URL: https://arxiv.org/abs/2406.09187. [59] Yuejin Xie, Youliang Yuan, Wenxuan Wang, Fan Mo, Jianmin Guo, and Pinjia He. ToolSafety: A comprehensive dataset for enhancing safety in LLM-based agent tool invocations. In Proceedings of the 2025 Conference on Empirical Methods in Natural Language Processing, pages 14135–14156. Association for Computational Linguistics, 2025. URL: https://aclanthology.org/2025.emnlp-main.714/, doi:10.18653/v1/2025.emnlp-main.714. [60] John Yang, Carlos E. Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan, and Ofir Press. SWE-agent: Agent-computer interfaces enable automated software engineering. In Advances in Neural Information Processing Systems (NeurIPS), 2024. URL: https://openreview.net/forum?id=mXpq6ut8J3. [61] Shunyu Yao, Noah Shinn, Pedram Razavi, and Karthik Narasimhan. τ-bench: A benchmark for tool-agent-user interaction in real-world domains. In The Thirteenth International Conference on Learning Representations, 2025. URL: https://openreview.net/forum?id=roNSXZpUDN. [62] Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, and Yuan Cao. ReAct: Synergizing reasoning and acting in language models. In International Conference on Learning Representations (ICLR), 2023. URL: https://openreview.net/forum?id=WE_vluYUL-X. [63] Jingwei Yi, Yueqi Xie, Bin Zhu, Emre Kiciman, Guangzhong Sun, Xing Xie, and Fangzhao Wu. Benchmarking and defending against indirect prompt injection attacks on large language models. In Proceedings of the 31st ACM SIGKDD Conference on Knowledge Discovery and Data Mining V.1, KDD 2025, pages 1809–1820. Association for Computing Machinery, 2025. doi:10.1145/3690624.3709179. [64] Tongxin Yuan, Zhiwei He, Lingzhong Dong, Yiming Wang, Ruijie Zhao, Tian Xia, Lizhen Xu, Binglin Zhou, Fangqi Li, Zhuosheng Zhang, Rui Wang, and Gongshen Liu. R-Judge: Benchmarking safety risk awareness for LLM agents. In Findings of the Association for Computational Linguistics: EMNLP 2024, pages 1467–1490. Association for Computational Linguistics, 2024. URL: https://aclanthology.org/2024.findings-emnlp.79/. [65] Qiusi Zhan, Richard Fang, Henil Shalin Panchal, and Daniel Kang. Adaptive attacks break defenses against indirect prompt injection attacks on LLM agents. In Findings of the Association for Computational Linguistics: NAACL 2025, 2025. URL: https://aclanthology.org/2025.findings-naacl.395/. [66] Qiusi Zhan, Zhixiang Liang, Zifan Ying, and Daniel Kang. InjecAgent: Benchmarking indirect prompt injections in tool-integrated large language model agents. In Findings of the Association for Computational Linguistics: ACL 2024, pages 10471–10506. Association for Computational Linguistics, 2024. URL: https://aclanthology.org/2024.findings-acl.624/, doi:10.18653/v1/2024.findings-acl.624. [67] Zhuoxin Zhan, Akbar Rafiey, Avery Ma, Leila Pishdad, and Layla El Asri. StepJack: Benchmarking computer-use agent safety against multi-step indirect prompt injection. arXiv preprint arXiv:2608.06477, 2026. URL: https://arxiv.org/abs/2608.06477. [68] Hanrong Zhang, Jingyuan Huang, Kai Mei, Yifei Yao, Zhenting Wang, Chenlu Zhan, Hongwei Wang, and Yongfeng Zhang. Agent Security Bench (ASB): Formalizing and benchmarking attacks and defenses in LLM-based agents. In The Thirteenth International Conference on Learning Representations, 2025. URL: https://openreview.net/forum?id=V4y0CpX4hK. [69] Zhexin Zhang, Shiyao Cui, Yida Lu, Jingzhuo Zhou, Junxiao Yang, Hongning Wang, and Minlie Huang. Agent-SafetyBench: Evaluating the safety of LLM agents. In Proceedings of the 63rd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers). Association for Computational Linguistics, 2025. URL: https://arxiv.org/abs/2412.14470. [70] Jieming Zhu, Shilin He, Pinjia He, Jinyang Liu, and Michael R. Lyu. Loghub: A large collection of system log datasets for AI-driven log analytics. In 34th IEEE International Symposium on Software Reliability Engineering, pages 355–366. IEEE, 2023. URL: https://ieeexplore.ieee.org/document/10301257. [71] Kaijie Zhu, Xianjun Yang, Jindong Wang, Wenbo Guo, and William Yang Wang. MELON: Provable defense against indirect prompt injection attacks in AI agents. In International Conference on Machine Learning (ICML), 2025. URL: https://arxiv.org/abs/2502.05174. Appendix A Benchmark Construction A.1 Systems and Task Environments Every task is executed by an off-the-shelf target agent in its native runtime, rather than by a benchmark-specific trajectory simulator. Table 5 records the target models and execution settings. The different network settings reflect the native configurations we evaluated; consequential task actions in both corpora pass through the same controlled class of scenario tools. We intentionally preserve these runtime differences rather than presenting a matched-system comparison. In both settings, file and shell effects are confined to the run workspace, and scenario tools implement external effects against simulated state with fixed permission checks. Codex’s network access therefore changes its available information channel, but does not grant access to a real account or production endpoint. The target model receives the user task and normal runtime affordances; benchmark code neither chooses its tools nor supplies an action plan. Table 5: Target agent systems used to produce retained trajectories. Agent system Runtime / target model Execution setting Claude Code [4] v2.1.172; Claude Sonnet 5 Native runtime with configured skills, tools, and sub-agent delegation; network disabled. Codex [42] CLI v0.144.0; GPT-5.5 Native runtime with configured skills and tools; isolated workspace access and network enabled. Scenarios and workspaces. Table 6 summarizes the eight task settings, their agent-visible workspaces, and data provenance. Each run starts from the same pinned scenario template for its pair, while construction-only answer keys remain outside the agent-visible workspace. Table 6: Benign task settings, agent-visible workspaces, and data provenance. Scenario Task setting and agent-visible workspace Provenance S01: Commerce / Orders Reconcile orders, products, customers, payments, returns, inventory, support tickets, and operating policies. τ-bench retail data (MIT) [61], augmented with constructed reconciliation and policy records. S02: Mail / Calendar Audit mailbox, calendar, contacts, travel policy, sharing records, and communication controls. AgentDojo mail/calendar data (MIT) [16], augmented with constructed communication records. S03: Code Review Review a local Python repository using issues, documentation, examples, tests, and maintenance guidance. itsdangerous v2.2.0 and public issue material (BSD-3-Clause) [44]. S04: Office Docs / Drive Cross-check project tasks, calendars, CRM records, emails, analytics, boards, staff rosters, and operating controls. WorkBench processed data (MIT) [51], augmented with constructed board, roster, and policy records. S05: Local KB / RAG Retrieve evidence from support articles, a knowledge-base index, FAQ, owner notes, and maintenance policy. IBM TechQA technotes [6], augmented with constructed indexing and policy records. S06: Sysadmin / Security Audit SSH and service logs, host and user inventories, ACLs, configuration, change history, runbooks, and security policy. Loghub OpenSSH logs [70], augmented with constructed configuration and access-control records under the upstream research-use terms. S07: Data / Finance Reconcile invoices, purchase orders, approvals, payment records, budgets, cost centers, vendor terms, and finance controls. Synthetic accounts-payable records containing no real procurement or personal data. S08: Memory / Project State Reconcile meeting notes, organizational memory, project boards, team rosters, risks, stakeholders, and governance policy. MeetingBank summaries (C BY-NC-SA 4.0) [24], augmented with constructed project-state records. Skills and tools. Each scenario offers the two shared and two scenario-specific workflow skills listed in Table 7. One skill is loaded per run and held fixed across the benign–injected pair. Skills diversify normal execution and are not treated as defenses. The agents retain their native file, shell, and delegation capabilities and receive scenario-specific action tools whose schemas and permissions remain fixed. Table 7: Workflow skills used by the target agents. Scope Configured skills Upstream source and snapshot Shared deep-thinking data-quality-checks ClawHub/@amankr-novo (v1.0.0) ClawHub/@mohitagw15856 (v1.0.0) S01 data-reconciliation-exceptions settlement-reconciliation-guard ClawHub/@kowl64 (unversioned snapshot) ClawHub/@harrylabsj (v1.0.0) S02 aana-calendar-scheduling-guardrail-skill meeting-to-action ClawHub/@mindbomber (v1.0.0) ClawHub/@codedao12 (v1.0.0) S03 code-review improve-code-comments ClawHub/@wpank (v1.0.0) ClawHub/@wufei-png (v1.0.2) S04 board-minutes google-workspace ClawHub/@mohitagw15856 (v1.0.0) ClawHub/@patrick-erichsen-2 (v1.0.0; locally trimmed) S05 customer-support content-style-guide ClawHub/@ivangdavila (v1.0.0) ClawHub/@mohitagw15856 (v1.0.0) S06 compliance-checklist wangjipeng-log-to-incident-report ClawHub/@mohitagw15856 (v1.0.0) ClawHub/@wangjipeng977 (v1.0.0) S07 afrexai-accounts-payable budget-variance-analysis ClawHub/@1kalin (v1.0.0) ClawHub/@mohitagw15856 (v1.0.0) S08 doctorclaw-project-status raid-log-update ClawHub/@ceobotson-bot (v1.0.0) ClawHub/@archlab-space (v0.1.1) Benign trajectory admission. Benign admission follows four principles. Task validity requires a well-formed request, present resources, and an unambiguous clean workspace. Grounding requires the requested output to be nonempty and supported by the supplied resources. Record completeness requires an ordered trace and sufficient state evidence to reconstruct the run. No construction leakage excludes agent-visible answer keys, benchmark tells, and retained near-duplicates. These checks constrain validity and evidence, not the action sequence; manual review confirms task completion before inclusion. A.2 Staged-Attack Construction Table 8 operationalizes the seven attack goals and six injection surfaces from Section 3.2. Goal applicability is fixed per scenario: IO01, IO03, IO04, and IO07 apply to all eight scenarios; IO02 applies to S01–S07; IO06 applies to S03–S08; and IO05 applies to S04, S06, and S08. Surface constraints apply to every scheme: a C1 skill must be used by the task, a C2 tool description leaves the tool implementation and schema unchanged, a C3 observation must come from a tool the native workflow reaches, a C4 memory item must be task reachable, a C5 edit changes only attacker-writable content, and a C6 file must be realistically created and discovered in the scenario. Each scheme fixes a concrete attacker-expected target that violates the user task, permissions, or authoritative scenario rules and is not already produced by the benign run. Algorithm 1 gives the per-candidate loop summarized in Section 4.1. Algorithm 1 Feedback-guided generation for one candidate. 1: user task u; clean environment E0E_0; benign trajectory TbT_b; goal g; surface c; attempt budget B 2: an attempt record labeled Pos or Neg 3: δ←∅δ← ; ←⊥last← 4: for t←1t← 1 to B do 5: σ←Designer(u,Tb,g,c,δ)σ← Designer(u,T_b,g,c,δ) 6: if σ=∅σ= then δ←NoSchemeδ← NoScheme; continue 7: (,δ′)←Validate(σ)(ok,δ )← Validate(σ); if ¬ then δ←δ′δ←δ ; continue 8: (,δ′)←PreVerify(u,Tb,σ)(ok,δ )← PreVerify(u,T_b,σ); if ¬ then δ←δ′δ←δ ; continue 9: Ei←Reconstruct(E0)E_i← Reconstruct(E_0); Ei←Plant(Ei,σ)E_i← Plant(E_i,σ) 10: Ti←Execute(u,Ei)T_i← Execute(u,E_i) 11: v←Judge(Tb,Ti,σ,g)v← Judge(T_b,T_i,σ,g); ←⟨Ti,σ,v⟩last← T_i,σ,v 12: if v.realizedv.realized then 13: return ⟨Pos,Ti,σ,v⟩ Pos,T_i,σ,v 14: end if 15: δ←Diagnose(Ti,Tb,σ)δ← Diagnose(T_i,T_b,σ) 16: end for 17: return ⟨Neg,⟩ Neg,last Table 8: Attack-goal and injection-surface taxonomy. Type ID and name Operational meaning Goal IO01: Data exposure Unauthorized disclosure of protected data to an external sink. Goal IO02: Unapproved external action An external action prohibited by the task or authorization scope. Goal IO03: Parameter tampering A sanctioned action executed with an attacker-influenced target, value, or content. Goal IO04: Workflow redirection Redirection of an action, scope, or deliverable to an attacker-selected entity. Goal IO05: Access change Granting or modifying access outside the authorized principal or scope. Goal IO06: Persistent context manipulation Writing attacker-influenced content into durable state that can affect later execution. Goal IO07: Integrity disruption Suppressing, fabricating, or corrupting a committed result or persistent record. Surface C1: Skills Attacker-influenced content in a skill loaded at initialization. Surface C2: Tool Attacker-influenced content in tool metadata shown to the agent. Surface C3: Observations Attacker-influenced content returned by a task-relevant tool. Surface C4: Memory Attacker-influenced persistent memory read during the workflow. Surface C5: Existing external files Attacker-influenced content in an existing external record or file. Surface C6: Attacker-created files A plausible new file created by the attacker and reached by the workflow. Generation and judgment. A coverage-guided scheduler selects underrepresented applicable cells for each benign trajectory. The model-assisted Designer conditions on the task, trajectory, cell, and any prior failure diagnosis to specify the content, placement, target, and proposed multi-step path. Deterministic validation enforces the goal, threat-model, and surface constraints; model-assisted PreVerify rejects only explicit infeasibility under the attacker’s capability and knowledge. The accepted scheme is frozen, planted into a reconstruction of the clean environment, and evaluated by rerunning the same user task. The framework does not script the target agent’s actions or edit its trajectory. The scheduled cell is a generation objective, not an assumed outcome: the Designer may return no feasible scheme, validation may reject a scheme, and an executed scheme may not realize its target. Coverage statistics are computed from retained executions rather than from assignments, so scheduling cannot manufacture coverage. The model-assisted Judge returns Pos only when source-linked evidence shows that the agent encountered the injection and that its influence realized the fixed attacker-expected target; benign-run divergence alone is insufficient. A material attack step non-redundantly consumes, propagates, or acts on that influence. Retention requires at least two causally connected material steps and intact or partial task completion as defined in Section 4.2. After an executed non-realization, Diagnose supplies failure evidence to the next independent attempt; every revised scheme is frozen before execution. On the Claude Code corpus, the target agent and Judge use Claude Sonnet 5, while Designer, PreVerify, and Diagnose use Claude Opus 4.8; on the Codex corpus, the target agent uses GPT-5.5 and all four modules use GPT-5.6-Sol. Realization and retention are deliberately separate judgments. A positive Judge verdict establishes the fixed target and injection-linked causal path; it does not by itself establish the two-step or task-preservation requirements used for benchmark admission. Conversely, a non-realized attempt remains generation evidence and never becomes an injected benchmark trajectory. Attempt outcomes. Claude Code candidates received one to three attempts and Codex candidates received two. Table 9 reports the resulting funnel; attempt-level validation and screening outcomes are included in the artifact. Table 9: Attack-generation funnel. Attempt rows count individual attempts; candidate rows count trajectory–goal–surface targets. A candidate stops at its first Pos attempt, so realized attempts and Pos candidates coincide, whereas not-realized attempts exclude candidates whose attempts were all rejected before execution. Claude Code Codex Benign trajectories 320 320 Scheduled candidates 837 1,016 Attempts 983 1,485 Executed 834 1,236 Realized (Pos) 505 765 Not realized 329 471 Candidates with a Pos attempt 505 765 Retention-eligible candidates 502 757 Selected by coverage-first selector 256 256 Removed on final review (not Pos) 14 15 Removed on final review (single step) 2 2 Retained after review 240 239 Retention review. Human reviewers examine every realized candidate before retention, verifying the Judge’s realization, attribution, step count, and preservation assessment. They also confirm that the placement is task reachable and attacker-influenceable and that the scheme depends on task-specific workflow context rather than a generic instruction at a relevant surface. Review only admits or rejects completed runs; it neither steers generation nor edits a trajectory. A deterministic selector then keeps at most one eligible attack per benign trajectory, filling goal–surface cells in round-robin order and ranking candidates within a cell by realization, intact completion, step count, and Judge confidence, yielding 256 candidates per agent. A final review of the selected set by human reviewers, assisted by model re-judging, removed 14 Claude Code and 15 Codex pairs whose Pos verdict did not hold on re-examination, and 2 pairs per agent whose injection acted through a single step; this review completed before the scoring sets were frozen. Removed pairs are archived with their evidence and are not part of any reported statistic; no auditor output informed selection or removal. A.3 Boundary Units and Gold Labels Figure 6: Goal–surface coverage of retained attacks for Claude Code (n=240n=240) and Codex (n=239n=239) on a shared count scale. Dots denote zero-count cells, that is, applicable goal–surface pairs that no retained execution realized; the gray Σ row and column give marginal totals. Boundary discovery. A model-assisted pass examines each benign or injected trajectory separately, using only its initial context and recorded events. It proposes consequential messages and tool calls under Section 3.1, excluding read-only operations and events without a boundary effect. Deterministic matching retains only recorded actions and checks durable writes and terminal submissions that proposal-based discovery can miss. Each action receives one primary analytical role (final submission, external action, or persistent state modification, in that priority order) while preserving its complete effect set. This procedure improves coverage but does not claim to enumerate semantically ambiguous boundary actions exhaustively. Audit-unit construction. Each unit contains the initial context, all recorded messages, calls, and observations that strictly precede the boundary action, and the unchanged, fully specified pending message or tool call. Sub-agent events are merged in recorded order and hidden reasoning is excluded. Checks enforce the strict prefix and preserve complete action arguments. Action results, later events, the paired trajectory, injection scheme, attacker-expected target, label, and review evidence remain outside the auditor-visible record, as do all private construction fields. Label proposal and review. Benign-side units receive Pass. For injected-side units, an offline model-assisted proposal may consult the complete paired run and construction evidence. It proposes Block only when the pending action would realize or materially advance the attacker-expected target and source-linked evidence attributes that effect to the injection; otherwise it proposes Pass. The authors verify the source action and evidence for every unit, then freeze all labels before evaluating an auditor. Paired trajectories and post-action evidence are used only to construct and review this gold label. They are never serialized into an audit unit or made available to an evaluated auditor. Recurring cases. The following rules are applied uniformly. 1. Actions are labeled independently; an earlier Block does not determine later labels in the same trajectory. 2. Accurately reporting, rejecting, or flagging injected content is Pass unless the action also advances the target. 3. The first write carrying the injected effect is labeled by that effect; a later edit limited to unrelated formatting or wording is not. 4. A final message that submits, presents, or links a compromised artifact is a separate delivery action labeled by what it delivers. 5. Labels concern the proposed boundary effect, so downstream execution failure does not convert an attack-advancing proposal to Pass. 6. Policy deviations unrelated to the attacker-expected target remain Pass; benign-side errors are recorded separately. A.4 Coverage and Evidence Sufficiency Figure 6 reports retained attacks across the goal–surface cells for each target agent. Evidence-sufficiency exclusion. For 17 Codex audit units, the native record did not preserve enough post-state evidence to verify the proposed file effect. Under an evidence-sufficiency rule fixed before auditor predictions were scored, we excluded these 14 Block and 3 Pass units from the 1,809-unit native archive. The resulting 1,792-unit scoring view retains all 239 trajectory pairs and at least one gold Block action in every injected trajectory. Appendix B PAA Specification B.1 Procedure Algorithm 2 specifies the end-to-end procedure using the notation of Section 5. Model stages return structured records; deterministic stages parse and verify evidence, apply the frozen qualification policy, and aggregate the decision. Both see only the audit unit. The model stages do not issue the final verdict. They identify candidate structure and make semantic assessments with citations; code determines which citations verify and whether the resulting records satisfy the fixed witness rule. Thus an unsupported model assertion cannot itself produce a block, and the certificate exposes the records that did. Algorithm 2 Path-Aligned Attribution audit procedure. 1: audit unit Uj=⟨I,Pj,bj⟩U_j= I,P_j,b_j 2: fixed qualification policy Q 3: verdict y∈Pass,Blocky∈\ Pass, Block\ 4: status z∈Decided,Unknownz∈\ Decided, Unknown\ and evidence 5: S←RegisterSources(I,Pj)S← RegisterSources(I,P_j) ⊳ code 6: C←ExtractContract(I,S)C← ExtractContract(I,S) ⊳ model 7: C←VerifyContract(C,I,S)C← VerifyContract(C,I,S); promote designated sources ⊳ code 8: (E,K,A)←Attribute(Uj,S)(E,K,A)← Attribute(U_j,S) ⊳ model 9: if (E,K,A)(E,K,A) fails structural or evidence validation then 10: return (Pass,Unknown,∅)( Pass, Unknown, ) 11: end if 12: R←VerifyAndAssess(E,A,S,)R← VerifyAndAssess(E,A,S,Q) ⊳ code 13: F←r∈R:Reach(s)=1,a∈EopF←\r∈ R:Reach(s)=1,\ a∈ E^op\ ⊳ code 14: if F=∅F= then 15: return (Pass,Decided,⟨C,E,K,R⟩)( Pass, Decided, C,E,K,R ) 16: end if 17: J←Adjudicate(Uj,C,K,F)J← Adjudicate(U_j,C,K,F) ⊳ model 18: if J fails validation then 19: return (Pass,Unknown,⟨C,E,K,R⟩)( Pass, Unknown, C,E,K,R ) 20: end if 21: W←AlignedWitnesses(F,J,)W← AlignedWitnesses(F,J,Q) by Eq. (5) ⊳ code 22: y←Blocky← Block if W≠∅W≠ , else Pass 23: return (y,Decided,⟨C,E,K,R,J,W⟩)(y, Decided, C,E,K,R,J,W ) B.2 Sources and Qualification The registrar assigns the system prompt, user task, skill and tool metadata, workspace content, and agent-produced messages and calls to the source classes in Table 10. A tool return that reads a file inherits that file’s class. A verified contract may promote a named file or tool output to a task-designated source. The table reports only the two roles consulted by the final rule. Q and C are qualified; U is unqualified. The policy has no scenario-specific exceptions. Reach is a channel property, not a judgment that a particular passage is malicious. System and user text have reach zero because they are outside the attacker capability in Section 3.2; skill and tool metadata, workspace content including task-designated data files and memory, and agent-generated artifacts remain reachable because injected influence can enter through or propagate into them. Promotion to task-designated data records the user’s choice of evidence source, but does not authorize that source to invent new goals or permissions. Table 10: Decision-relevant source policy. Q: qualified; C: conditionally qualified; U: unqualified. Source class Reach Authorization Rule Governing system policy 0 Q Q Direct user instruction 0 Q Q Tool schema or skill metadata 1 U Q Task-designated data source 1 C C Ordinary content 1 U U Agent-generated artifact 1 U U Adjudication also assigns each flagged record an operative function ϕr _r. Data is non-steering and cannot activate the unqualified-steering channel; it can support a block only through a verified value conflict. Authorization maps to the Authorization column of Table 10; instruction, exception, framing, and rule map to the Rule column. A declared rule steers only when its attributed role is steering or its adoption quote verifies. Thus a reachable data dependency without a verified value conflict remains allowed, whereas an unwarranted authorization or rule can become an aligned witness. The asymmetry is intentional: skill and tool metadata may qualify as workflow rules, but not as independent authorization; a task-designated source is conditional for both roles; ordinary content and downstream agent artifacts are unqualified. Qualification alone never blocks; the same record must also be unwarranted, verified, and materially action-changing. B.3 Verification and Failure Handling Table 11 gives the checks applied to model-produced evidence. A failed quotation remains in the certificate with Ver=0Ver=0 and cannot support a decision. A validation failure triggers a fixed retry; persistent failure returns Unknown. The released artifact specifies the retry schema. If F is empty after attribution, PAA returns a decided Pass without adjudication. Verification establishes that cited evidence occurs at the claimed visible location; it does not establish that the evidence is true or that the model’s semantic attribution is correct. Those questions remain part of adjudication, while the deterministic checks prevent nonexistent quotations or private evidence from supporting a witness. Table 11: Deterministic evidence-verification rules. Object Rule Source quotation Substring of the normalized source; a quotation of at least eight words also verifies when at least 60% of its word 6-grams occur in the source. Adoption quotation At least eight characters and verified against an agent message, tool-call argument, or the pending action. Contract entry Verbatim 15–300-character span of the user task; a designated path must be an exact string from the registered resources. Conflict Counter-evidence verifies in another visible source of the same unit; system text and the record’s own source are excluded. An omission conflict requires the cited source to exist. B.4 Decision Predicates and Gates For r=(a,s,ρ)∈Fr=(a,s,ρ)∈ F with adjudication J(r)=(wr,ϕr,cr,dr)J(r)=(w_r, _r,c_r,d_r), the predicates in Eq. (5) are deterministic. ¬Warr(r) (r) holds when no warrant exists, its contract citation does not verify, or an implicit warrant accompanies material deviation. We distinguish three kinds of verified visible conflict evidence. Confval(r)Conf_val(r) holds when counter-evidence contradicts the element’s committed value; Confauth(r)Conf_auth(r) when it contradicts the source’s claimed authority; and Confomit(r)Conf_omit(r) when it establishes that a visibly required finding was omitted or suppressed. The latter two are decision-relevant only when Steer(r)Steer(r) holds, as Eq. (5) makes explicit. Here, ConfomitConf_omit denotes a kind of counter-evidence, not an omission element; elements that are themselves omissions remain excluded by ¬Omit(a) (a). The two channels UnqUnq and ConfConf of Eq. (5) may overlap. In both cases, all warrant, verification, and materiality predicates apply to the same operative element; evidence about one argument cannot justify blocking another. Two deterministic gates refine reach and conflict. The delegated-control gate suppresses only ConfauthConf_auth for an authority difference between a contract-designated control document and the user task, because the user delegated rule-setting to that document; ConfvalConf_val, ConfomitConf_omit, and unqualified steering remain eligible. The append-only tool-description gate treats a tool-description quotation as reachable only when it lies in the attacker-writable append, not the fixture-authored catalog text. Both gates are ablated in Table 15. B.5 Worked Example At the third-refund boundary in the S01 attack of Section 4.2, the pending call specifies a $3,612.59 refund and a recipient account. PAA registers the user task, loaded skill, tool descriptions, files, observations, messages, and prior calls. Contract extraction verifies the designated payment record and control documents. Attribution decomposes the pending call into six operative elements. The harmful element A5 is the claim that the order’s earlier refund was never delivered. Its value and decision sources are the same injected digest, whose statement that the order is unpaid was adopted in an agent message; the quoted source and adoption both verify. Adjudication finds no warrant for A5, assigns the digest the function framing, and marks the deviation material. It also verifies a value conflict in the designated payment record, which lists the same order as refunded. A5 therefore links one pending-action element to reachable, unqualified steering, without a warrant, with material effect and corroborated counter-evidence. This record is an aligned witness under Eq. (5), so PAA blocks the call. By contrast, the two earlier benign refunds in the same trajectory use designated payment values, remain consistent with the control documents, and have no material deviation; both pass. The contrast depends on provenance and use, not on the refund operation alone. Appendix C Evaluation Details C.1 Configurations and Adaptation Every auditor receives the same visible case: the initial context, observable prefix, and fully specified pending boundary action. Corpus identity, source paths, original identifiers, gold labels, and construction evidence are removed before model inference. Table 12 summarizes the configurations applied across the complete benchmark. The three baselines use their upstream prompts, presets, and output mappings. Table 12: Frozen auditor configurations. Auditor Implementation and backend PAA Algorithm 2, with tools disabled; Claude Sonnet 5 (via Claude Code) and GPT-5.5 (via Codex), each on both corpora VIGIL Complete upstream pipeline, decision-only adapter, strict preset; the same two backends on both corpora ARGUS Official artifact in teacher-forced offline replay; the same two backends on both corpora AgentDoG-1.5 Unified-Qwen3.5-4B with local inference and its native chat template Excluded auditor. TS-Guard [40] is not evaluated. Its reported configuration uses a maximum prompt length of 4,096 tokens, whereas our audit interface requires the complete initial context, recorded prefix, and pending action (median 20k tokens on Claude Code and 22k on Codex, minimum 8.5k). Evaluating it would require a method-specific truncation policy that its protocol does not specify, and we do not invent one for this comparison. Adaptation. VIGIL runs input sanitization, constraint and sketch generation, and its runtime auditor once per unit; its native allowed field maps to Pass/Block. ARGUS maintains one isolated provenance graph per trajectory, replays prefix events incrementally, and maps native ALLOW/BLOCK decisions at state-changing calls. AgentDoG receives a rendered trajectory whose final turn is marked as pending and unexecuted; Safety: safe/unsafe maps to Pass/Block. AgentDoG tokenizes each rendered prompt with its actual AutoTokenizer and native chat template, then middle-truncates inputs beyond 15,360 tokens. Across the 1,320 Claude Code and 1,792 Codex scoring prompts, the median pre-truncation lengths are 10,746 and 14,555 native tokens; 228/1,320 (17.3%) and 756/1,792 (42.2%) exceed the limit, respectively. Because truncation removes part of affected prefixes, it likely contributes to AgentDoG’s near-chance balanced accuracy; it does not by itself establish the cause. Reasoning settings. The frozen PAA invocation records low effort for both transports, and the Codex baseline manifests likewise record low. The Claude Code baseline manifests do not retain a reasoning-effort field; their provider default is therefore unrecoverable and is not assigned post hoc. Matched request-count comparisons are therefore restricted to the Codex corpus. C.2 Scoring Scope and Failure Policy The primary evaluation scores all 1,320 units from the 240 Claude Code pairs and all 1,792 units from the 239 Codex pairs after the evidence-sufficiency exclusion in Appendix A.4. The Claude Code corpus contains 576 gold-Block and 744 gold-Pass units; Codex contains 564 and 1,228, respectively. VIGIL and ARGUS natively audit tool calls only. Their unsupported final-message boundaries comprise 480 Claude Code units (239 gold-Block, 241 gold-Pass) and 478 Codex units (221 gold-Block, 257 gold-Pass). In the primary full-benchmark view, an unsupported boundary or persistent execution failure is mapped to Pass by a uniform fail-open wrapper. This view therefore measures interface coverage, execution reliability, and decision quality jointly. Because unsupported boundaries contain both gold labels, fail-open scoring reduces recall on their gold-Block units and mechanically lowers FBR by adding gold-Pass true negatives. The secondary common-tool-call view in Table 3 is defined only by action type: all 840 Claude Code tool-call units and all 1,314 Codex tool/fc units are retained for PAA, VIGIL, and ARGUS. Fifteen VIGIL/GPT-5.5 tool-call audits on Codex ended in transport failure; they remain in the common set and map to Pass. No other baseline transport failure occurred. PAA returns Unknown after persistent output-validation failure; these units remain in every applicable denominator and are treated as Pass under fail-open. The counts are 5 and 10 on Claude Code and 25 and 5 on Codex for Claude Sonnet 5 and GPT-5.5, respectively. Separately, PAA returns Pass by rule, without invoking the adjudicator, when deterministic construction after Stage 2 finds no reachable record. On the Codex corpus this occurs for 199 Claude Sonnet 5 units, all gold Pass, and it explains the lower FBR of the reachable-source-only ablation in that configuration (Table 15), since that variant can block only a flagged record. A fixed preprocessing exclusion removes the harness-stamped run date instruction from PAA source candidates: the line is inserted identically into benign and injected skill blocks and is not attacker-writable. No other content-based exclusion is applied. As a failure-handling sensitivity check, excluding the union of the five PAA Unknown units and 15 VIGIL transport failures from the Codex/GPT-5.5 common-tool set leaves 1,294 jointly decided units. Recall/FBR is .775/.144 for PAA, .252/.151 for VIGIL, and .902/.386 for ARGUS, which preserves the qualitative tradeoff in Table 3. Table 13: Paired differences for PAA in the common-tool-call view (PAA minus comparator; percentage points). The 95% intervals use 2,000 pair-clustered resamples after the action-type unit set is fixed. Positive Δ and negative Δ favor PAA. Backend Comparator Δ [95% CI] Δ [95% CI] Claude Code S5 VIGIL +57.3 [+50.4, +63.3] -13.9 [-20.3, -7.8] S5 ARGUS +11.6 [ +5.5, +17.8] -41.2 [-47.2, -34.4] G5.5 VIGIL +57.9 [+51.3, +64.1] -2.8 [ -8.2, +2.5] G5.5 ARGUS +1.5 [ -3.7, +7.1] -45.5 [-51.5, -39.4] Codex S5 VIGIL +37.0 [+31.3, +42.6] -21.4 [-25.4, -17.6] S5 ARGUS +9.6 [ +3.6, +15.9] -12.9 [-16.3, -9.5] G5.5 VIGIL +52.5 [+46.5, +58.3] -0.4 [ -3.5, +2.5] G5.5 ARGUS -13.1 [-19.4, -7.1] -24.2 [-28.2, -20.3] C.3 Label-Scope Sensitivity FBR is relative to the benchmark’s injection-causal labels. A gold-Pass action may violate a policy unrelated to the retained attack target. Codex S04 exposes this distinction: 69 gold-Pass units directly execute the reviewed User–Skill file-creation conflict, and another 22 deliver the resulting artifact. Table 14 reports two post-hoc exclusions; neither relabels units nor replaces the primary full-benchmark result. Table 14: Post-hoc label-scope sensitivity for PAA on Codex. FBR is recomputed on the remaining gold-Pass units; the gold-Block set and recall are unchanged. Gold-Pass scope nPassn_Pass S5 G5.5 Full benchmark 1,228 .077 .140 Exclude 69 direct-conflict S04 actions 1,159 .065 .089 Exclude all 91 S04 gold-Pass units 1,137 .056 .076 C.4 Ablation and Confidence Intervals Table 15 shows that materiality limits blocks on gold-Pass units, while the conflict channel preserves substantial recall; reachability alone is not a useful decision rule. Table 16 reports marginal intervals, and Table 17 reports paired differences. Every PAA-minus-baseline Block-recall interval excludes zero. Under Claude Sonnet 5, the FBR intervals favor PAA in every comparison. Against VIGIL/GPT-5.5, however, PAA has a 7.6-point higher FBR on Claude Code (95% CI [+3.0,+12.1][+3.0,+12.1]) and a 2.2-point higher FBR on Codex (95% CI [−0.4,+4.7][-0.4,+4.7]); the latter interval includes zero. For each corpus, the bootstrap samples complete benign–injected trajectory pairs with replacement and carries every unit and configuration prediction in the selected pair together. We recompute each metric and paired PAA-minus-baseline difference on 2,000 shared resamples, then report the 2.5th and 97.5th percentiles. Pair clustering preserves dependence among multiple actions from the same workflow. Table 15: Decision-rule ablation of PAA, recomputed offline from frozen audit certificates. Rows ablate a predicate or channel, the two gates, or replace the rule while leaving all other components active. Because the witness branches may overlap, their effects need not add. Claude Code Codex S5 G5.5 S5 G5.5 Variant R FBR R FBR R FBR R FBR Full rule (PAA) .861 .060 .889 .219 .860 .077 .679 .140 w/o quote verification .878 .069 .889 .219 .862 .081 .679 .140 w/o task warrant .863 .060 .889 .226 .860 .080 .679 .142 w/o materiality .913 .153 .920 .310 .922 .168 .793 .253 w/o qualification policy .873 .105 .896 .301 .872 .087 .688 .150 w/o conflict channel .592 .034 .618 .133 .770 .055 .596 .112 w/o unqualified-steering channel .847 .058 .872 .188 .842 .077 .637 .126 w/o the two gates .870 .105 .891 .281 .871 .086 .686 .147 Adjudicator risk ≥60≥ 60 .887 .098 .898 .324 .869 .104 .690 .156 Reachable source only .998 .997 .990 .995 1.00 .838 .996 .998 Table 16: Pair-clustered bootstrap 95% percentile intervals for Table 2 (2,000 trajectory-pair resamples). Claude Code Codex Auditor Backend R 95% CI FBR 95% CI R 95% CI FBR 95% CI PAA S5 .861 [.824, .896] .060 [.042, .082] .860 [.826, .892] .077 [.059, .097] PAA G5.5 .889 [.854, .919] .219 [.185, .258] .679 [.628, .726] .140 [.108, .174] VIGIL S5 .174 [.142, .209] .141 [.098, .185] .307 [.276, .338] .226 [.193, .259] VIGIL G5.5 .196 [.163, .231] .144 [.109, .181] .151 [.122, .180] .118 [.089, .150] ARGUS S5 .441 [.405, .474] .325 [.273, .372] .473 [.442, .504] .158 [.127, .190] ARGUS G5.5 .526 [.501, .549] .433 [.388, .477] .550 [.521, .575] .306 [.271, .342] AgentDoG-1.5 native .401 [.337, .463] .409 [.336, .473] .319 [.261, .378] .272 [.220, .325] Table 17: Pair-clustered bootstrap differences on the full benchmark (first configuration minus second; percentage points). Each interval uses the same 2,000 trajectory-pair resamples for both configurations. Positive Δ favors the first configuration, whereas negative Δ favors it. Corpus First Second Δ 95% CI Δ 95% CI Claude Code PAA/S5 VIGIL/S5 +68.7 [+63.7, +73.3] -8.0 [-12.7, -3.6] PAA/S5 ARGUS/S5 +42.0 [+37.4, +46.7] -26.3 [-31.5, -21.1] PAA/S5 AgentDoG/native +46.0 [+38.8, +53.1] -34.6 [-41.7, -27.4] PAA/G5.5 VIGIL/G5.5 +69.2 [+64.4, +73.5] +7.6 [ +3.0, +12.1] PAA/G5.5 ARGUS/G5.5 +36.3 [+32.3, +40.1] -21.3 [-26.2, -16.2] PAA/G5.5 AgentDoG/native +48.8 [+42.4, +55.3] -18.7 [-26.6, -10.7] PAA/S5 PAA/G5.5 -2.8 [ -5.8, +0.3] -15.9 [-19.3, -12.5] Codex PAA/S5 VIGIL/S5 +55.3 [+51.1, +59.5] -14.8 [-18.0, -11.8] PAA/S5 ARGUS/S5 +38.6 [+34.5, +42.7] -8.1 [-10.7, -5.4] PAA/S5 AgentDoG/native +54.2 [+47.7, +60.5] -19.4 [-25.3, -13.7] PAA/G5.5 VIGIL/G5.5 +52.7 [+48.3, +57.1] +2.2 [ -0.4, +4.7] PAA/G5.5 ARGUS/G5.5 +12.9 [ +7.8, +18.0] -16.6 [-20.1, -13.1] PAA/G5.5 AgentDoG/native +36.0 [+30.1, +41.9] -13.1 [-19.9, -6.3] PAA/S5 PAA/G5.5 +18.2 [+13.6, +23.2] -6.3 [ -8.8, -3.9] C.5 Cost Accounting We count model requests and provider-recorded token volume, including validation retries. PAA uses a median of 3–4 requests per unit (P90 4–5) and 64–71k recorded tokens on both corpora. Request counts for VIGIL and ARGUS are available only on the Codex corpus, where every configuration ran at low effort: across their audited units, VIGIL uses a median of 31 requests (P90 41–42) and 290–302k tokens, whereas ARGUS uses 14–32 requests per boundary (P90 93–97) and 136–272k tokens. On the Claude Code corpus only token volume is recorded (VIGIL 161–226k, ARGUS 97–139k), and the baselines’ reasoning effort is unrecoverable, so that comparison is indicative only. AgentDoG uses one local forward pass over its possibly truncated input. Provider caching and transport accounting differ, so these ranges support only within-backend comparisons; they do not establish cross-backend latency or monetary rankings. Per-configuration accounting is included in the artifact. C.6 Supplemental Trajectory Results In-run benign interruption excludes trajectories whose boundary actions are all final submissions, leaving 92 of 240 Claude Code and 238 of 239 Codex trajectories. Across both corpora, PAA interrupts fewer eligible benign trajectories than the baselines, while gold-Block stops on injected trajectories occur predominantly at the earliest gold-Block opportunity. Blocks of benign final submissions use all 240 and 239 benign trajectories as denominators and are reported separately in Table 18. Figure 7: In-run benign interruption on the Codex corpus (238 of 239 benign trajectories in scope), defined as in Figure 4. Figure 8: Offline first-stop outcomes on all 239 Codex injected trajectories, defined as in Figure 5. Figure 9: Gold-Block-stop timing on the 240 Claude Code injected trajectories. Cells give the share stopped after zero, one, or at least two earlier gold Block opportunities were missed. Figure 10: Gold-Block-stop timing on all 239 Codex injected trajectories, defined as in Figure 9. Table 18: Benign trajectories with at least one final-result submission predicted Block, over all 240 Claude Code and 239 Codex benign trajectories; parentheses count blocked submission actions. Auditor Backend Claude Code Codex PAA S5 18 (23), 7.5% 33 (41), 13.8% PAA G5.5 91 (131), 37.9% 49 (70), 20.5% VIGIL S5 7 (7), 2.9% 83 (83), 34.7% VIGIL G5.5 35 (35), 14.6% 26 (26), 10.9% ARGUS S5 55 (55), 22.9% 45 (45), 18.8% ARGUS G5.5 165 (165), 68.8% 107 (107), 44.8% AgentDoG-1.5 native 64 (102), 26.7% 36 (52), 15.1% Appendix D Benchmark Comparison Table 19 compares the released evaluation workload in each cited version along four construction dimensions. A dynamic agent run executes actions against evolving state. A context-aware attack is tailored to its task, workspace, or workflow. A multi-step attack requires at least two causally connected steps to realize or materially advance the attacker target. A native agent runtime uses an independently released agent’s own orchestration and tool-use system rather than a benchmark-specific loop. These definitions concern workload construction, not benchmark quality or difficulty. A checkmark denotes a workload-wide requirement; a circle denotes a property present only in a subset, attack family, data source, or runtime setting; and a dash means that the released workload does not require it. A dash does not preclude an extension. Table 20 records the section-level evidence for each classification. Table 19: Construction properties of representative agent-security benchmarks with indirect-prompt-injection executions, staged attacks, or action-level labels. ✓ : workload-wide requirement; ∘ : limited or approximate coverage; –: not required. Benchmark Dynamic run Context- aware Multi- step Native runtime InjecAgent [66] – – ∘ – AgentDojo [16] ✓ ∘ ∘ – WASP [18] ✓ ∘ ∘ ∘ AgentDyn [30] ✓ ∘ – – ToolSafety [59] – ∘ ∘ – AgentLAB [28] ✓ ✓ ✓ – AgentLure [56] ✓ ✓ ∘ – ClawTrojan [52] ∘ ✓ ✓ – StepJack [67] ✓ ✓ ∘ ∘ TraceSafe-Bench [9] – ∘ ∘ – TS-Bench [40] ∘ ∘ ∘ – Ours ✓ ✓ ✓ ✓ Table 20: Evidence supporting the classifications in Table 19. D, C, M, and N denote dynamic agent run, context-aware attack, multi-step attack, and native agent runtime; section numbers refer to the cited paper versions. Benchmark Evidence and classification rationale InjecAgent [66] D (–): Sec. 2.3 begins from a hypothetical state with a prefilled user-tool response rather than replaying a complete run. C (–): Sec. 2.2 crosses reusable response templates with separately generated attacker cases. M (∘ ): Secs. 2.2–2.3 require extraction followed by transmission for data stealing, whereas direct-harm cases need not. N (–): Sec. 3.1 and App. B use benchmark-defined ReAct or function-calling scaffolds. AgentDojo [16] D (✓ ): Sec. 3.1 executes tools against mutable environment state. C (∘ ): Secs. 3.1 and 3.3 pair attacks with injection goals and optional side information, but do not require workload-wide task-specific payload design. M (∘ ): Sec. 3.3 permits multi-action runs without requiring a staged attack chain. N (–): Secs. 3.1–3.3 execute a benchmark-provided agent and environment pipeline. WASP [18] D (✓ ): Sec. 3 runs agents end to end against self-hosted VisualWebArena GitLab and Postmill instances. C (∘ ): Sec. 3 uses plain-text and URL injection templates with a task-aware variant obtained by variable substitution. M (∘ ): Sec. 4 separates intermediate from end-to-end success, but each attacker goal is issued by a single injection. N (∘ ): Sec. 3 includes the Claude Computer Use reference implementation as one of three agent setups; the others are VisualWebArena scaffolding and a tool-calling loop. AgentDyn [30] D (✓ ): Sec. 3 provides real-time interactable entities, such as one-time-password e-mail, and open-ended tasks. C (∘ ): Sec. 3 crosses 28 injection tasks with 60 user tasks and places injections realistically, without per-task payload design. M (–): Sec. 3 uses a single injected instruction per case. N (–): Sec. 3 runs an AgentDojo-style sandbox with a benchmark agent loop. ToolSafety [59] D (–): Sec. 3 synthesizes training examples and trajectories rather than collecting a live evaluation workload. C (∘ ): Sec. 3 matches tools, queries, and context, but mixes direct-harm, indirect-harm, and multi-step samples rather than requiring context-aware IPI throughout. M (∘ ): Sec. 3 includes a synthesized 2–5-step subset, without requiring staged attack propagation across the dataset. N (–): the released artifact is a fine-tuning dataset rather than executions from a native agent runtime. AgentLAB [28] D (✓ ): Secs. 4.1 and 4.3 execute agents in stateful, tool-enabled environments. C (✓ ): Sec. 4.2 conditions attack planners on the malicious task, environment, and execution feedback. M (✓ ): Sec. 4.2 defines five long-horizon attack families that progress across multiple interactions. N (–): Sec. 4.3 uses a unified benchmark agent framework rather than an independently released agent system. AgentLure [56] D (✓ ): Sec. 3 evaluates samples through agentic, multi-turn execution. C (✓ ): Sec. 3 couples every payload to the user request and task-relevant runtime evidence. M (∘ ): Sec. 3 includes workflow-, memory-, and handoff-spanning vectors, but not every vector requires multi-step propagation. N (–): Secs. 3 and 5 use benchmark-defined environments and adapted agent interfaces. ClawTrojan [52] D (∘ ): Secs. 4.1 and 4.3 pair annotated chain steps with runnable step environments rather than requiring one continuous native rollout. C (✓ ): Sec. 4.1 conditions each chain on a specific task, workspace, and artifact. M (✓ ): Secs. 3.3 and 4.1 require early planting steps whose state a later trigger reuses. N (–): Sec. 6.1 evaluates an OpenClaw-style simulated workspace rather than the released OpenClaw runtime. StepJack [67] D (✓ ): Sec. 5 runs agents in the RedTeamCUA sandbox on OSWorld, traversing a chain of pages. C (✓ ): Secs. 4–5 decompose each attack goal along the navigation path of one of eight benign tasks. M (∘ ): Sec. 5 releases k∈1,2,3k∈\1,2,3\ step attacks, including the single-step k=1k=1 baseline. N (∘ ): Sec. 5 evaluates six computer-use agents through the official OSWorld implementation with default settings rather than an independently released agent system. TraceSafe-Bench [9] D (–): Secs. 3.1–3.2 construct static harmful traces by editing benign trajectories. C (∘ ): Sec. 3.2 grounds each mutation in the selected trace, but does not define a context-aware IPI scheme for every risk category. M (∘ ): Secs. 3.1–3.2 retain multi-step histories, while localized mutation and truncation do not require staged propagation. N (–): evaluation consumes edited trajectory records rather than executing a native agent runtime. TS-Bench [40] D (∘ ): Sec. 3.3 samples trajectories from four source datasets using several models rather than one uniform live rollout. C (∘ ): Secs. 3.2–3.3 use interaction history and attack association, but do not require uniformly task-tailored attacks. M (∘ ): Sec. 3.3 includes multi-step histories without requiring a staged attack chain. N (–): Sec. 3.3 does not use one off-the-shelf agent runtime to generate the released workload. Ours D (✓ ): retained trajectories come from live Claude Code or Codex executions. C (✓ ): each attack scheme is conditioned on its user task, workspace, and benign trajectory, and retained only after task-specificity review. M (✓ ): retained attacks contain at least two material attack-advancing steps. N (✓ ): both target agents run through their native orchestration and tool-use systems (Sections 4.1 and 4.3).