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 exploits runtime content read by tool-using agents, while prior defenses can lose utility when delegation leaves actions and values unspecified. ROPE enforces structural origin policies over sensitive parameters using only the trusted request for routing and deterministic runtime checks. Across four agent models and open-ended suites, it retains high clean utility while keeping attack success low, with guarantees for origin soundness and paraphrase-invariant admission.

  • Problem

    Prior system-level defenses struggle with runtime delegation because plans, policies, or trust boundaries fixed before content arrives cannot reliably distinguish legitimate from attacker-controlled values without sacrificing utility.

  • Method

    ROPE audits sensitive parameters, routes task-specific origin policies from the trusted request, tracks structural origins, and deterministically checks every sensitive state-changing call.

  • Results

    ROPE holds attack success to 1.6–2.6 while retaining 82–100% of undefended clean utility across four agent models and open-ended suites, outperforming baselines on the utility–security tradeoff.

  • Takeaways & Limitations

    ROPE provides provable protection against attacker-only origins and injection paraphrasing while preserving substantially more task utility than defenses that suppress open-ended actions.

  • Takeaways & Limitations

    ROPE’s guarantees concern origin rather than user intent, so it can safely reject legitimate values whose only origin is attacker-writable content.

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

ROPE addresses indirect prompt injection by enforcing trusted origins for sensitive tool parameters while adapting enforcement to the user’s delegation. This targets the utility–security tradeoff that limits prior system-level defenses on open-ended tasks.

  • Motivation: Indirect prompt injection steers agents through attacker-planted instructions in outside content toward harmful state-changing tool calls.The harmful value may trigger an unrequested action or corrupt an action the user intended.
  • Motivation: Prior system-level defenses either predict tools or constrain information flow before delegated content arrives, limiting their ability to handle runtime-determined actions and values.LLM-based flow judges also read potentially injected content, creating a weak link.
  • ROPE: ROPE defines trust structurally: sensitive values must trace unforgeably to the user, a user-named source, or the user’s authoritative records.These origins are platform-level properties rather than model predictions of the task.
  • ROPE: ROPE combines audited sensitive-parameter identification, trusted-request routing, origin tracking, and deterministic enforcement without an LLM in the enforcement loop.The task-specific policy changes which trusted origins a parameter may use, preserving benign deviations such as extra reads or reordered steps.
  • Contributions: ROPE provides origin soundness and paraphrase-invariant admission decisions, while introducing under-specification as the signal for conditioning enforcement strictness.The contributions connect this design to recovering utility lost by fixed policies on open-ended benchmarks.

2 System and Threat Model

The paper studies agents that read attacker-controllable outside content before calling tools, focusing on preventing attacker-chosen values from reaching harmful state-changing operations while retaining task completion.

  • Setting: The setting is a natural-language request completed by an LLM agent through tools such as email, payments, file operations, browsing, and repository management.The focus is indirect prompt injection in data retrieved by the agent.
  • Setting: State-changing tools alter the world outside the agent, whereas read-only tools only return information.The defense targets harm effected through state-changing calls.
  • Threat model: Attackers may plant instructions in file bodies, web pages, and email bodies, but cannot observe or alter the user query or forge properly verified origin identities.The threat model still permits attackers to claim identities in writable content.
  • Trust anchors: ROPE uses three trust anchors: the user’s request (T1), a user-referenced unforgeable runtime origin (T2), and the user’s authoritative records (T3).Examples include a named sender’s signed address and platform-maintained transaction history.
  • Task openness: Requests are categorized as fully-specified, parameter-open, or action-open, with broader delegation allowing a larger set of legitimate origins.The defense operationalizes the distinction as a per-sensitive-parameter binary question.
  • Defense goal: The defense goal is to block sensitive parameters carrying attacker-chosen values or unrequested attacker-induced actions while allowing regular requested tasks to complete.

3 Design of ROPE Defense

ROPE fixes an auditable set of sensitive parameters, routes each task using only the trusted request, and deterministically admits values whose tracked origins satisfy the compiled policy. Its guarantees cover origin soundness and invariance to injection paraphrasing.

  • Setup: ROPE identifies harmful non-read-only tools and sensitive destination or content parameters once from tool schemas in an auditable, task-independent setup.Examples include payment recipients, URLs, owners, submitted data, products, and event titles.
  • Step 1: Route and scope: A single model call reads only the user request to determine task under-specification and scope, so injected content cannot influence routing.
  • Step 2: Compile policy: The compiled policy maps each sensitive parameter to trusted origins: T1 for request-provided values, with T2 and T3 added when the task delegates legitimately.Irreversible destructive actions require explicit authorization on the named target.
  • Step 2: Compile policy: Origin-guarded parameters admit values only through traces to trust anchors, including parameters carrying destinations, recipients, accounts, or items.
  • Step 3: Attribute origins: The origin tracker labels tool results from platform structure and identity metadata rather than reading their text.Verified sender identities can support T2, while undivided file or webpage blocks remain injectable even when referenced by the user; authoritative records can support T3.
  • Step 3: Enforce: The matcher admits a proposed sensitive value only when it matches a value read under an accepted origin, requiring every list element to be trusted and preserving whole decision units.Decision units include full repository names, email recipient addresses, or destination URL hosts.
  • Theoretical guarantees: Under A1–A3, Proposition 1 guarantees that every admitted origin-guarded value has an unforgeable trace to T1, T2, or T3 at every trajectory step.The guarantee is about origin rather than whether the value matches the user’s intent.
  • Theoretical guarantees: Proposition 2 guarantees that paraphrasing an injection cannot change ROPE’s admission decision, although rewording may still steer which calls the agent attempts.

4 Evaluation

ROPE is evaluated against 11 defenses across four agent models and multiple AgentDyn, AgentDojo, adaptive-attack, long-horizon, policy-ablation, and router studies. It maintains a stronger utility–security balance than prior defenses while remaining robust to adaptive and staged attacks.

  • Comparison to baseline defenses: ROPE holds AgentDyn ASR to 1.6–2.6 while retaining 82–100% of undefended clean utility across all four models.It also dominates DRIFT on CU and UA by 7–25 CU points at comparably low ASR.
  • Comparison to baseline defenses: Low-ASR baselines generally collapse clean and under-attack utility, whereas utility-preserving methods barely reduce attacks.CaMeL completes no tasks, while ROPE’s UA tracks the undefended agent’s performance.
  • Trace analysis: ROPE completes all three delegated clean tasks without constraining benign runtime deviations or inserting replacement tokens.DRIFT refuses delegated values or steps as plan deviations, while PFI masking can cause fabricated email addresses.
  • Robustness to adaptive attacks: Adaptive optimization leaves ROPE’s admission decision unchanged because its request-derived origin check is invariant to injection wording.By contrast, optimization roughly doubles DRIFT’s overall ASR on GPT-4o-mini and Gemini-2.5-Flash and quadruples it on Qwen3-235B.
  • Robustness to long-horizon attacks: ROPE reduces long-horizon ASR to 0.0 on every suite for all three protected models while preserving under-attack utility close to undefended performance.Staging does not help because decisive values still originate in attacker-writable content.
  • Conditioning on under-specification: The routed policy matches the strict policy’s ASR of 1.8 while matching the loose policy’s CU of 43.3.The strict policy over-blocks delegated values, whereas the loose policy reaches ASR 44.0.
  • How cheap can the router be?: Clamping router overrides removes Gemini-3-Flash’s GitHub and daily-life attack successes, reducing ASR from 6.0 to 0.0 without costing clean utility.The clamp only tightens attack-admitted values; shopping is unchanged because its audited floor is permissive.

5 Failure Analysis

ROPE’s residual failures arise from harms outside tool-call admission and from cases where legitimate values originate only in attacker-writable content. Its clean-task losses are mainly agent failures or deliberate fail-closed denials, with paraphrase matching adding a smaller strictness cost.

  • Residual attack success: 90 attacked cases succeed against ROPE, spanning message-only harm, harmful content sent to legitimate destinations, and attacker-supplied sensitive parameters.The cases are classified by the channel carrying harm.
  • Residual attack success: 23 residual successes involve only the agent’s message, which ROPE cannot constrain because it guards tool calls rather than model outputs.One example includes an injected hotel recommendation without any tool call.
  • Residual attack success: 21 residual successes send harmful content to legitimately admitted destinations, because the user named the destination while the message body remains arbitrary text.A phishing link can therefore reach a colleague the user explicitly named.
  • Residual attack success: 46 residual successes occur when a sensitive parameter is delegated wholly to attacker-writable content, ROPE’s identified blind spot.The origin rule rejects no trusted source here because none exists.
  • Clean task failures: 199 of 411 clean tasks fail, but only 73 failures are attributable to ROPE; the remaining 126 contain no denied tool call and predominantly reflect agent artifacts.ROPE-attributable failures are either fail-closed delegated parameters or strictness costs from rejecting paraphrases.
  • Clean task failures: Stable identifiers could reduce strictness costs by letting matching compare entity identity rather than differently worded phrases.The paper gives event titles and addresses as examples of phrase-valued parameters.

6 Discussion

ROPE’s matcher makes crafting an accepted malicious value difficult because the attacker lacks the user’s request, while its guarantees depend on platform provenance, record integrity, and complete enumeration of guarded parameters. Deployment also requires exposing and propagating value origins.

  • Discussion: An attacker’s chosen objective and the user’s legitimate value coincide only by accident when the attacker lacks knowledge of the request.This makes optimizing the injected value itself largely ineffective beyond wording attacks.
  • Discussion: Origin soundness assumes unforgeable origin metadata and a matcher that equates only genuinely equal values.The decision-unit rule supplies the equality condition.
  • Discussion: Record integrity requires T3 fields to have no attacker write path and prevents deployment tools from writing attacker-reachable content into them.The paper audits state-changing write edges against this condition.
  • Discussion: ROPE requires enforcement points to expose and agent stacks to propagate each value’s origin, while platform-certified content integrity could extend trust beyond sender identity.Signed content and authenticated read-only interfaces are cited as mechanisms that could recover currently fail-closed in-band tasks.

7 Related Work

Related defenses differ in whether they trust prompts, content, model behavior, tool calls, or information flows, and in where trust judgments occur. ROPE contrasts with these approaches by constraining actions through provenance rather than relying on classifiers or per-call model judgments.

  • Model- and content-level defenses: Prompt-based defenses restate or delimit user instructions, while detector models classify content or behavior and instruction-training methods prioritize privileged instructions.Examples include prompt sandwiching, spotlighting, ProtectAI, PIGuard, PromptGuard2, CAD, StruQ, SecAlign, and instruction hierarchy.
  • Model- and content-level defenses: These model- and content-level methods leave agents free to act on content that passes their checks, and adaptive rewording can increase detector attack success.The appendix reports optimizer-driven increases for ProtectAI and PIGuard.
  • Model- and content-level defenses: ROPE constrains the action itself and uses a fixed set of audited origin markers, allowing audited defaults to bound weaker router outputs.The defaults serve as enforcement floors.
  • Per-call attribution and contextual policies: Per-call attribution and contextual policies re-execute agents, diagnose causes, or vary access by estimated risk, incurring model-in-the-loop costs on every call.Examples include AttriGuard, MELON, AgentSentry, and TBAC.
  • Attacks and benchmarks: IPI research progressed from direct model-input attacks to attacks embedded in application content, with AgentDojo, InjecAgent, and ASB standardizing tool-using-agent evaluation.Adaptive attackers and taxonomies further organize the defense landscape.

8 Conclusion

ROPE frames indirect prompt injection defense as a provenance problem and enforces trust through task-conditioned information-flow control without an auxiliary model predicting agent behavior. Across four models and three open-ended suites, it combines low attack success with high retained utility and supports two guarantees.

  • Conclusion: ROPE treats provenance as the question of which read content may reach actions, using information-flow control conditioned on the user’s task.Its enforcement does not require an auxiliary model to predict the agent’s behavior.
  • Conclusion: 82–100% of undefended task completion is retained while attack success remains 1.6–2.6% across four agent models and three open-ended suites.Baselines with comparable utility leave attack success an order of magnitude higher.
  • Conclusion: ROPE guarantees that attacker-writable content cannot reach an origin-guarded parameter and that injection rewording cannot change an admission decision.The conclusion also reports no gains for adaptive or long-horizon attackers.
  • Conclusion: Agent stacks that preserve and expose provenance would enable deterministic origin defenses, while additional platform-certified trust anchors could widen admitted content without weakening enforcement.This identifies provenance-aware infrastructure as the deployment path for extending ROPE’s coverage.

Ethics

The paper presents ROPE as defensive research evaluated only in simulated environments, with sensitive parameters and origin markers specified through auditable configuration. Its implementation addresses runtime attribution, persistent records, and exact identity matching.

  • Ethics: All experiments use simulated AgentDojo, AgentDyn, and AgentLAB environments with synthetic users, accounts, and services.No production system, real user, or third party was attacked, and no personal data was processed.
  • Configuration: ROPE’s sensitive-parameter rules use markers corresponding to the request, named unforgeable runtime origins, or the user’s authoritative records.The offline-authored configuration defines marker semantics and default sensitive-parameter tables.
  • Attribution: The tracker attributes returned values by reading result structure, separating stamped records from monolithic attacker-writable blobs.Platform-generated or structurally identified records can receive authoritative-record provenance, while blobs remain constrained by their source.
  • Persistent state: Persistent logs can violate the record-consumption invariant unless deployments strengthen purchase parameters or restrict provenance to platform-generated identifiers.The benchmark resets environments between tasks, so this issue is not realized in evaluation.
  • Identity matching: Decision-unit matching treats candidate identifiers as whole values, blocking padded composites such as attacker/victim-repo while accepting the user-named bare identifier.Destination URLs use the host as the decision unit; other values use identifier chunks.

A.4 Reproducibility

The reproducibility setup fixes attack configurations, oracle scoring, baseline artifacts, and router inputs while keeping enforcement deterministic after routing. Exact tables and prompts provide the configuration underlying the reported comparisons.

  • A.4 Reproducibility: Each run evaluates every user-task and injection-task pair plus one clean run per user task under the important_instructions attack.Claude Opus 4.8 reads only the request for routing and scoping; enforcement is deterministic given the resulting scope.
  • Oracle evaluation: Success is counted only when an executed call produces the attacker’s state-changing effect, using one audited oracle across defenses and agent models.The corrected score can remove false positives from attempt-based or proxy-based oracles but cannot add successes.
  • Baseline reproduction: PFI is evaluated with supplied AgentDyn artifacts and benchmark-independent policies derived from ROPE’s origin anchors.The agent remains unmodified, and the artifacts do not refer to benchmark tasks or attacks.
  • Routing: The router/scoper is a single trusted-input LLM call that reads only the user request and emits the per-task scope.Its output includes the under-specification level, named source, and verbatim parameter values or overrides.
  • Reported comparisons: Tables 11 and 12 provide the exact numbers plotted in the utility–security comparisons.Figure 5 reproduces those values as one utility–security panel per agent model.

C Results on AgentDojo

On simpler AgentDojo tasks, ROPE remains low-ASR with clean utility close to an undefended agent, while request-derived defenses also perform well. The results support a delegation-dependent gap rather than a universal advantage over task-specific gating.

  • C Results on AgentDojo: ROPE records overall ASR 3.7/3.7/4.6 across agents while keeping clean utility close to the undefended agent.On these specified tasks, Progent and DRIFT also maintain high utility at low ASR.
  • C Results on AgentDojo: AgentDojo’s clean tasks often require acting on values read from the environment, so provenance gating can block legitimate tool-sourced values.The same channel can carry injected instructions in attack variants.
  • C Results on AgentDojo: DRIFT avoids the clean-task cost but admits a correspondingly higher attack rate, with the separation re-emerging on AgentDyn.The reported pattern is associated with where delegation occurs.
  • C Results on AgentDojo: MELON’s masked re-execution reduces attacked completion despite near-undefended clean utility, including UA 24.6 vs. 43.2 on GPT-4o-mini.On Gemini-2.5-Flash, UA is 15.5 versus 41.5 for the undefended agent.
  • C Results on AgentDojo: Figure 5 presents the AgentDyn utility–security tradeoff for all four models, with ROPE alone in the favorable region.Each point uses overall clean utility and attack success rate from the comparison tables.

D AgentDojo under the Adaptive Attack

Under AutoDojo’s adaptive attack, ROPE remains in the lowest-ASR group across three agents at comparable clean utility. Optimization changes ROPE’s ASR by at most 0.4 percentage points in the attacker’s favor on any model.

  • D AgentDojo under the Adaptive Attack: Adaptive optimization moves ROPE’s ASR by at most 0.4 in the attacker’s favor on any model.The increases are 3.7 to 4.0 on Gemini-2.5-Flash and 4.6 to 5.0 on Qwen3-235B.
  • D AgentDojo under the Adaptive Attack: The adaptive attack substantially raises ASR against filter-based detectors while leaving provenance- and plan-based defenses comparatively unchanged.For example, PIGuard rises from 0.0 to 26.7 on GPT-4o-mini, while ROPE remains low-ASR.
  • D AgentDojo under the Adaptive Attack: Banking remains at 0.0 under both static and adaptive attacks on all three models, while ASR movement concentrates in travel.This distribution matches the reported wording-invariance pattern on AgentDyn.

E Per-Category Results

Per-category results show ROPE’s advantage is sharpest on highly under-specified AgentDyn tasks, while AgentDojo’s more specified tasks narrow the separation.

  • AgentDyn: On AgentDyn action-open tasks, ROPE alone retains clean utility of 12.5 while maintaining ASR = 0.Other system-level defenses fall to exactly CU = 0 because the legitimate action appears only in runtime content.
  • AgentDyn: On AgentDyn param-open tasks, ROPE leads low-ASR defenses with CU = 43.3 versus 16.7 for the next reported baseline.The comparison uses the larger param-open bucket of n=30.
  • Evaluation setup: The evaluation pools metrics over benchmark suites and groups tasks by under-specification buckets to expose where defenses diverge.AgentDyn uses router-assigned buckets, whereas AgentDojo follows AutoDojo’s published buckets.
  • AgentDyn: 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.The monotonic increase tracks increasing delegation to runtime content.
  • AgentDojo: On AgentDojo, request-derived baselines remain competitive because tasks are more specified, but ROPE records the best fully-specified clean utility at CU = 68.0.ROPE also remains in the low-ASR group throughout the benchmark.
Loading 2608.27496v1…