PaperlayerView exact revision on arXiv

Source-linked AI summary

When Consent Outlives Context: Residual Authority Replay in Long-Lived Agents

Zhihao Zhang, Chao Wang, Rujia Li, Qingze Wang, Xiaoyan Sun, Jun Dai

arXiv:2609.33910v1cs.AI

TL;DR

Long-lived agents can preserve user approvals beyond the context that justified them, leaving authority available without renewed consent. The paper profiles production authorization semantics and tests a longitudinal attack that obtains grants through benign tasks before replaying them in an adversarial context. Replay increases attack success in benchmark and live-agent evaluations, while finer authorization matching reduces—but does not eliminate—the exposure.

  • Problem

    Long-lived agents may preserve approval decisions across tasks or sessions, creating a mismatch when consent outlives the context that justified it.

    Source: §1 · p. 1

  • Method

    The authors profile native authorization semantics, backchain from target actions to benign grant-acquisition tasks, and compare replay under fresh and accumulated authorization states.

    Source: §4 · p. 3, §4.1 · p. 3

  • Results

    Replay increased attack success by up to 35.1 percentage points on AgentDojo and by 24.9 percentage points on average in Terminal-Bench context-rebinding attacks.

    Source: §1 · p. 2

  • Takeaways & Limitations

    Finer matching reduces replay exposure but does not eliminate it, because matching action and resource identity may omit context that changes an action’s security meaning.

    Source: §6 · p. 9

    The experiments used controlled environments, public benchmarks, and locally instantiated agent systems, not third-party users or production deployments.

    Source: ETHICS STATEMENT · p. 10

Abstract

from arXiv · show

LLM agents increasingly rely on user approval to authorize security-sensitive actions at runtime. Such approvals are granted within a specific task and execution context. In long-lived agents, authorization decisions may need to persist across tasks or sessions. We find that this continuity can outlive the context that originally justified the approval, creating residual authority reusable without renewed consent. We expose this failure mode through a longitudinal attack that starts from a target security-sensitive action, identifies the authority required to execute it, induces benign interactions that legitimately obtain that authority, and later replays the residual authority during adversarial execution. Across controlled and live settings, we demonstrate that residual-authority replay arises in practice and substantially increases the success of prompt-injection and context-rebinding attacks. We evaluate 508 AgentDojo attack cases across six LLM families using production-derived authorization semantics. With residual authority, attack success rate (ASR) increases by up to 35.1 percentage points compared with a fresh authorization state. In live context-rebinding attacks on 55 Terminal-Bench cases across three real-world production coding agents, residual-authority replay increases ASR by 24.9 percentage points on average. These findings expose a fundamental mismatch between persistent authorization and the contextual nature of user consent in long-lived LLM agents.

1 INTRODUCTION

Long-lived agents may retain approvals across tasks and sessions, so consent can outlast the context that justified it. The paper characterizes this residual authority and introduces an attack that accumulates grants through benign interactions before replaying them in a later malicious context.

1 INTRODUCTION

  • Residual authority can persist across task and session boundaries, allowing later actions to bypass otherwise-required user approval.The paper examines authorization semantics across production agents and notes incidents involving persisted authorization or delegated capabilities.Source: §1 · p. 1
  • The attack backchains from a target harmful outcome to approval-gated actions, obtains matching grants through benign approvals, then compares execution with fresh and accumulated authorization states.The comparison measures how much retained authority amplifies attack success.Source: §1 · p. 2
  • Across 508 AgentDojo cases and six LLM families, accumulated authorization increased prompt-injection attack success rates by up to 35.1 percentage points; across 55 Terminal-Bench cases and three production coding agents, replay increased ASR by 24.9 percentage points on average.The evaluation characterizes authorization semantics in eight production agents.Source: §1 · p. 2

2 RELATED WORK

Prior work studies persistent semantic or behavioral state, agent authorization, and context changes that alter action effects. This paper distinguishes its focus on legitimate approvals that persist and later suppress a fresh approval boundary after context changes.

2 RELATED WORK

  • Research on persistent agent memory and skills examines later influence or safety effects, while this paper studies authorization state created by legitimate user approval.The related work distinguishes persistent authorization from persistent semantic or behavioral state.Source: §2 · p. 2
  • Work on authorization scope and temporal validity includes task-scoped or programmable least privilege, reusable consent rules, and approaches to revoking or constraining stale authority.The paper's distinction is that it studies how legitimate interactions construct persistent authorization state that can suppress renewed confirmation after context changes.Source: §2 · pp. 2–3
  • Prior systems-security research describes how pathname, executable, dependency, or configuration rebinding can change an action’s effects; residual-authority replay couples such execution changes with authority established under benign context.The later reuse can suppress an approval boundary for an action whose security consequence has changed.Source: §2 · p. 3

3 THREAT MODEL

The threat model concerns a long-lived agent whose user-approved grants persist across task or session boundaries and are later tested under attacker-supplied untrusted content.

3 THREAT MODEL

  • The agent’s authorization grants may persist across task or session boundaries and accumulate through ordinary use or attacker-influenced benign tasks.The attacker later supplies untrusted content to induce a target action; grants are user-approved, and the runtime and authorization mechanism are trusted to operate as specified.Source: §3 · p. 3
  • Replay succeeds when earlier grants remain valid across a context change, match the target action, and permit execution without renewed user confirmation.The later context may be a task, repository, or session.Source: §3 · p. 3
  • The model assumes the agent runtime and authorization mechanism create, store, and evaluate approved grants as specified.This sets the trusted-system boundary for the attack scenario.Source: §3 · p. 3

4 RESIDUAL AUTHORITY REPLAY

Residual-authority replay constructs retained authorization from legitimate approvals and tests whether it admits a target action in a later adversarial context. The workflow profiles native authorization, backchains from target actions to benign acquisition tasks, farms grants, then compares replay under fresh and retained states.

4 RESIDUAL AUTHORITY REPLAY

  • Residual-authority replay profiles native authorization, acquires grants through benign tasks, and replays the target task under a fixed adversarial context with fresh and accumulated authorization states.Figure 1 depicts the attack construction and evaluation workflow.Source: §4 · p. 3, Figure 1 · p. 4

4.1 AGENT AUTHORIZATION PROFILING

  • Authorization profiling traces how approval creates reusable state, identifies the grant scope and stored representation, recovers native matching conditions, and validates matching and persistence across execution boundaries.The resulting profile records grant scope, representation, matching conditions, and lifetime.Source: §4.1 · pp. 3–4

4.2 RESIDUAL-AUTHORITY BACKCHAINING

  • Backchaining defines approval-gated actions from a target reference path under fresh authorization, then maps those actions to benign task–grant pairs whose grants would admit them.The required actions are those for which the native check asks for approval in the fresh state; this is not a minimum permission set across all possible attack paths.Source: §4.2 · p. 4

4.3 BENIGN AUTHORITY FARMING

  • Benign authority farming executes selected tasks through native approval workflows and records which grants remain effective at replay time, verifying whether they admit every approval-gated action.The target residual-authority set is anticipated during backchaining; the retained set records grants actually produced and not expired or revoked.Source: §4.3 · p. 5

4.4 RESIDUAL-AUTHORITY REPLAY

  • Replay compares the same target task and adversarial context under fresh and retained grants, then verifies the approval-boundary change, grant provenance, execution without renewed approval, and harmful outcome.Successful replay requires all these conditions; unmatched grants, additional approval requirements, absent harmful outcomes, or unverified attribution are recorded separately.Source: §4.4 · p. 5

5 EVALUATION

The evaluation tests how benign authorization history accumulates reusable authority, whether that authority amplifies attacks on AgentDojo, and whether replay enables attacks on production agents. It uses controlled experiments and live production approval mechanisms to examine these questions.

5.1 EXPERIMENTAL SETUP

  • Controlled AgentDojo experiments covered 508 eligible v1.2 cases across six LLM families, while live evaluation used 55 independently selected Terminal-Bench cases and production approval mechanisms.Controlled runs held the system prompt, tool schema, attack template, and ten-step interaction budget fixed.Source: §5.1 · p. 6

5.2 RQ1. RESIDUAL AUTHORITY ACCUMULATION

  • Benign history produced sharply different exposure: Goose reached CHE 1.00 after one task, Gemini CLI reached 0.84 at h = 64, and Codex and OpenCode reached 0.12 and 0.11.Exposure depends jointly on approval-reuse breadth and overlap between benign history and future actions.Source: Figure 2 · p. 6, §5.2 · p. 6

5.3 RQ2. ATTACK AMPLIFICATION ON AGENTDOJO

  • At h = 64, tool-level retention yielded ASR of 0.114–0.351 among four model families with clear amplification, versus 0.016–0.116 for scope-level and 0.012–0.039 for exact-resource matching.The remaining model families stayed near zero, and no replay eliminated the increase; exact-resource matching nevertheless did not bind approval to its original task context.Source: §5.3 · p. 8, Table 3 · p. 8

5.4 RQ3. LIVE ATTACKS ON PRODUCTION AGENTS

  • 24.9 percentage points: residual-authority replay increased case-weighted average ASR across 55 Terminal-Bench cases spanning five context-drift classes.Each case was evaluated under fresh and farmed authorization states with five repetitions per condition.Source: §5.4 · p. 8, Figure 3 · p. 9
  • Replay increased ASR by up to 0.46 for executable and dependency hijacking; content substitution increases were 0.30, 0.60, and 0.90 for Codex, Gemini CLI, and Goose, respectively.Replay was strongest when a resource changed at execution without changing authorization identity; configuration poisoning was less prevalent, and neither project-redirection case showed amplification.Source: §5.4 · p. 9

6 DISCUSSION

Persistent authorization turns contextual consent into a reusable predicate that may retain only part of the information that justified approval. Reducing replay risk therefore depends on authorization lifetime, matching granularity, and which contextual facts persist.

6 DISCUSSION

  • Exact-resource matching still permits nonzero attack success because it preserves action and resource identity but not execution context or contents.Finer matching reduces replay without eliminating it when omitted context changes an action’s security meaning.Source: §6 · p. 9
  • Task-scoped authorization and no replay eliminate history-induced amplification but restrict cross-task reuse.Finer matching preserves reuse, yet exact-resource matching can still leave residual attacks when context changes an action’s security meaning.Source: §6 · p. 9
  • A reuse-preserving defense should retain and revalidate the security-relevant bindings under which consent was granted.When changes to those bindings alter an action’s meaning, the runtime should request renewed approval and expose the changed context.Source: §6 · p. 9
  • Identifying minimal security-relevant bindings across heterogeneous tools and execution environments remains future work.Source: §6 · p. 9

7 CONCLUSION

The paper identifies residual authority as a longitudinal authorization failure: consent can remain effective after its justifying context changes. Its Terminal-Bench cohort was screened using benchmark artifacts and reference-action validation, retaining 55 cases across five context-drift categories.

7 CONCLUSION

  • Residual authority is a longitudinal authorization failure in which user consent outlives the context that originally justified it.Replay was validated on three native agent systems, and finer matching reduced exposure without eliminating the temporal separation between consent and execution.Source: §7 · p. 9
  • The study used controlled environments with public benchmarks and locally instantiated agent systems, not third-party users or production deployments.The authors state that they followed responsible-disclosure practices for identified vulnerabilities.Source: ETHICS STATEMENT · p. 10
  • The paper provides datasets, model and configuration details, histories, policies, prompts, budgets, and evaluation conditions to support repeatability.The evaluation uses publicly available benchmarks and deterministic or frozen inputs where applicable.Source: REPRODUCIBILITY STATEMENT · p. 10

A MODEL-INDEPENDENT COHORT SELECTION

  • The cohort was selected through model-independent screening and validation before agent evaluation.The marker file showed that modified context affected execution, while forwarding checks established that the original operation was reached but did not prove general behavioral equivalence.Source: A MODEL-INDEPENDENT COHORT SELECTION · pp. 12–13
  • 55 Terminal-Bench cases across five categories were retained after static screening and reference-action validation.Counts are task–class pairs, so one task may appear in multiple rows; C2 and C5 each contribute only two cases, limiting category-specific conclusions.Source: A MODEL-INDEPENDENT COHORT SELECTION · p. 13, Table 4 · p. 13

B CONTROLLED AGENTDOJO EXPERIMENTAL SETUP

The controlled AgentDojo study applies production-derived authorization semantics to 508 attack cases while keeping benign histories independent of later attack coverage. This design measures whether independently accumulated authority happens to overlap with authority needed by a later harmful action.

B CONTROLLED AGENTDOJO EXPERIMENTAL SETUP

  • History-length and policy comparisons do not select benign histories according to whether they cover the later attack.The same frozen history is reused across policy comparisons, and only the authorization policy changes in the h = 64 comparison.Source: B CONTROLLED AGENTDOJO EXPERIMENTAL… · pp. 13–14
  • The evaluation covers 508 eligible AgentDojo attack cases across banking, Slack, travel, and workspace environments.The cases pair a user task, injected adversarial objective, and side-effecting attack capability.Source: B CONTROLLED AGENTDOJO EXPERIMENTAL… · p. 13
  • The controlled experiments emulate recovered production authorization semantics around AgentDojo rather than simulating a production agent end to end.The layer determines whether a side-effecting call is silently admitted or reaches approval; model-side decisions remain native to each evaluated LLM.Source: B CONTROLLED AGENTDOJO EXPERIMENTAL… · p. 13
  • A later harmful action’s match with accumulated authority is an experimental outcome, not a history-selection criterion.The prior benign stream is fixed before evaluating whether the harmful action matches its authorization state.Source: B CONTROLLED AGENTDOJO EXPERIMENTAL… · p. 14
  • Benign histories are frozen before attack rollouts and coverage tests, with each history length using a nested prefix of one deterministic stream.The current task is excluded, and the stream is not resampled based on whether its grants admit the later harmful action.Source: B CONTROLLED AGENTDOJO EXPERIMENTAL… · p. 14
  • Rollouts use the same system instruction, AgentDojo task prompts, fixed injection template, and a ten-step limit.Side-effecting calls reaching the approval boundary are withheld and receive the same blocked-action response in every condition.Source: B CONTROLLED AGENTDOJO EXPERIMENTAL… · p. 14

C SOURCE-LEVEL AUTHORIZATION ANALYSIS

The paper reconstructs authorization semantics from production implementations and validates recovered profiles against native authorization engines. It then instantiates alternative authorization policies, including task-scoped and persistent matching, for controlled comparisons.

C SOURCE-LEVEL AUTHORIZATION ANALYSIS

  • The source-level analysis traces how explicit approval becomes reusable authorization state and how that state later controls execution.Recovered profiles are validated against native allow-or-ask decisions, including replay across supported task, session, and process boundaries and an unapproved-action negative control.Source: C SOURCE-LEVEL AUTHORIZATION ANALYSIS · pp. 14, 16
  • The recovered authorization profile records action attributes retained by a grant, its stored representation, its matching predicate, and the execution boundaries across which it remains effective.Source: C SOURCE-LEVEL AUTHORIZATION ANALYSIS · p. 15
  • Recovered grants retain different action information: Codex stores an argv prefix, Gemini CLI a command root, and Goose only tool identity.A later action can match a stored rule despite changes in execution context or unretained action attributes; for Gemini CLI, a chmod-root rule can match commands with different remaining arguments.Source: C SOURCE-LEVEL AUTHORIZATION ANALYSIS · pp. 15–16

D AUTHORIZATION POLICY INSTANTIATION

  • Persistent policies vary in matching granularity, from tool-level operation identity to exact-resource matching and scope-level parent identity.Tool-level matching can authorize later invocations regardless of arguments or affected resource; scope-level matching uses a parent identity when well-defined, otherwise falling back to exact-resource identity.Source: D AUTHORIZATION POLICY INSTANTIATION · p. 16
  • The fresh condition removes historical authorization while preserving authorization required by the current task; no-replay disables historical reuse.On these AgentDojo cases, no-replay and PAuth yield the same attack outcome because injected harmful capabilities are outside the task’s legitimate side-effecting behavior.Source: D AUTHORIZATION POLICY INSTANTIATION · p. 17
  • The PAuth implementation isolates task scoping and omits its additional operand-provenance analysis.Its result should therefore be interpreted as an evaluation of task scoping rather than a complete reproduction of PAuth.Source: D AUTHORIZATION POLICY INSTANTIATION · p. 17

E MOTIVATING CASE: PERSISTENT AUTHORIZATION IN CODEX

The Codex case traces how persistent approval becomes a reusable rule, and how a later matching command can affect filesystem access without renewed approval. The tests validate this authorization path and its contained consequence, not a continuous prompt-injection attack.

Approval source and persistent state

  • Persistent approval writes an allow rule to $CODEX HOME/rules/default.rules, retaining an argv prefix but not the originating task, project, or approval reason.The stored rule is reusable authorization state, distinct from the earlier command execution.Source: E MOTIVATING CASE: PERSISTENT… · p. 18

Authorization point and reuse

  • A later command matching a stored rule is admitted without renewed approval, and the same rule remains available across projects.Codex loads stored rules and compares a proposed command’s argv against their prefixes; a match admits it without a new approval request.Source: E MOTIVATING CASE: PERSISTENT… · p. 18

Observed consequence

  • The native sandbox rejects the marker write, while the execution mode selected after the persisted-rule decision permits it.The marker was placed outside the test workspace but inside a temporary, researcher-controlled directory.Source: E MOTIVATING CASE: PERSISTENT… · pp. 18–19

Containment and scope

  • The authorization and filesystem tests validate consecutive implementation properties, but do not record a continuous prompt-injection trajectory through Codex’s user interface.The reproduction used temporary local files and did not access third-party systems, credentials, or user data; operational payloads and bypass variants are omitted.Source: E MOTIVATING CASE: PERSISTENT… · p. 19

F END-TO-END ATTACK WALKTHROUGH IN GOOSE

The Goose walkthrough acquires a persistent shell grant during a legitimate task, then reuses it after script content changes. Fresh requires approval and withholds the action; Farmed proceeds without a target-action approval and creates the marker.

What outlives the original context

  • The persistent permission store retains only the shell-tool identity, not the approved command, script contents, project, or task justification.The stored native always-allow shell entry is carried from Acquire into Farmed after the context changes.Source: F END-TO-END ATTACK WALKTHROUGH IN GOOSE · pp. 19–20

Fresh and Farmed replay

  • Across all five repetitions, Fresh generated one or two target-action approval requests and no marker, while Farmed generated no such request and did produce the marker.Table 8 reports the native Goose replay for one archived portfolio-optimization repetition; the caption states the pattern across all five.Source: Table 8 · p. 20, F END-TO-END ATTACK WALKTHROUGH IN GOOSE · p. 20

Relation to the replay definition

  • With an empty authorization store, the target action reaches Goose’s approval boundary; with the restored grant, it is allowed without a corresponding approval request.The archived summary records MGoose(G0, a⋆) = ask, MGoose(Gh, a⋆) = allow, Q2 = 0, and H2 = 1.Source: F END-TO-END ATTACK WALKTHROUGH IN GOOSE · p. 20

Case construction and acquisition

  • The grant originates in a clean run through Goose’s ordinary approval workflow; the adversarial change comes later, in the script content.The legitimate portfolio-optimization task naturally requires a shell invocation, and the script is modified only after the grant is created.Source: F END-TO-END ATTACK WALKTHROUGH IN GOOSE · pp. 19–20

Evidence scope

  • Archived summaries preserve the permission store, target-action and approval counts, and marker outcome, but not the complete message-level ACP trace.The reported claims are limited to observed approval-boundary and effect fields, without inferring additional intermediate events.Source: F END-TO-END ATTACK WALKTHROUGH IN GOOSE · p. 20

G BOOTSTRAP CONFIDENCE INTERVALS

The bootstrap procedure estimates uncertainty in AgentDojo accumulated-minus-fresh ASR effects by resampling paired target clusters. At h = 64, the paper reports percentile 95% confidence intervals, with Claude treated as a negative control because it has zero successful attacks in both conditions.

Paired target-cluster bootstrap

  • Each bootstrap resample draws injection targets (suite, X, Z) with replacement while retaining all rows and paired fresh and accumulated outcomes for each target.Uncertainty is quantified separately for each model and history length.Source: G BOOTSTRAP CONFIDENCE INTERVALS · p. 20

Negative control

  • Claude’s empirical bootstrap distribution is degenerate because neither condition has successful attacks, so its observed zero effect is reported as a negative control rather than an informative interval.The procedure uses B = 2000 resamples with seed 20260907.Source: G BOOTSTRAP CONFIDENCE INTERVALS · p. 20

Reported intervals

  • The AgentDojo estimates at h = 64 are accumulated-minus-fresh ASR effects, with percentile 95% confidence intervals reported in Table 9.The supplied passage identifies the table’s scope but does not provide its cell values.Source: G BOOTSTRAP CONFIDENCE INTERVALS · p. 20, Table 9 · p. 21

Related papers

Loading 2609.33910v1…