PaperlayerView exact revision on arXiv

Source-linked AI summary

ROPE: Routed Origin Policy Enforcement against Indirect Prompt Injection

Xinhang Ma, Chaowei Xiao, William Yeoh, Ning Zhang, Yevgeniy Vorobeychik

arXiv:2608.27496v1cs.CR

TL;DR

Indirect prompt injection can steer runtime-read content into attacker-chosen values passed to state-changing tools, while delegated runtime steps limit what preplanned defenses can anticipate. ROPE applies deterministic origin checks to sensitive parameters and reports low attack success while retaining much of undefended clean utility across four agent models.

  • Problem

    Runtime delegation limits how reliably defenses fixed before content arrives can distinguish legitimate from harmful actions, while indirect prompt injection can steer attacker-chosen values into state-changing tools.

    Source: §1 · pp. 1–2

  • Method

    ROPE uses deterministic origin checks on sensitive parameters, trusting values traced to the user, a user-named source, or authoritative records, with a router that reads only the request.

    Source: §1 · p. 2

  • Results

    1.6–2.6% attack success rate while retaining 82–100% of undefended clean utility, with ROPE high-utility and low-ASR across all four evaluated models.

    Source: §4.1 · p. 7

  • Takeaways & Limitations

    ROPE's guarantees support treating indirect prompt injection defense as provenance enforcement, including protection against attacker-writable content reaching guarded parameters and rewording changing admission decisions.

    Source: §8 · p. 13

    ROPE guards tool calls, not harmful content in the agent’s message to the user, so message-only harms remain outside its enforcement.

    Source: §5 · p. 11

Abstract

from arXiv · show

Indirect prompt injection (IPI) plants instructions in the content a tool-using LLM agent reads, steering the agent into harmful tool calls. The strongest defenses are system-level, leveraging techniques such as task-conditional tool screening to prevent execution of malicious tools, and information-flow control to avoid tool execution with untrusted parameters. However, as agents grow more capable, users delegate more to automation. Consequently, tool execution sequences and parameter values are increasingly determined at runtime and cannot be reliably screened from solely user's query without significant utility loss. We present ROPE (Routed Origin Policy Enforcement), which is anchored in a structural notion of trust: a value may reach a state-changing tool only if it traces unforgeably to the user, a source the user explicitly named, or the user's own authoritative records. Enforcement is then a deterministic origin check over an audited set of sensitive tool parameters, and the only reliance on a language model involves solely the trusted user request, out of the attacker's reach. Our approach admits two provable guarantees: 1) at every step of a trajectory, no value whose only origin is attacker-writable content reaches an origin-guarded parameter, and 2) no rewording of an injection changes an admission decision. We evaluate across four agent models on open-ended agent suites, ROPE holds attack success rate to 1.6--2.6\% while retaining 82--100\% of undefended clean utility, significantly exceeding state-of-the-art system-level defenses in utility while attaining comparable or better security. Further, we show that optimizing the injection against ROPE is largely ineffective, while long-horizon attacks that defeat prior system-level defenses achieve zero success rate. Our code and logs are available at https://github.com/xhOwenMa/ROPE .

1 Introduction

Indirect prompt injection is dangerous when attacker-written values reach state-changing tools, while defenses fixed before runtime content arrives force a security–utility tradeoff. ROPE instead enforces trusted origins structurally, adapting trust to what the user delegates.

Threat model

  • IPI causes harm when attacker-written values reach state-changing tools, either inducing an unrequested action or corrupting one the user wanted.The harmful value may be passed to a tool that sends, pays, or deletes; read-only tools only return information.Source: §1 · p. 1

Evaluation

  • ROPE is the only defense in the evaluation’s favorable utility–security region, with low attack success and high utility across evaluated environments.Figure 1 shows the comparison for AgentDyn with GPT-4o-mini; the ordering is unchanged across all four agent models.Source: Figure 1 · p. 2, §1 · p. 3

Motivation

  • On AgentDyn’s open-ended tasks requiring runtime replanning, strongest system-level defenses achieved 18.3% completion for DRIFT and 6.7% for Progent, versus 46.7% clean utility without defense; information-flow PFI achieved 15.0%.Source: §1 · p. 2

Trust model

  • ROPE permits a value to reach a state-changing tool only when its origin traces unforgeably to the user’s request, a user-named source, or the user’s authoritative records.These origins rely on structural properties, such as verifiable sender identity or platform-maintained records, rather than model planning.Source: §1 · p. 2

Enforcement

  • ROPE checks an audited set of sensitive tool parameters deterministically and uses structural-origin tracking, avoiding LLM enforcement and plan-conformance checks.The checked parameters are identified from tool schemas offline; benign deviations such as extra reads or reordered steps are not penalized.Source: §1 · pp. 2–3

Policy routing

  • A router reads only the trusted request to set task-specific accepted origins, while audited default origins provide a floor it cannot relax.This adapts enforcement to how much the user delegates without allowing injected content to steer the policy.Source: §1 · p. 2

Guarantees

  • ROPE guarantees that attacker-only-origin values never reach guarded parameters at any trajectory step and that injection paraphrasing cannot change admission decisions.The paper states these guarantees hold under mild conditions.Source: §1 · p. 3

2 System and Threat Model

The section models an LLM agent that reads outside content and acts through tools, then defines the attacker’s capabilities, trustworthy origins, and task scope for defense.

2 System and Threat Model

  • Indirect prompt injection plants malicious instructions in data the agent reads to steer tool calls, with harmful effects realized through state-changing actions such as sending, paying, or editing.The workflow also uses read-only tools to retrieve outside content; the model, architecture, and alignment training are unspecified.Source: §2 · p. 3
  • The attacker may inject content into any ingested channel except the user’s query and authoritative records, but cannot forge origins or introduce malicious tools or descriptions.The defense is not assumed secret, and the attacker may adapt injections based on observed success.Source: §2 · p. 3
  • A value is trustworthy only when its trace has both integrity and authorization, through the user’s request, a user-referenced authenticated source, or the user’s own authoritative records.T3 records must be written only by the user’s authenticated actions, be unreachable by agent-read-triggered writes, and contain only origin-checked values.Source: §2 · p. 3
  • Requests are fully specified, parameter-open, or action-open; leaving more unspecified expands the legitimate value origins and the task’s irreducible attack surface, following AutoDojo [24].The defense operationalizes these categories as a per-parameter binary question.Source: §2 · pp. 3–4
  • The defense must block harmful state-changing calls carrying attacker-chosen sensitive parameters or attacker-induced unrequested actions while preserving successful completion of regular requested tasks.Source: §2 · p. 4

3 Design of ROPE Defense

ROPE audits sensitive parameters once, then uses task-specific trust policies and deterministic origin checks to govern state-changing calls. Under stated deployment assumptions, it guarantees that attacker-only-origin values cannot reach guarded parameters and that paraphrasing does not change admission decisions.

3.1 Overview

  • ROPE performs a one-time audit of state-changing tools and sensitive parameters, then routes each trusted request, compiles a per-task policy, and deterministically checks calls at runtime.The router reads only the user’s request; an origin tracker labels values, and read-only calls always pass.Source: §3.1 · p. 4

3.2 Conditioning on under-specification

  • ROPE conditions each sensitive parameter’s trust marker on task under-specification, from request-only PROMPT through SOURCED and RECORD to delegated free-text FREE.Structural DEST blocks writes into credential or system stores unless the request names the path, while EXPLICIT requires request authorization for irreversible actions; deployments may set a default marker floor.Source: §3.2 · p. 4

3.3 Structural origin attribution

  • The tracker labels values from verified platform identities as T2, treats undivided files and web pages as injectable, and labels authoritative user records T3.At enforcement, list parameters require every element to be trusted, and matching uses the whole decision unit, preventing extra injected elements or hostile wrappers from passing.Source: §3.3 · p. 5

3.4 Theoretical analysis

  • Under A1–A3, ROPE guarantees every admitted origin-guarded value traces to T1, T2, or T3, so attacker-only-origin values never reach guarded parameters.The guarantee concerns origin, not intent: when a legitimate value itself comes only from attacker-writable content, ROPE refuses it along with injected values.Source: §3.4 · p. 6
  • Under router isolation and deterministic enforcement, paraphrases containing the same values with the same origins cannot change ROPE’s admission decisions.This bounds the defense, not the agent: rewording may still steer which calls the agent attempts.Source: §3.4 · pp. 6–7

4 Evaluation

Across four agent models, ROPE combined low attack success with high clean utility, and its origin-based enforcement remained effective under adaptive and long-horizon attacks. The evaluation also tested how task routing and router quality affect that security–utility balance.

4 Evaluation

  • ROPE was evaluated on six AgentDyn and AgentDojo suites using clean completion, attacked completion, and attack success rate.The study compared four agent models against 11 baseline defenses; three proxy-scored injection tasks were rescored by environment effect for every defense and model.Source: §4 · p. 7

4.2 Trace analysis

  • Across three delegated clean tasks, ROPE completed all three without constraining benign runtime deviations, unlike DRIFT’s refusals and PFI’s masking.In one task, PFI’s masking led the agent to fabricate an email address.Source: §4.2 · p. 7, Table 1 · p. 8

4.1 Comparison to baseline defenses

  • 1.6–2.6% ASR with 82–100% of undefended clean utility made ROPE the only high-utility, low-ASR defense across all four models.ROPE also exceeded DRIFT, the strongest prior system-level defense, by 7–25 CU points at comparably low ASR; its under-attack completion tracked the undefended agent’s.Source: §4.1 · p. 7, Figure 3 · p. 8

4.3 Robustness to adaptive attacks

  • ROPE’s origin-based admission was invariant to optimized injection wording, while runtime-behavior defenses such as DRIFT were steered into higher ASR.Optimization shifted DRIFT’s overall ASR from 3.4 to 7.4 on GPT-4o-mini, 2.8 to 5.4 on Gemini-2.5-Flash, and 7.1 to 28.5 on Qwen3-235B; PFI’s low ASR came with only 5–15 clean utility, versus ROPE’s 25–53.Source: §4.3 · pp. 7–9, Table 2 · p. 9

4.4 Robustness to long-horizon attacks

  • 0.0 long-horizon ASR on every suite across all three models let ROPE retain under-attack utility close to the undefended agent.For GPT-4o-mini, ROPE’s UA was 40.9 versus 44.0 for the undefended agent; cases were aggregated per matched case because suite coverage was uneven.Source: §4.4 · pp. 9–10, Table 3 · p. 10

4.5 Conditioning on under-specification

  • Routed and strict policies each had 1.8 ASR, but routed CU was 43.3 versus 26.7 for strict; loose CU was 43.3 and loose ASR was 44.0.The strict policy blocked legitimately delegated values, while the loose policy admitted values already present in the environment.Source: Table 4 · p. 10, §4.5 · p. 10

4.6 How cheap can the router be?

  • 6.0 to 0.0 ASR on Gemini-3-Flash’s attacked suites showed the clamp removing over-loosening successes without reducing clean utility.Across cheaper routers, clamped ASR was 1.7 and 2.6 versus 1.5 for Opus, while CU was 40.0 and 38.3 versus 43.3. The clamp rejects overrides looser than the audited per-parameter default, bounding any router’s security risk; noisier tightening can reduce utility.Source: §4.6 · pp. 10–11, Table 5 · p. 11

5 Failure Analysis

ROPE’s residual attacks exploit harms that fall outside its origin-guarded tool parameters, while clean-task failures arise both from the agent and from conservative ROPE denials. The analysis identifies request specification and platform-certified content as ways to address some residual harms, and stable identifiers as a way to reduce strictness costs.

Residual attack success

  • 90 residual static-attack successes split into 23 message-only cases, 21 in-band content cases, and 46 delegated-parameter cases; none had a trusted identifier for the harmful parameter.Table 6 classifies these residual successes by the channel carrying the harm.Source: Table 6 · p. 11, §5 · p. 11
  • All three residual-attack classes fall outside Proposition 1: message-only harm uses no tool call, while the other harms occupy parameters ROPE does not origin-guard.More-specified requests can avoid delegated-parameter cases; platform certification of content alongside identity could address in-band content, while message-only harm is beyond tool-level defenses.Source: §5 · p. 11

Clean task failures

  • 199 of 411 clean tasks fail across benchmarks and models; 73 failures are attributable to ROPE, while 126 involve no denied tool call and predominantly reflect agent failures.These agent failures predominantly occur when the defense is not deployed.Source: §5 · pp. 11–12
  • ROPE-caused clean failures arise from fail-closed delegated values or strict matching that rejects paraphrased phrase parameters; stable identifiers could reduce the latter cost.Table 7 shows a payment refused because the payee appears only in the bill and an in-band attack whose message body carries a phishing link.Source: §5 · p. 12, Table 7 · p. 12

6 Discussion

ROPE argues that attackers cannot reliably craft an injected value that both matches the user’s request and benefits them, while its guarantees depend on deployment assumptions and provenance-aware infrastructure. The discussion frames those assumptions as bounded platform and enumeration requirements and identifies uneven provenance coverage as a deployment limitation.

Discussion

  • An attacker cannot reliably choose an injected value that both matches the user’s request and advances its objective, because admission routes the action to a structurally trusted destination.The attacker lacks knowledge of the user’s request, and ROPE’s decision-unit matching makes admission and attacker gain conflict.Source: §6 · p. 12
  • Origin soundness depends on unforgeable origin metadata and genuine value matching, protected T3 records, and a complete offline inventory of state-changing tools and harm-carrying parameters.The inventory is a bounded one-time cost per environment; an omission removes the guarantee only for the omitted parameter.Source: §6 · p. 12
  • ROPE requires enforcement-point access to value origins and propagation of that metadata to tool calls, which is unevenly supported across real platforms.Provenance-aware agent infrastructure and platform integrity guarantees such as signed content or authenticated read-only interfaces could extend trust to intact message bodies and recover tasks that currently fail closed.Source: §6 · p. 12

7 Related Work

Related work distinguishes defenses by what they trust and where they enforce that judgment. ROPE’s key distinction is deterministic, task-conditional checks on sensitive parameters based on the trusted request and value origin.

Model- and content-level defenses

  • Model- and content-level defenses restate instructions, detect attacks, or prioritize privileged instructions, but still let the agent act on content that passes their checks.Detectors can over-block benign content and fail against adaptive rewording; ROPE instead constrains sensitive-parameter values so classifier evasion cannot authorize an untrusted value.Source: §7 · pp. 12–13

Information-flow and capability defenses

  • Information-flow and capability defenses track value origins, but fixed trust boundaries can block legitimate delegated steps; ROPE conditions each sensitive parameter’s trust on the user’s request.On AgentDyn, PFI costs two-thirds of the undefended agent’s completion; ROPE reads the trusted request alone to determine whether the user supplied a value.Source: §7 · p. 13

Task-conditional screening and plan conformance

  • Task-conditional methods constrain actions to a request-derived policy, while ROPE admits guarded values only when they match one read under a trusted origin.Conseca [31] uses syntactic regex constraints and a free-form policy without an audited default; ROPE’s fixed origin markers compile into enforcement policies with audited defaults that bound a weak router.Source: §7 · p. 13

Per-call attribution and contextual policies

  • Per-call attribution and contextual-policy methods use model judgments on every call, whereas ROPE varies a deterministic check according to request under-specification.Their judgments remain model outputs that evaluations cannot audit; values delegated wholly to attacker-writable content remain challenging for these methods too.Source: §7 · p. 13

Attacks and benchmarks

  • Prior work established direct and indirect prompt injection, standardized attacks, built agent benchmarks, and studied adaptive attackers; ROPE evaluates on AgentDyn and against adaptive and long-horizon attacks.AgentDyn places helpful third-party instructions on the critical path, making it unsuitable for defenses that ignore all external content.Source: §7 · p. 13

8 Conclusion

ROPE enforces tool-parameter trust through provenance and task-conditioned information-flow control, without an auxiliary model predicting agent actions. It combines empirical efficacy with two provable guarantees.

8 Conclusion

  • Across four agent models and three open-ended suites, ROPE retains 82–100% of undefended task completion while holding attack success to 1.6–2.6%.Baselines preserving comparable utility leave attack success an order of magnitude higher, while adaptive and long-horizon attackers gain nothing.Source: §8 · p. 13
  • ROPE uses information-flow control conditioned on the user’s task, ensuring attacker-writable content cannot reach origin-guarded parameters and injection rewording cannot change admission decisions.Source: §8 · p. 13
  • Agent stacks that expose each value’s provenance enable deterministic origin-based enforcement, and certifiable trust anchors widen admission without weakening the defense.Source: §8 · p. 13

Ethics … A.3 Origin-tracker attribution

The appendix operationalizes ROPE’s origin-based guard through offline parameter rules and runtime attribution, while documenting ethical safeguards and edge cases that qualify trust in records.

Ethics

  • Experiments used synthetic users and simulated benchmarks; no production system, real user, third party, or personal data was involved.The evaluated attacks were already public, and the work introduced no new offensive capability.Source: Ethics · p. 14

A Implementation Details

  • Appendix A documents the offline-authored sensitive-parameter tables, origin markers, runtime attribution rules, and configuration for reproducing §4.Source: A Implementation Details · p. 16

A.1 Origin markers

  • Origin markers map to trust anchors T1 (request), T2 (named unforgeable runtime origin), and T3 (the user’s authoritative records).The router can pin an exact request-named value to CONST or a request-implied closed set from the user’s account to ONEOF, overriding a default marker.Source: §A.1 · p. 16, Table 8 · p. 16

A.2 Per-suite sensitive-parameter tables

  • The tables default-allow unlisted tools as benign, but browse_webpage can dispatch state-changing handlers despite its fetch-like interface and was treated as read-only.Whether a tool changes state depends on its implementation, so interface-based enumeration can miss such calls.Source: §A.2 · p. 16
  • Tables 9–10 enumerate sensitive parameters for AgentDyn and AgentDojo tasks, with travel phrase-valued booking entities and event titles requiring exact whole-value request pins.Table 9 covers AgentDyn suites with 20 user tasks each; Table 10 covers AgentDojo banking (16), slack (21), and travel (20).Source: Table 9 · p. 16, §A.2 · p. 16, Table 10 · p. 17

A.3 Origin-tracker attribution

  • The tracker attributes structured records by unforgeable origin, treats monolithic blobs as injectable, and requires every list element to be trusted.User platform records such as order history and linked SSH-key state may be filed under a reserved non-injectable source; live cart, catalog, and editable profile are excluded. Reads from write-protected stores receive that record-source attribution, while writes under /system, /.ssh, or /etc are blocked unless the request named the path.Source: §A.3 · p. 16
  • Lemma 1’s write-to-record condition holds for SSH-key state, but order-log product identifiers create a task-dependent edge that persistent deployments must close.Catalog-derived order fields remain injectable, and clean fresh environments prevent an admitted open-target purchase from affecting later re-buys in the evaluation. The paper proposes strengthening the purchase floor or recording only the platform-generated order identifier; account-verification responses likewise contribute only SSH-key state to the record source.Source: §A.3 · p. 17
  • Matching uses whole candidate identifiers, blocking padded composites such as attacker/victim-repo while allowing the bare user-named victim-repo.Trusted identifiers are tokenized into whole identifiers and slash-separated parts; destination URLs use the host as the decision unit, so paths on a trusted host refer to the same recipient.Source: §A.3 · p. 17

A.4 Reproducibility … B Full Comparison Tables

The appendices specify the evaluation and defense configurations, correct three flawed attack-success oracles uniformly, and identify the full-comparison tables underlying the reported tradeoff plots.

A.4 Reproducibility

  • Each evaluation cell is a single greedy-decoding run over every user-task/injection-task pair plus one clean run per task, with Claude Opus 4.8 routing and an unweighted Overall mean.For small action-open buckets, raw k/n is reported next to clean utility.Source: §A.4 · p. 17

A.5 Benchmark scoring corrections

  • Oracle audits require recorded attack success to reflect a state change only the attack could produce; three suite oracles instead counted denied actions or benign outcomes as successes.The affected cases were Slack IT5, Daily-life IT7, and GitHub IT1.Source: §A.5 · p. 18
  • Re-scoring uses defense-filtered traces uniformly across defenses and agents, can only remove non-attack-caused successes, and leaves clean and attacked utility unchanged.The same correction dispatch point is used by every table in the paper.Source: §A.5 · p. 18

A.6 PFI policies

  • PFI policies trust the user’s identities and platform records, label counterparty content by unforgeable sender or container, and use rule-derived, benchmark-independent policies on AgentDojo.For AgentDyn, PFI’s unmodified agent is supplied with the required artifacts; policies grant it tools outside the audited sensitive-tool table.Source: §A.6 · pp. 18–19
  • PFI trusts the platform’s service address for one-time action-confirmation passwords, which attackers cannot author or forge under the stated threat model.Otherwise, PFI’s utility would be zero by construction.Source: §A.6 · p. 19

A.7 Router prompt

  • The router/scoper reads only the user request to emit per-task scope, and malformed output fails loudly rather than falling back to a weaker scope.The reference runs are zero-shot; the user message includes the sensitive-tool set, trusted account facts, and request.Source: §A.7 · p. 19

B Full Comparison Tables

  • Tables 11 and 12 provide the exact numbers underlying Figure 3, while Figure 5 plots those numbers as a utility–security tradeoff by agent model.Source: B Full Comparison Tables · p. 19

C Results on AgentDojo

On AgentDojo’s specified tasks, ROPE remains in the low-ASR group with clean utility close to an undefended agent, but does not separate from the best request-derived defenses; the utility cost of provenance gating is tied to tasks that require acting on environment-read values.

C Results on AgentDojo

  • The identical ROPE defense, with the same fixed sensitive-parameter set, router, and enforcement, was tested on three AgentDojo suites for three agents using effect-based scoring.One slack injection task was scored by emitted calls rather than workspace changes, with uniform rescoring across defenses.Source: C Results on AgentDojo · p. 19
  • Overall ASR was 3.7/3.7/4.6 across agents, with ROPE’s clean utility near undefended levels, while Progent and DRIFT also kept utility high at low ASR on these specified tasks.This convergence is consistent with the claim that the gap opens with delegation, not with the gating mechanism alone.Source: C Results on AgentDojo · p. 19
  • AgentDojo clean tasks often require acting on environment-read values, which provenance gating blocks; the same channel can carry injections in attack variants.Examples include paying an IBAN from a bill file or booking a hotel named in a review.Source: C Results on AgentDojo · p. 19
  • DRIFT avoids this clean-task cost but admits a higher attack rate; MELON keeps clean utility near undefended levels but its masked re-execution flags legitimate calls under attack.MELON’s UA was 24.6 vs. 43.2 on GPT-4o-mini and 15.5 vs. 41.5 on Gemini-2.5-Flash.Source: C Results on AgentDojo · p. 19

D AgentDojo under the Adaptive Attack

Under the AutoDojo adaptive attack, filter-based detectors lose ground while provenance- and plan-based defenses move little. ROPE remains in the lowest-ASR group across all three agents, with clean utility comparable to the strongest baselines and little adverse movement under optimization.

D AgentDojo under the Adaptive Attack

  • ROPE records ASR of 2.8/4.0/5.0 across the three agents, with clean utility comparable to the strongest baselines.Optimization moves its ASR by at most 0.4 in the attacker’s favor on any model: 3.7 to 4.0 on Gemini-2.5-Flash and 4.6 to 5.0 on Qwen3-235B, while lowering it from 3.7 to 2.8 on GPT-4o-mini.Source: D AgentDojo under the Adaptive Attack · p. 20
  • On GPT-4o-mini, adaptive attacks raise PIGuard ASR from 0.0 to 26.7 and ProtectAI from 7.9 to 16.0, while provenance- and plan-based defenses move little.Prompt-based defenses remain high under the adaptive attack.Source: D AgentDojo under the Adaptive Attack · p. 20
  • MELON and Tool Filter post low single-agent rates, but from collapsed operating points.MELON completes only 29.5 under attack on GPT-4o-mini; Tool Filter’s 0.0 on Gemini-2.5-Flash coincides with clean utility of 10.4.Source: D AgentDojo under the Adaptive Attack · p. 20
  • PFI remains low under adaptive attack on API models at ASR 1.3 and 3.2, but reaches 8.8 on Qwen3-235B.Its clean utility is 41.2, below ROPE’s 58.9 and 58.6; the authors relate its low API-model ASR to wording invariance.Source: D AgentDojo under the Adaptive Attack · p. 20
  • Banking remains at 0.0 under both attacks on all three models, while ROPE’s ASR movement is concentrated in travel.This matches the wording-invariance pattern on AgentDyn.Source: D AgentDojo under the Adaptive Attack · p. 20

E Per-Category Results

Per-category results show ROPE’s advantage is clearest on AgentDyn tasks that require runtime delegation, while AgentDojo’s more-specified tasks narrow the separation. The benchmarks use published AutoDojo buckets for AgentDojo and router-assigned buckets for AgentDyn.

E Per-Category Results

  • On AgentDyn action-open tasks, ROPE alone retains clean utility (CU=12.5) at ASR=0; on param-open (n=30), its CU=43.3 versus 16.7 for DRIFT, MELON, and PFI and 10.0 for Progent.Every other system-level defense has CU=0 on action-open tasks, where the legitimate action is named only in runtime content unseen by request-time planning.Source: E Per-Category Results · pp. 20–21, Table 15 · p. 24
  • MELON’s clean-task false-positive rate rises from 44% on fully-specified tasks to 72% on parameter-open and 100% on action-open tasks as delegation increases.The pattern reflects behavioral detection mistaking legitimate content-driven steps for attacks.Source: E Per-Category Results · p. 21
  • On AgentDojo, ROPE achieves the best fully-specified clean utility (CU=68.0) and remains in the low-ASR group throughout, while separation narrows on the more-specified tasks.AgentDojo tasks are bucketed as published by AutoDojo [24].Source: E Per-Category Results · p. 21, Table 16 · p. 24

Related papers

Loading 2608.27496v1…