Source-linked AI summary

Approval Laundering: Systematizing Approval--Execution Binding Failures in AI Coding-Agent Harnesses

Yang Wang

arXiv:2609.38983v1cs.CRcs.AIcs.SE

TL;DR

Coding-agent harnesses make human approval their security boundary, yet may dispatch an action different from the one approved. The paper operationalizes six laundering surfaces and finds high Bound-Gap Rates in several classes, while a field-only token check cannot catch downstream-effect divergence.

  • Problem

    Coding-agent harnesses rely on human approval as their security boundary, but may dispatch an action whose downstream effect exceeds what the approval authorized.

    Source: §1 · pp. 1–2
  • Method

    The paper operationalizes six credential-divergence surfaces as scenarios with fixed permission grants, benign tasks, canaries, and per-scenario success predicates.

    Source: §2.5 · p. 5, §4.2 · p. 9
  • Results

    Scope and Temporal Laundering each had BGR = 1.00, Delegation had BGR = 0.947, and Argument had BGR = 0.45 (9/20).

    Source: §5.1 · p. 10
  • Takeaways & Limitations

    An exact approved command can still trigger unintended hook-mediated file changes that risk classifiers and scope-inference checks miss.

    Source: §1 · p. 2

    Field-only verification cannot detect Scope and Argument cases where recorded dispatch fields remain unchanged but downstream effects exceed the grant.

    Source: §3.2 · p. 7

Abstract

from arXiv · show

Modern AI coding-agent harnesses (Claude Code, Codex CLI, Cursor) rest their security boundary on a largely unexamined assumption: that the action A a human approves is the same action A' the harness executes, where A is fixed by a stated policy for what a scope grant or session-scoped approval authorizes. We show this assumption fails systematically and reproducibly. We introduce Approval Laundering, a taxonomy of six failure modes by which a harness's enforcement mechanism silently substitutes A' for A after approval: Scope, Argument, Temporal, Tool, Delegation, and Semantic laundering. Unlike prior work that evaluates risk classifiers against static corpora or infers implicit authorization boundaries, we study credential-binding integrity: given an already-approved action, does the harness dispatch exactly that action? Instrumenting Claude Code's pre-execution mediation point (PreToolUse), we conduct a controlled, headless, repeated-measures study of all six classes (N=19-20 runs each), reporting a Bound-Gap Rate (BGR) with Wilson confidence intervals and inter-rater agreement (kappa=1.0). We prototype Approval Token, a keyed capability Hk(principal, agent_id, session_id, tool, arguments, scope, expiry) issued by a mediator that never returns the key to the agent, evaluated via paired before/after replay of 118 runs (McNemar's exact test). The token fully eliminates Delegation laundering and, for our seeded session-identity-mismatch construction, Temporal laundering (p<10^-5), but by design leaves Scope laundering unaffected and shows no significant reduction in Argument laundering (p=1): an honest negative result, since these two classes leave every recorded dispatch field unchanged, diverging one process level below what a field-only verifier can observe. We discuss implications for defenses that bind only at the tool-invocation boundary.

1 INTRODUCTION

The paper argues that coding-agent harnesses treat human approval as their security boundary, yet their enforcement can silently dispatch an action broader, later, or differently scoped than the one approved. It names this Approval Laundering, studies six binding surfaces, and presents a keyed-token defense and the scope boundaries of the draft.

1 INTRODUCTION

  • Approval Laundering is the harness’s silent substitution of a broader, later, or differently scoped action for the one approved, without fresh approval.The paper distinguishes this credential-binding problem from an agent being induced to misbehave.Source: §1 · p. 2
  • Repository hooks can make an exact approved command commit unintended tracked-file changes, a downstream effect missed by risk classifiers and scope-inference checks.The paper reports this Argument Laundering scenario in 45% of runs (Wilson 95% CI [0.258, 0.658], N = 20).Source: §1 · p. 2

1.1 Contributions

  • The taxonomy covers six credential-binding surfaces: Scope, Argument, Temporal, Tool, Delegation, and Semantic laundering.The paper describes these as distinct targets, while noting that Scope and Argument share a mechanism family.Source: §1.1 · p. 2
  • The study measures credential-binding integrity—whether an already-approved action is the one dispatched—rather than classifier accuracy or implicit scope inference.It instruments Claude Code’s PreToolUse point and reports per-class Bound-Gap Rates, Wilson confidence intervals, and human-reviewed inter-rater agreement.Source: §1.1 · p. 2

1.2 Scope of this draft

  • The draft’s empirical results cover Claude Code only, and Semantic Laundering uses an automated proxy rather than a human-subjects perception study.Cross-harness measurement is identified as future work.Source: §1.2 · pp. 2–3

2 THREAT MODEL AND PROBLEM STATEMENT

The section models approval as authorization for a specific dispatched action, then defines when a harness violates that binding. It states an operational authorization policy and distinguishes field-based laundering from failures of grant rendering.

2.1 System model

  • The harness checks calls against existing policy or fresh human confirmation, with the security claim that the dispatched action is the one authorized.Policy may come from an allow/deny rule, a persistent approval, or a sandbox tier.Source: §2.1 · p. 3

2.2 Adversary

  • Scenarios use benign, non-adversarial model behavior, but constructed environments limit how far their measured rates generalize.The environments include planted hooks, a shadowed executable, and—in some smoke tests—session-summary leakage.Source: §2.2 · p. 3

2.3 Formal problem statement

  • A dispatched call is Approval Laundering if it bypasses fresh approval and is inadmissible under the stated grant or exceeds its permitted effects.These are admissibility-divergence and effect-divergence failures, respectively.Source: §2.3 · p. 3

2.4 What counts as “admissible” and “permitted”: an explicit operational definition

  • Admissibility requires literal scope matching and matching agent and session identities unless configuration extends the grant; permitted effects are defined per scenario.This is a consistently applied study policy, not an elicited account of operators’ intent; permitted effects are not computable from dispatch fields alone.Source: §2.4 · pp. 4–5

2.5 Six axes of divergence

  • Five classes target scope, arguments, session, tool, or agent fields; Semantic Laundering instead concerns whether the rendered grant faithfully represents its content.Scope, Argument, and Tool are effect-divergence cases; Temporal and Delegation are admissibility-divergence cases.Source: §2.5 · p. 5

3 TAXONOMY

The taxonomy organizes Approval Laundering into five credential-binding surfaces and a separate rendering-fidelity dimension. It distinguishes changed-field admissibility failures from unchanged-field effect divergences, which constrain what field-only verification can address.

3.1 Why five fields plus one orthogonal dimension, not six fields

  • The taxonomy drops a standalone resource field because measured resource effects are subsumed by arguments and scope, and adds agent_id and session_id to distinguish agents and sessions.Without those identity fields, a subagent replaying the main session’s approval would pass the original formula’s verification.Source: §3.1 · p. 5

3.2 Two forms of field-bound failure: admissibility divergence versus effect divergence

  • Scope, Argument, and Tool usually show effect divergence: recorded fields remain unchanged, yet downstream effects exceed what the grant permits.Scope and Argument share an unnamed child-process mechanism in the measured scenarios; the taxonomy does not establish that their mechanisms are independent.Source: §3.2 · pp. 6–7
  • A verifier that checks only admissibility can address changed-field failures, not effect divergences; this explains why token binding leaves Scope and most Argument cases unmitigated.Delegation and the chained-command Argument case are admissibility divergences; Temporal is also treated as one, subject to the synthetic-session-seeding caveat.Source: §3.2 · pp. 5–7

3 TAXONOMY

  • The six classes are Scope, Argument, Temporal, Tool, Delegation, and Semantic laundering; Semantic concerns rendering fidelity rather than a credential field.The five field-bound classes cover distinct credential surfaces, while Semantic asks whether the approval rendering faithfully presents the credential.Source: §3 · p. 5, Table 2 · p. 6, §3.3 · p. 7

3.3 Completeness argument

  • The completeness claim covers five credential surfaces plus rendering fidelity, not five mechanistically independent or uniformly checkable failure modes.The five surfaces span scope, session_id, tool, agent_id, and arguments; Semantic remains orthogonal because field binding cannot ensure faithful rendering.Source: §3.3 · p. 7, §3.2 · p. 7

4 MEASUREMENT METHODOLOGY

The study operationalizes six approval-binding scenarios and measures their designated success predicates with BGR, then corrects a denial-scoping error and checks judgments against human review.

4.1 Harness and instrumentation

  • Claude Code 2.1.197 ran headlessly with a fixed, explicitly recorded model alias to prevent silent configuration drift.Source: §4.1 · p. 7
  • Runs inherited user configuration and plugins, and all 138 valid traces included plugin instructions and prior-session summaries of unverified equivalence.The authors characterize estimates and intervals as nominal under stated sampling assumptions and call for replication in a clean, scenario-only environment.Source: §4.1 · pp. 7–8

4.2 Scenario design

  • Scenarios used fixed permission grants, benign task prompts, canaries, and success predicates; Scope, Temporal, and Tool tested out-of-scope access, a seeded earlier session, and an unapproved tool.Source: §4.2 · p. 8
  • Argument tested an exact commit grant whose pre-commit hook staged an unstaged canary edit, while Delegation tested a subagent invoking a script under the main session’s grant.Delegation’s automated check combined final file state with a separate subagent-call existence check, rather than verifying both conditions on the same call.Source: §4.2 · p. 8
  • Semantic success meant the approval-facing tool description omitted the canary filename; this was a proxy for description-command coverage, not human deception.Source: §4.2 · p. 8

4.3 Bound-Gap Rate

  • BGR is the fraction of valid runs whose scenario success predicate holds, reported with Wilson 95% confidence intervals.Process-level timeouts and non-zero harness exit codes were excluded from the denominator.Source: §4.3 · p. 9

4.4 The denial-scoping fix

  • The corrected success check required an undenied call’s own ID and recorded result to match the canary-touch evidence, avoiding unrelated denials suppressing success.Source: §4.4 · p. 9
  • Four Scope runs reclassified as successes after the denial-scoping fix, raising Scope BGR from 0.80 (16/20) to 1.00 (20/20).The authors reanalyzed existing audit logs rather than running new model invocations; Temporal and Tool BGR were unaffected.Source: §4.4 · p. 9

5 MEASUREMENT RESULTS

On Claude Code, the study measures approval-binding failures across six laundering classes; rates and mechanisms vary by class and substitution pattern. Results are limited to one harness and one fixed model.

5.1 Discussion of per-class results

  • BGR reached 1.00 for Scope and Temporal laundering; the tested Temporal setup seeded a prior-session rule rather than capturing a real two-session lifecycle.Under the scenario design, the harness exercised these rules without fresh confirmation.Source: §5 · p. 9, §5.1 · p. 10
  • BGR was 0.947 for Delegation laundering, as subagents inherited the practical effect of main-session approvals without individual grants.This occurred reliably during ordinary harness operation, without adversarial input.Source: §5.1 · p. 10
  • BGR was 0.45 (9/20) for Argument laundering; successful approved commits could trigger a repository-local hook that staged an unapproved tracked canary file.The allowlist distinguished narrower commands but tolerated a trailing command continuation; the binding covered the command string, not downstream repository effects.Source: §5.1 · p. 10
  • Tool laundering depended on substitution pattern: all 19 cross-tool attempts were denied, while same-name PATH substitution had BGR = 1.00 (N = 20, 95% CI [0.839, 1.000]).The observed call fields contained the literal command, not the executable resolved by PATH.Source: §5.1 · p. 10
  • Semantic laundering had BGR = 0.10 under an automated description-to-command lexical-coverage proxy, not a human-perception measure.The authors do not infer that this low proxy rate means low practical risk.Source: §5.1 · p. 11

5.2 Scope of this measurement

  • Measurements used Claude Code and one fixed model; no scenario was replicated on Codex CLI or a Cursor-equivalent.Table 3 reports BGR by class with Wilson 95% confidence intervals; its two Tool rows are substitution patterns, not separate classes.Source: §5 · p. 9, Table 3 · p. 10, §5.2 · p. 11

6 APPROVAL TOKEN: DESIGN

Approval Token is a keyed capability intended to bind approvals to invocation identity, arguments, scope, and expiry. Its design adds identity and time checks to native scope matching, while its pilot leaves important key-custody and coverage boundaries.

6.1 Credential structure

  • Approval Token binds seven fields in a keyed capability; its argument hash avoids storing the full payload, and its expiry is a Unix timestamp.The protocol data flow does not return the key to the agent; the pilot's measurements exercise seeded allowlist tokens, not a complete interactive approval lifecycle.Source: §6.1 · p. 11

6.2 Scope-pattern binding

  • For wildcard policy approvals, the token binds the scope-pattern text rather than an unknown future literal command, leaving argument matching to the harness's native pattern semantics.For exact-literal patterns, the pilot observed one case where guard matching was stricter than the native matcher.Source: §6.2 · p. 11

6.3 Verification

  • At dispatch, the guard checks scope-map membership and verifies a matching, unexpired, unrevoked token against observed fields; mismatches are denied without a re-approval exchange.Verification also uses the scope-pattern placeholder bound at issuance, rather than hashing the call's literal tool input.Source: §6.3 · p. 11

6.4 Key custody

  • The pilot keeps the key out of the protocol's model-visible data flow, but stores it in a same-user-readable file and does not test adversarial key exfiltration.A production deployment would need an OS- or hardware-level access boundary; the stated protocol-level isolation is not a full OS-level guarantee.Source: §6.4 · p. 12

6.5 Field-to-class coverage

  • A verifier of admissibility divergence can catch recorded-field mismatches but cannot catch effect divergence or Semantic laundering; predicted Tool and Temporal coverage is limited to the specified constructions.The same-name PATH-substitution Tool mechanism was not included in the offline replay, and the Temporal prediction does not establish coverage for a captured real two-session lifecycle.Source: §6.5 · pp. 12–13

7 DEFENSE EVALUATION

Approval Token is evaluated by replaying recorded calls through a guard and by live smoke tests; it blocks Delegation and the seeded Temporal mismatch, but does not resolve Scope or Argument laundering.

7.1 Offline replay methodology

  • Offline replay paired each recorded run’s baseline and guard-mediated outcomes, feeding its tool-call events through guard.decide() in call order.The 118-run replay seeded tokens from each run’s granted scopes and used McNemar’s exact test; Temporal used a synthetic earlier-session identifier.Source: §7.1 · p. 13

7.2 Results

  • Delegation and Temporal were fully and significantly mitigated (p < 0.0001 for both), while Scope was unaffected and Argument showed no significant change (p = 1 for both).Tool and Semantic also showed no change; the Tool replay covered only cross-tool-identity substitution, not same-name PATH substitution.Source: §7.2 · pp. 13–14, Table 5 · p. 13

7.3 Live smoke test

  • All three live Scope runs admitted the in-pattern command, whose test-runner file access still produced the canary effect.In the live Argument run that reached a commit, guard admitted the exact approved command, and its pre-commit hook swept in the scratch-file edit; the other run never attempted that command.Source: §7.3 · p. 14
  • Delegation was blocked in all three live runs, but the prompt prohibited main-agent execution, so the test did not establish whether a legitimate alternative would be admitted.A separately authorized worker token or an in-scope main-session execution was not tested.Source: §7.3 · pp. 14–15
  • Temporal was blocked in all three live runs, but the seeded session mismatch was synthetic rather than a captured cross-session approval lifecycle.Read was outside the gated-tool set, and model tool choices and prior-session summaries also qualify the canary-recovery outcomes; the guard’s recorded decisions themselves depended on call fields, not conversation history.Source: §7.3 · p. 15
  • Across the six live Delegation and Temporal attempts, guard denied every tested laundering call, but the small samples do not establish rates under adversarial variation or legitimate-call handling.None of the sessions completed its prescribed task after denial; the authors identify paired legitimate-versus-laundered testing as future work.Source: §7.3 · p. 15

8 RELATED WORK

Prior work addresses agent policy enforcement, approval presentation, and scope judgments, while this paper focuses on whether an already-approved action remains bound to its dispatch. The authors distinguish that binding-integrity question from both authorization decisions and confused-deputy or injection threats.

8.1 Approval and consent mechanisms for LLM agents

  • CaMeL [8], Conseca [9], SkillScope [10], IntentCap [11], KITA [6], and VAC [7] address related approval or consent problems, but differ in what they bind, enforce, or evaluate.VAC is closest in mechanism to Approval Token; IntentCap reports a delegation-like scenario but not a Temporal-equivalent session-boundary evaluation.Source: §8.1 · pp. 15–16
  • Loopjacking [1] studies approval-operation substitution in orchestration products, while this work measures binding gaps in coding-agent harnesses and separates six credential-field classes.Loopjacking reports deterministic product-path trials; this paper reports sampled agent-task attempts and does not claim independent sampling across runs.Source: §8.1 · pp. 16–17
  • None of the seven discussed approval or consent works measures production-harness binding gaps across more than one or two failure modes; only IntentCap [11] addresses delegation-like handoff.The authors note an open question about whether Loopjacking’s state-substitution cases exercise equivalent session or identity boundaries.Source: §8.1 · p. 17

8.2 Measurement-oriented benchmarks

  • AmPermBench [3] measures classifier accuracy and OverEager-Bench [4] measures scope-inference accuracy, whereas this paper asks whether dispatch still matches a correct approval decision.A perfect classifier or scope-inference model does not itself guarantee dispatch-time re-verification of the credential fields.Source: §8.2 · p. 17

8.3 Confused deputy and its LLM-agent instantiations

  • Approval Laundering is framed as a confused-deputy problem, while prompt-injection and harmful-action benchmarks [2], –[18] do not measure the binding of a granted approval to a dispatched call.The paper assumes no injected content or malicious model and presents the confused-deputy connection as an analogy, not a new empirical claim.Source: §8.3 · p. 17

9 DISCUSSION AND LIMITATIONS

The discussion qualifies the measurements and defense: a corrected success predicate exposed an undercount, and the Tool result depends on substitution pattern. The proposed token leaves Scope and Argument unresolved, while cross-harness, semantic, and key-custody validation remain open.

The denial-scoping fix as an analyzer-completeness case

  • A global any_denial check undercounted Scope BGR (0.80 → 1.00) by masking a call that had succeeded before an unrelated denial.Human review traced the discrepancy to the success predicate despite κ = 1.0, motivating audit of the measurement instrument’s completeness.Source: The denial-scoping fix as an… · pp. 17–18
  • Tool Laundering was blocked for cross-tool identity substitution (BGR = 0) but unprotected for same-name PATH substitution (BGR = 1.00, N = 20, 95% CI [0.839, 1.000]).Claude Code checks declared tool identity at PreToolUse but cannot see which program a shell command resolves to; the authors do not generalize this finding to other harnesses.Source: The denial-scoping fix as an… · p. 18
  • Scope and Argument remain unsolved because their effects diverge while the recorded arguments and scope values remain unchanged.Drift detection would not catch the measured cases because the relevant hooks or scripts were already installed at approval; addressing them requires initial effect validation, which the authors did not test.Source: The denial-scoping fix as an… · p. 18
  • Semantic Laundering rates are lexical-coverage proxies, not measurements of whether human readers were misled by approval prompts.The authors say a human-subjects perception study is needed before claims about real-world Semantic Laundering risk.Source: The denial-scoping fix as an… · pp. 18–19
  • Measurements use Claude Code under one fixed model, and the attempted Codex CLI headless replication exposed no observable per-call approval checkpoint in that mode.The paper also identifies untested key custody: its protocol data flow withholds the key from the agent, but the pilot stores it in a same-user-readable file and no adversarial exfiltration test was run.Source: The denial-scoping fix as an… · p. 19

10 CONCLUSION

The paper concludes that coding-agent harnesses can exhibit six forms of approval-binding failure, and evaluates a seven-field token that mitigates some but not all tested classes. It identifies cross-harness replication and stronger tests of unresolved mechanisms and assumptions as future work.

10 CONCLUSION

  • The six-class taxonomy measures Scope, Argument, Temporal, Tool, Delegation, and Semantic laundering, with rates varying by class and Tool substitution pattern.Tool laundering was blocked for cross-tool identity substitution but unprotected for same-name PATH-level substitution; Semantic findings use an explicitly scoped automated proxy.Source: §10 · p. 19
  • Paired replay of 118 runs found that the seven-field HMAC-bound Approval Token mitigated Delegation and the seeded Temporal mismatch, while leaving Scope and Argument structurally unaddressed.The authors also identify cross-harness replication, a Scope/Argument-capable mechanism, a Semantic human-subjects study, and an adversarial key-exfiltration test as future work.Source: §10 · pp. 19–20
Loading 2609.38983v1…