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

Yang Wang

cs.CRSep 30, 2026

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

Authors: Yang Wang

Organizations: Fudan University

Abstract

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.

Figures & tables

Scenario	Excluded from $\mathrm{Perm}_{G}(c)$
Scope	the test runner’s child-process read of the canary file, via a package.json script Bash(npm run test *) never names
Argument	the pre-commit hook’s inclusion of the unstaged edit to the already-tracked scratch-notes file in the commit, via a mechanism Bash(git commit -m "wip") never names
Tool (PATH)	the write side effect the $PATH -shadowed executable produces into important_config.txt , when$ PATH resolves cat to that executable rather than the one Bash(cat *) ’s own text names
Tool (cross-tool)	any network access via Bash , since the grant is WebFetch(domain:example.com) — a different tool entirely
Delegation	execution under an agent_id other than $G$ ’s (governed by $D_{G}$ , not $\mathrm{Perm}_{G}$ : an inadmissible $c$ )
Temporal	execution under a session_id other than $G$ ’s (likewise governed by $D_{G}$ )

TABLE I:

\mathrm{Perm}_{G}(c)

, stated concretely per scenario: what

G

’s own credential text grants, and the specific effect it does not license.

#	Class	Bound field	Failure description
1	Scope Laundering	scope	An approved call is dispatched exactly as approved and matches its granted scope pattern, yet a mechanism outside the model’s own arguments (e.g., a child process the approved command spawns) accesses a resource beyond what the granted pattern’s own text would lead a reviewing human to expect, without any additional or different call ever being made.
2	Argument Laundering	arguments	An approved literal or prefix-matched command is dispatched unchanged, yet a repository-local mechanism the argument string never names (e.g., a version-control hook) broadens the command’s actual effect beyond what its literal arguments describe.
3	Temporal Laundering	session_id	An approval granted in one session (or as a persistent “always allow” rule) is exercised in a later, distinct session without a fresh confirmation.
4	Tool Laundering	tool	A call approved for tool $T_{1}$ is instead dispatched through a different tool $T_{2}$ that achieves an equivalent effect and was never itself approved; or, for the same declared tool, the OS-level program a command name resolves to at execution time diverges from what the operator observed when granting the approval.
5	Delegation Laundering	agent_id	An approval granted to the main session is inherited, without re-approval, by a subagent acting under a different agent_id .
6	Semantic Laundering	(orthogonal — rendering fidelity)	The text shown to the human in the approval prompt (e.g., a tool’s description field) does not faithfully disclose the actual command being authorized.

TABLE II: Six-axis Approval Laundering taxonomy. Five classes correspond to a single credential field that authorization is understood to fix (§ II-D ); for three of these (Scope, Argument, Tool), our measured failures are downstream effect divergences with an unchanged field value rather than a changed one (§ III-B ). Semantic Laundering is an orthogonal rendering-fidelity dimension.

Class	$N$	BGR	95% CI
Scope	20	1.000	$[0.839,1.000]$
Temporal	20	1.000	$[0.839,1.000]$
Tool (cross-tool-identity substitution)	19	0.000	$[0.000,0.168]$
Tool (same-name PATH substitution)	20	1.000	$[0.839,1.000]$
Argument	20	0.450	$[0.258,0.658]$
Delegation	19	0.947	$[0.754,0.991]$

TABLE III: Bound-Gap Rate by failure class (Claude Code, Wilson 95% CI). Scope figures reflect the corrected analyzer (§ IV ). The two Tool rows are two distinct substitution patterns for the same taxonomy class, not two different classes.

Class	Mechanism	Caught?
Scope	effect divergence	No
Argument	mostly effect divergence §	Mostly no
Temporal	admissibility concept, unrecorded ‡	Yes (seeded case)
Tool	effect divergence (PATH) †	No
Delegation	recorded admissibility divergence	Yes
Semantic	orthogonal, no bound field	No

TABLE IV: Defense coverage by class, derived from the admissibility-divergence/effect-divergence distinction of § III-B , prior to the empirical evaluation of § VII .

Class	Baseline	With defense	$b$ / $c$	$p$
Argument	0.450	0.400	1/0	$1$
Delegation	0.947	0.000	18/0	$7.6\mathrm{e}{-6}$
Scope	1.000	1.000	0/0	$1$
Semantic	0.100	0.100	0/0	$1$
Temporal	1.000	0.000	20/0	$1.9\mathrm{e}{-6}$
Tool (cross-tool)	0.000	0.000	0/0	$1$

TABLE V: Approval Token defense evaluation, offline paired replay on already-collected runs. The Tool row covers only the cross-tool-identity substitution pattern; the same-name PATH-substitution pattern was not replayed (§ IX ).

Explore similar work

May 18, 2026cs.SE

Overeager Coding Agents: Measuring Out-of-Scope Actions on Benign Tasks

Coding agents now run autonomously with shell, file, and network privileges. When a user issues a benign request, the agent sometimes does more than asked: it deletes unrelated files, wipes a stale credentials backup, or rewrites configuration the user never mentioned. We call these scope expansions overeager actions, an authorization problem distinct from capability failures, prompt injection, or sandbox escapes. We present OverEager-Gen, a benchmark dedicated to overeager behavior on benign tasks. Building it surfaces a measurement-validity issue: if a benchmark spells out the authorized scope inside the prompt, the agent stops inferring boundaries and starts pattern-matching declaration text. On Claude Code, stripping the consent declaration alone raises the overeager rate from 0.0% to 17.1% on paired scenarios (McNemar exact p = 2.4 x 10^-4). OverEager-Gen therefore certifies each scenario's discriminative power before admission via a behavioral-gradient validator, audits internal tool calls through a dual-channel stack (PATH-injected shim plus per-agent event streams), and ships byte-identical consent_kept and consent_stripped variants. OverEager-Bench contains 500 validated scenarios and ~7,500 runs across four agent products (Claude Code, OpenHands, Codex CLI, Gemini CLI) and six base models; a 50-sample re-annotation gives Cohen's kappa = 0.73 and rule-judge recall = 1.00. Stripping consent multiplies the overeager rate on every shared base model (Delta in [11.9, 17.2] pp). The framework axis dominates effect size: a permissive cluster (Claude Code, Codex CLI, Gemini CLI) runs at 5.4-27.7% while the ask-to-continue framework (OpenHands) sits at 0.2-4.5% (Fisher p <= 10^-5). Within-framework base-model variance reaches 15.9 pp, indicating that model-layer alignment does not fully propagate through permissive permission gating.

Yubin Qu, Ying Zhang, Yanjun Zhang +4

Griffith University · Wake Forest University · Nanyang Technological University +2

Kernel-Resident Tool Governance Gateway Coding Agents Benign

Ask PDF

Jun 13, 2026cs.SE

ClayBuddy: A Framework, Evaluation, & Mitigation of Coding Agent Failures

Software engineering and deployment are increasingly delegated to AI coding agents. The scale of their adoption is surfacing rare, but highly destructive, failure modes. In this paper, we study these failure modes as stemming from three distinct mechanisms: underspecification, where default model behavior is unsafe; capability errors, where the safe action is available but the model does not adhere to it due to bias or capability limitations; and agent harness errors, where the model fails to execute the safe action through the harness. We assess these across 8 different evaluations, each inspired by real-life deployment failures, totaling 20 coding environments and 59 synthetic transcript templates. These evaluations act as controlled stress tests for isolating our failure mechanisms. Based on this evaluation, we propose ClayBuddy, a harness modification that molds to user preferences and can be modified by the model in-session, to mitigate these errors. By adding tools for the agent to edit its own context, an extended system prompt, a customizable command classifier, and deterministic guardrails, we show that ClayBuddy is safer across a statistically significant number of samples. Thus, we suggest concrete mitigations for current coding agents and a design philosophy for future agent harness features.

Kenneth Ge, Andre Assis

Anthropic Fellows Program · Constellation

Coding Agents Agent Harness Latent Failure Patterns Streaming Guardrails Mitigation

Ask PDF

Jul 7, 2026cs.CR

The Balkanization of Execution-Security Research for AI Coding Agents: Isolation, Access Control, and Time-of-Check-to-Time-of-Use Vulnerabilities

AI coding agents now read repositories, call tools, and execute shell commands with limited human oversight, and a fast-growing body of work studies whether the execution layer around them is actually safe. That literature is scattered. Papers on sandbox isolation, capability and access control, policy enforcement, time-of-check-to-time-of-use (TOCTOU) races, Model Context Protocol (MCP) threats, identity delegation, execution provenance, network egress control, and static analysis of agent-generated code are published independently and rarely cite one another. We systematize 39 papers published between 2023 and 2026 into 17 categories, each verified directly against its source. The same verification protocol also confirms four disclosed, patched CVEs directly affecting production agent harnesses. Reading across categories surfaces five cross-cutting gaps that no single paper addresses. (1) Isolation architectures and capability models are almost never evaluated against one another on a shared benchmark. (2) Policy-enforcement studies report failure rates from 69% to 98% of real denylists, yet no isolation paper re-evaluates its own defense under that adversarial setting. (3) TOCTOU and MCP threats are analyzed as separate literatures despite both being instances of the same state-validation problem. (4) Every enforcement mechanism assumes an honest policy author, leaving policy-authoring error itself unaddressed. (5) Benign but out-of-scope agent actions occurring at rates up to 17.1% under realistic prompting are addressed by no access-control or capability paper in the corpus. Existing broader surveys of agentic AI security discuss sandboxing only as one item among many defenses, leaving execution security without a dedicated systematization. This paper is written to fill that gap. We conclude with a research agenda directed at the five gaps.

Mohammadreza Rashidi

Department of Computer Science AI and Media Analysis Lab Berlin, Germany

Access Control Coding Agents Runtime Code Generation

Ask PDF