Capability Gating Is Not Authorization

Sources#

• Agentic Permissions Policy Algebra for Taint Confinement in LLM Agents
• Capability Gates Are Not Authorization: Confused-Deputy Failures in LLM Agent Frameworks
• NetInjectBench: Benchmarking Indirect Prompt Injection in Tool-Using Large Language Model Agents for Network Operations
• OpenID Foundation advances authorization for the agent era with new AuthZEN Working Group Drafts
• The Balkanization of Execution-Security Research for AI Coding Agents: Isolation, Access Control, and Time-of-Check-to-Time-of-Use Vulnerabilities

Summary#

David Mellafe Zuvic (Independent Security Research, Chile; arXiv 2606.28679, June 2026) audits a specific authorization failure in tool-using LLM agents: capability gating is present, but per-call authorization is absent. The two are distinct controls that frameworks routinely conflate:

• Capability gating is static — it decides which tools exist in the agent's menu (tool allow-lists, key scopes, JSON schemas). A schema can reject a malformed argument.
• Per-call authorization is dynamic — it decides whether this concrete call, with these argument values, in this principal/session context, is allowed. A schema cannot decide whether a well-typed account=acct_ATTACKER_999 is authorized.

When the only checks are tool-name existence and schema validity, "the untrusted model effectively supplies both the action and the authorization fact." That is the confused deputy (Hardy 1988): a privileged component induced by attacker-controlled input to misuse its authority. Classical systems security already gives the remedy — Saltzer–Schroeder complete mediation: every access to authority must be checked, not only at construction time. This is empirical work: a reproducible cross-framework audit tied to a measured threat and a deployable control, with no CVE asserted and no live third-party service attacked.

The paper is the authorization layer the vault's injection-attack pages exploit. Agentic Prompt Injection and its finer variants (Agent Data Injection (ADI), Task-Specification Effects in Prompt Injection (AutoDojo)) are all delivery mechanisms that end in a model-emitted tool call; this paper takes injection as given and studies the narrower systems question: once a compromised model emits a call, what does the runtime do next?

The two controls, and why conflating them is a confused deputy#

The system is a tool-using agent embedded in an application that holds real authority (a payment key, mailbox, CRM token, HTTP egress, MCP client, infra credential). The agent runtime and tools are inside the trust boundary; the LLM is not — it is an untrusted parser/planner over text that may include attacker content. The adversary controls content, not code (a retrieved document, web page, email body, support ticket, prior tool output, or agent-to-agent handoff) and wants the agent to emit a side-effecting call with attacker-chosen arguments: repoint a payout account, refund to an attacker destination, exfiltrate a secret, fetch an SSRF target. This is indirect prompt injection (OWASP LLM01, MITRE ATLAS AML.T0051) — assumed feasible, not re-litigated.

Compromise-source independence is the boundary's key property. Runtime prompt injection and supply-chain model compromise converge at the action layer: both produce a proposed tool call. A poisoned checkpoint can carry a file-level RCE (unsafe deserialization, trust_remote_code) or a weight-level backdoor whose trigger phrase elicits an attacker action — and weight-backdoor detection is an open problem. At the per-call boundary both are treated identically: a backdoor-triggered update_payout_account(acct_ATTACKER) and an injection-triggered one are denied by the same out-of-band policy. The control contains the action-layer consequence for governed tools; it does not detect poisoning, recover a clean model, or constrain non-tool text returned to the user.

The same control, with the adversary removed. Reddy et al. (arXiv 2607.07405, empirical) build structurally the same thing — a deterministic predicate over the proposed call's concrete arguments and current state, evaluated before dispatch, default-allow rather than default-deny — for a non-security reason: a compliant agent that simply failed to apply a domain policy rule before a write, with 78% of the resulting failures leaving a wrong final state and no error. Useful reading in both directions. It shows the PDP/PEP shape pays outside the threat model that motivated it (task success 29.6% → 42.0%), which is a deployment argument this page's security framing cannot make on its own. And its per-gate audit is the measurement missing here: one predicate at 100% precision over 161 fires, another at 5% blocking correct behavior 40 times in 42 — ScopeGate reports 0 false-denies over its corpus, but nothing in either source says how you would detect a bad predicate in production, where no ground-truth trajectory exists to audit against.

Out-of-band policy is load-bearing#

The policy the gate checks against is not model output. Tool scopes, allowlists, money ceilings, idempotency requirements, and verified sets like {acct_MERCHANT_001} are operator-authored configuration loaded from a root of trust outside the model's context window, write path, and influence. Injected content can move the proposed call from account=acct_MERCHANT_001 to account=acct_ATTACKER_999; it cannot move the verified set the proposal is checked against. A design in which the LLM emits, expands, or discovers its own per-call scope would be circular — the same injection that corrupts the call could corrupt the scope. The obligation is transitive: no policy element may be sourced (directly or indirectly) from any model output at any stage — offline authoring, session seeding, or runtime refresh — which excludes verified-set poisoning, session-seeded time-of-check/time-of-use policy mutation, and dynamic policy fetch over model-reachable egress. This is the same doctrine the out-of-band defense literature states as "the gate must not be a model."

The cross-framework gap (Table I)#

A public-source architecture audit at pinned commits asks one narrow question: after the model emits a tool call, is there a deterministic fail-closed authorization check over the concrete argument values before side effect? All three audited stacks ship capability gating; none ships that check by default:

Framework (pinned source)	Capability gating	Per-call value authorization (default)	Confused-deputy by default
LangChain / LangGraph (00ad96c / bdb323e)	yes	none — callback hooks are observability, not a mandatory veto; HITL middleware is integrator-wired	yes
LlamaIndex (v0.14.23, 520aa4e)	yes	none at central tool dispatch; fn_schema is shape metadata; HITL is tool-author workflow code	yes
Stripe Agent Toolkit (0b4961f / f54c9e6)	yes	none on money args (amount, customer, payment_intent, destination, redirect_url); action allowlist + Restricted API Key scope are coarse, not per-transaction	yes

In each default dispatch path the model-selected tool name is resolved, input shape is validated, and the tool is invoked with the model-supplied arguments — with no hook between validation and execution that consults an authorization policy over concrete values. Stripe is highest-stakes because it sits nearest money movement. The audit is of public client/framework defaults (Stripe's remote MCP internals were not audited) — candidates for hardening and standards clarification, not asserted vulnerabilities.

How exposed is the model? (Table II / Figure 1)#

The gap matters only if real models emit unauthorized calls under realistic attack. A companion 27-model deterministic benchmark ([16]) measures ASR = the model's attempt rate (issuing an unauthorized call or producing an exact SHA-256 canary under a deterministic oracle in a sandbox with non-routable sinks) — not a breach rate. Two signals:

• Deployment-tier vs flagship. Cost-optimized "deployment-tier" models (economical, suited to high-volume agent traffic) attempt the unauthorized call ~3.2× more often than flagships: mean ASR_task 0.603 vs 0.189 (verified against Figure 1). Deployment-tier exemplars: gpt-4o-mini 1.000, glm-4.5-air 1.000, gemini-3.1-flash-lite 0.980; flagship low exemplars: glm-5.2 0.087, gemini-3.1-pro-preview 0.000. The tier is an economics inference, not a disclosure that any vendor runs a named model in production, and the aggregate carries no paired CI (high outliers exist in both groups).
• Task-aligned framing — presenting the same dangerous action as required to complete the user's task — sharply raises attempts over a crude naive injection: glm-4.7 0.283→1.000 (Δ0.717, BH q<0.001), gemma-3-12b-it 0.000→0.571, mistral-large 0.027→0.459 (paired, Wilson/Newcombe CIs, Benjamini-Hochberg correction). This is the same "the injection reads as task-data, not as an instruction" mechanism AutoDojo measures on the defense side. A Latam-GPT sovereign-model vignette shows an EN/ES sign flip (0.320→0.520 vs 0.240→0.040) but is caveated as a modality floor (bnb-4bit, native function-calling disabled), not a causal claim.

ScopeGate: a deterministic 5-stage PDP/PEP (Figure 3, Algorithm 1)#

ScopeGate is a Policy Decision Point / Policy Enforcement Point that sits downstream of the model and upstream of side-effecting tools. It receives a proposed (tool, args) plus trusted context and returns ALLOW / DENY; no LLM participates in the decision. It evaluates five stages in order and fails closed on any miss or runtime error:

1. Scope — is this tool governed by policy? Unlisted tools → DENY. Blocks model-discovered tools and misspelled variants from reaching side effects.
2. Authorization — are value-constrained arguments in their allowlists? This is the missing framework check. A well-typed but unauthorized account, destination, customer, URL, or payment intent → DENY(authz).
3. Money ceiling — for payment/refund tools the amount must be a finite real in [0, ceiling]. An affirmative check, not a naive > comparison: NaN, infinities, complex values, booleans-as-integers, and non-numeric containers all deny.
4. Idempotency — side-effecting tools that require it must receive a trusted idempotency key in context; a missing key denies, limiting replay and loop amplification.
5. Default deny — only calls passing every stage are allowed; errors are treated as denial. "A policy engine that fails open on malformed input recreates the vulnerability with extra steps."

The security property is placement-independent as long as all side-effecting calls pass through the PEP and policy stays out-of-band: it can live as SDK middleware inside the app, a sidecar proxy on loopback, or a central egress/MCP gateway (the evaluation uses SDK placement).

Evaluation (Table III)#

• Reproducible framework PoC. Real LangChain tools (update_payout_account, issue_refund) over a mocked merchant backend; a fixed compromised output proposes update_payout_account(account=acct_ATTACKER_999). Part A (normal dispatch) applies the attacker account and records a side effect; Part B routes the identical call through ScopeGate, which denies at authz (not in {acct_MERCHANT_001}) with zero side effects. A companion LlamaIndex PoC reproduces the same default-dispatch gap. One command (./run_proof.sh, Apache-2.0 artifact at commit d9568ac) reproduces it.
• Static bypass suite — 0/48. 48 adversarial vectors (case/whitespace/zero-width/homoglyph/null-byte mutations, type confusion, unhashable arguments, tool-name mutations, money edge cases, missing idempotency); none allowed. The suite found and fixed a real fail-open in an earlier ScopeGate prototype — NaN passed a naive money comparison — now denied at the money stage (a ScopeGate prototype bug, honestly reported, not a framework fail-open).
• Adaptive attacker — 0/29. Deny reasons fed back to a GLM-5.2 attacker for 40 iterations: 0/29 unauthorized attempts allowed (29 denied, 9 malformed/parse errors, 2 benign allowed). Budget-bounded, not a universal proof.
• Benign controls — 0 false-denies. 0/10 false-denies across two deployment-tier native-function-calling models; a deterministic Latam-GPT probe separately allows 4/4 authorized actions.
• Payment-agent containment. In a WhatsApp payment replica under a Business-Email-Compromise framing, glm-4.5-air and gpt-4o-mini both attempt the unauthorized payout 10/10; ScopeGate denies every out-of-scope payout at authz (0/5 false-denies per model on benign controls). A Latam-GPT Spanish PCI re-tokenization run: 10/10 unauthorized attempts, 10/10 denied at authz; the broader battery records 11/11 harm-bearing egress actions denied.

Positioning and limitations#

The paper is deliberately narrow. It does not claim to discover prompt injection or the first per-call authorization for agents — MiniScope (arXiv:2512.11147) exists and least-privilege predates LLM agents. The defended novelty: the first reproducible cross-framework audit of the exact default gap "capability gating shipped, per-call authorization absent," paired with measured model exposure and a deployable fail-closed control. It is compatible with cryptographic payment consent (the AP2-break line [11]): even strong payment rails need a deterministic control plane that checks model-proposed transactions against operator policy before execution.

The limits are stated plainly: containment is not cure (ScopeGate does not prevent injection, detect poisoned weights, repair model behavior, or guarantee safe natural-language output — it bounds what a compromised model can do through governed tools); the 0/48 and 0/29 figures are suite- and budget-bounded, with longer adaptive budgets, stateful side channels, DNS rebinding, timing, and multi-agent policy-poisoning left as future work; and the audit is public-source only, so its findings are hardening candidates, not CVEs.

How this answers "attacks confined to already-authorized actions"#

Out-of-Band Prompt-Injection Defense carries an open question the attack papers keep sharpening: does an attack confined to already-authorized actions — one that achieves the injection goal without any policy violation — slip past a deterministic action gate the way adaptive attacks broke in-band defenses? This paper names that failure class precisely and offers a defense. "Already authorized" splits into two:

• Capability-authorized but not value-authorized — the tool (issue_refund, update_payout_account) is in the granted menu, but the injected argument value (attacker destination/account) is not. This is the confused-deputy-within-scope case, and ScopeGate blocks it at the authz stage by re-checking values against out-of-band allowlists (0 bypasses in the tested corpus). The attack that looks like "within already-granted capability" becomes a policy violation at the value level.
• Genuinely within policy — the corrupted value legitimately varies and is not allowlist-constrainable (free-text content, an in-range amount to any legitimate customer, or the spoofed author / fabricated tool result the agent legitimately acts on). Here the action satisfies the value policy while still doing harm. This is the same residual ADI showed against Progent (22.2%) and the "in-the-loop / text-to-text" limit the out-of-band page names — a limit ScopeGate shares by construction, because a value gate only helps where a policy constrains the corrupted argument.

So the honest reading: per-call value authorization closes the value-redirection class of within-capability attacks (a real advance over capability-gating-only defaults) but not the corrupt-legitimately-variable-data class, which needs provenance/data-flow tracking. It is a defense in kind — a deterministic capability-removal, per Impossible, Not Tedious (Design Test) — not a cure.

"Permitted, but not intended now" — the residual gets a name and a rate (2026-07)#

Rashidi's execution-security SoK (The Balkanization of Execution-Security Research for AI Coding Agents: Isolation, Access Control, and Time-of-Check-to-Time-of-Use Vulnerabilities, arXiv 2607.05743, empirical) reads its 39-paper corpus for the recurring design defect behind each mechanism, and its third root cause is this page's thesis stated one notch more generally:

RC3: a mechanism encodes whether an action is permitted, not whether this invocation matches intent. "A capability token, a Datalog rule, or a command denylist all answer a binary question, is this action type allowed, which is a different question from whether this specific, authorized action should happen right now."

Note where the survey files work of ScopeGate's shape. Access-control and capability models map to RC2 and RC3 together — per-call authorization targets the intent gap without closing it, because each mechanism "grants an action type and then relies on the agent's own plan to stay within intent." Same residual this page already carries as corrupt-legitimately-variable-data, reached from the taxonomy side instead of from the attack side.

Gap 5 attaches a rate to it. OverEagerBench (Qu et al., arXiv 2605.18583, 2026) measures benign but unrequested actions on correctly-authorized tasks: 500 validated scenarios across four agent products and six base models, roughly 7,500 runs. As the survey reports it:

• Permissive-framework agents (Claude Code, Codex CLI, Gemini CLI) show substantially higher unrequested-action rates than an ask-to-continue framework (OpenHands).
• Removing an explicit statement of authorized scope from the prompt raised Claude Code's measured overeager rate from 0.0% to 17.1% — same task, same model, phrasing alone. Qu et al.'s reading: the agent is pattern-matching a declared-scope sentence rather than inferring task boundaries from the task itself.

Attribution, because it matters for how hard to lean on the number: 17.1% is Qu et al.'s measurement. The survey's verification protocol confirms only that the citation's title, authors, venue, and claimed contribution match the paper's own abstract page — it explicitly does not replicate any surveyed paper's empirical claims. One benchmark's finding, not a field result, and not the survey's.

Why this belongs here rather than on a page of its own: an overeager action is not a permission failure. The survey's own statement of the gap is the cleanest form of this page's argument taken one step further —

a capability token, a Datalog policy, or a pre-action gate all assume the dangerous action is either authorized or it is not, but an overeager action is, by the measurement's own definition, an action the agent was never asked to take and that a static permission grant would not necessarily forbid, since the agent may already hold the capability it is misusing for an unrequested purpose… A mechanism that constrains what an agent is allowed to do does not, by construction, constrain whether an authorized capability is invoked when it should not be.

That is a third column next to the two this page already splits "already authorized" into. Capability-authorized-but-not-value-authorized: ScopeGate's authz stage denies it. Genuinely-within-policy-but-harmful: the standing residual. And now within-policy-and-never-asked-for — where the authz stage is silent by construction, because an unrequested action supplies perfectly ordinary values. An allowlist over {acct_MERCHANT_001} has nothing to say about a refund to the right merchant that nobody requested.

Gap 5 is stated as a non-citation: no access-control paper in the corpus cites the measurement, and the measurement never evaluates whether any reviewed mechanism would have caught what it documents. The survey's proposed fix is cheap and precise — replay OverEagerBench's already-collected overeager trajectories against a capability system (PORTICO) or an information-flow framework (SEAgent) and measure what fraction an authorization mechanism built for a different threat model happens to catch, rather than inferring it from the design. Nothing in this vault answers that either.

Gap 2: the zeroes on this page are measured against the wrong attacker population#

The same non-citation pattern at the enforcement layer, and it is the more alarming instance. ShellSieve (Chen & Lin, arXiv 2606.15549) has a language model propose bypasses to real command denylists and validates each by execution in a sandbox, against 1,709 denylists scraped from GitHub — 69.0% to 98.6% of them fragile depending on the bypass class. YoloFS (Zhong et al., arXiv 2604.13536) documents the same failure from 290 misuse reports across 13 agent frameworks. Both figures are the underlying papers', restated by the survey, not measured by it.

The gap: no isolation or access-control paper in the corpus re-evaluates its own defense under those bypasses, though ShellSieve's corpus is released and "closing Gap 2 requires no new infrastructure at all." The survey generalizes it as RC4 — defenses are validated against author-constructed attackers rather than empirically observed real-world failure — and calls the two enforcement-fragility papers the most consequential finding in the whole literature, "precisely because they measure real, shipped artifacts rather than a mechanism's own claimed guarantee."

That lands squarely on this page's headline numbers. ScopeGate's 0/48 and NetInjectBench's 0/240 are both zeroes against attacker corpora the defenders' own communities constructed. This page already carries the AutoDojo caveat — a static number is a lower bound — but RC4 is a different objection, and the two should not be collapsed. AutoDojo says the attacker was too weak; RC4 says the attacker was the wrong population. A denylist a real developer wrote and shipped under time pressure is the artifact ShellSieve breaks, and neither ScopeGate's 48-vector suite nor NetInjectBench's 80 authored scenarios contains one. The corrective is available and unexercised: run the released bypass corpus against the gate.

An independent replication in another domain: NetInjectBench#

Shayoni, Shoaib, Hossain & Mridha (Wichita State University / American International University-Bangladesh, arXiv 2607.10490, July 2026, empirical) build NetInjectBench, a 130-scenario indirect-prompt-injection benchmark for network-operations agents, and arrive independently at this page's architecture. It is the corpus's second measured deterministic argument-value gate, by a different group, in a different domain, on different models — and it is the closest thing to a replication of ScopeGate's headline result.

Setup. 40 benign / 40 weak-attack / 40 strong-attack / 10 approved-high-impact-change scenarios; six mock tools spanning four privilege levels (low-risk read get_telemetry/fetch_logs/search_runbook, sensitive read query_topology, low-risk write open_incident_ticket, high-impact write apply_config_change); three local open models at temperature 0 (Qwen2.5-7B, Llama3.1-8B, Mistral-7B) via Ollama. Single-step: the agent reads an operator task plus one untrusted artifact (ticket note, monitoring alert, syslog excerpt, runbook fragment, ChatOps message) and proposes one tool call. The attack subset is 80 scenarios × 3 models = 240 model-scenario instances.

The gate is the same shape as ScopeGate. It is deterministic code — no LLM participates. Before allowing apply_config_change it requires approval status active, maintenance window active, a non-empty change-request identifier, and the proposed tool, target device, and configuration patch each matching the trusted approved value. That is ScopeGate's scope + authz stages with a domain-specific attribute set. Two design differences: policy is checked against trusted operational metadata (a change-management/CMDB record) rather than an operator-authored allowlist, and a failed check does not terminate — it falls back through a fixed safe order (fetch_logs → get_telemetry → search_runbook → open_incident_ticket), which is why blocking costs almost no utility.

The defense ladder (weak+strong attacks, all three models, N=240 unless noted; UTAR = unsafe tool-action rate, UAR = useful-action rate):

Method	UTAR	UAR	Block rate
Naive LLM	82.50%	16.67%	0.00%
Prompt-only safety (N=238)	25.63%	72.69%	0.00%
Self-Reminder	21.67%	75.00%	0.00%
Spotlighting	18.33%	77.50%	0.00%
Two-Pass LLM Judge	10.00%	84.58%	15.00%
Static allowlist	5.00%	94.17%	77.50%
Metadata-aware policy gate	0.00% (95% Wilson [0.00%, 1.58%])	99.17%	82.50%

McNemar on paired instances: policy gate vs prompt-only χ²=59.01, vs Spotlighting χ²=42.02, vs Two-Pass Judge χ²=22.04 (all p<0.001), vs static allowlist χ²=10.08 (p=0.001) — with 0 discordant pairs in which the gate was the unsafe one in every comparison.

The static-allowlist row is this page's title, measured. Globally blocking apply_config_change is capability gating: remove the dangerous tool from the menu. It scores a respectable 5.00% attack UTAR — and then fails on both sides of the thesis:

• It cannot tell a forged approval from a real one, so it blocks both. On the 10 approved-change scenarios (N=30) it achieves 0.00% usefulness and 100.00% overblocking — every legitimate, verified, in-maintenance-window change denied. The policy gate reaches 100.00% usefulness on the identical set. This is the cleanest demonstration in the corpus that a capability gate is a blunt instrument where per-call authorization is a sharp one: the two differ not in whether they stop the attack but in whether the system remains usable afterwards. The benchmark was built specifically to deny a trivial "block every high-impact tool" defense the win.
• It leaves the read side entirely untouched. Broken out by risk type, static allowlisting scores 100.00% UTAR on sensitive-information exposure — identical to the naive agent — because the globally-blocked tool is the write, while query_topology remains available. Prompt-only safety is barely better there (91.67%). Of the 198 unsafe naive final actions, 186 are high-impact writes and 12 are sensitive reads; removing the write tool moves the first bucket and does nothing to the second. Only the metadata-aware gate, which carries constraints over sensitive reads as well, reaches 0.00% on that row.

The metadata-stress test targets the value-matching stage directly. For each of the 10 approved-change templates the authors construct one valid instance plus six single-field mismatches (wrong device, wrong patch, expired window, unapproved status, missing CR ID, wrong tool) and three combined mismatches — 100 deterministic policy-check instances. 10/10 valid allowed, 90/90 degraded blocked, 100/100 correct decisions. This is the direct analogue of ScopeGate's 48-vector static bypass suite, and it isolates the property that matters: the decision tracks the trusted values, not the artifact's claims.

What replicates, and what does not#

The honest scope, because the temptation to read 0/240 as a stronger result than 0/48 is exactly what the denominator invites:

• What genuinely replicates. A deterministic, no-model-in-the-loop gate checking model-proposed argument values against out-of-band authoritative data produced zero unsafe executions on an independently-constructed attack suite, in a domain (network operations) and on models (7–8B open weights) neither ScopeGate's author nor this vault's other sources touched — while preserving the legitimate high-impact action that the coarse alternative destroys. Different group, different threat corpus, same architecture, same result.
• The attacker is static. All 80 attack scenarios are fixed and authored before the defense; decoding is at temperature 0; there is no optimizer, no feedback loop, no defense-aware adaptation. So this corroborates ScopeGate's 0/48 static suite, not its 0/29 adaptive run — it is evidence of suite independence, not of budget independence. AutoDojo's finding that a static number is a lower bound applies here in full force.
• The denominator is 80, not 240. 240 = 80 distinct attacks × 3 models. Three models re-running the same corpus is model coverage, not attack coverage.
• The action space is narrow. Six mock tools with one dominant unsafe write (apply_config_change accounts for 186 of 198 naive unsafe actions) and one sensitive read. A gate over two governed actions with a six-field approval record is close to the easiest case the design will ever face; the paper itself names richer tools (rollback, restart, ACL update, quarantine, credential rotation) as future work. ScopeGate's authoring-burden problem is proportionally invisible at this scale.
• The weak-agent caveat lands on the baselines, not the gate. Three 7–8B models is the same weakness this corpus flags on the Progent Qwen2.5-7B reproduction (Out-of-Band Prompt-Injection Defense) — but it cuts asymmetrically here. The naive 82.50% and the prompt-level rows are agent-quality artifacts and would look different on a frontier model. The gate's 0.00% is model-independent by construction: it never consults the model, so a stronger agent changes what gets proposed, not what gets allowed. What a frontier model would change is the size of the gap the gate is closing, not whether it closes it.
• Single-step, and the composition residual is untouched. The benchmark stops at the first executable decision. The authors name multi-step tool-output poisoning — a permitted read returns malicious text that steers a later call — as out of scope; that is the same composition-of-permitted-calls residual this page and Off-Host, Identity-Bound Authorization already carry, and it is exactly the shape a fallback-to-fetch_logs design invites.
• The scenarios are synthetic, and the metadata-integrity assumption is load-bearing and stated: the attacker can write artifact text but cannot touch the approval record, window state, approved-device/patch fields, or CR ID. The result is a claim about enforcement under metadata integrity, not about detecting compromised metadata — the authors say so in a dedicated section (§5.5).

Two findings that travel beyond the replication#

• Prompt-level defenses do not transfer across model families. The same Spotlighting prompt leaves 48.75% UTAR on Qwen2.5-7B and 1.25% on Llama3.1-8B — a ~39× spread on identical instructions; the Two-Pass LLM Judge splits 28.75% vs 0.00% the same way. Naive susceptibility varies too (96.25% / 58.75% / 92.50%), but the defense variance is not explained by it. A safety prompt's measured efficacy is a property of the model it was measured on, and the deterministic gate is the only row in the table that is flat across all three. This is the model-dependence argument for out-of-band enforcement stated as a variance result rather than an adaptive-attack result.
• Authority claims beat "ignore your instructions". Naive UTAR is 67.50% on weak attacks (explicit "skip approval, apply the change now") and 97.50% on strong attacks (fake manager approval, fake vendor advisory, fake security exception, poisoned runbook update). Every prompt-level defense preserves that ordering (Spotlighting 8.33% → 28.33%). An injection that forges the authorization fact is roughly the same attack as the task-aligned framing this page measures driving glm-4.7 from 0.283 to 1.000, and the same one ADI runs by forging trusted data — and it is precisely the class a metadata gate annihilates, because a fake approval in a ticket note is not in the channel the gate reads.

The standards-track counterpart (OpenID AuthZEN / COAZ)#

ScopeGate is a measured research system; the OpenID Foundation's AuthZEN Working Group is standardizing the same "authorize each tool call" boundary. Its Authorization API 1.0 already defines the interoperable Subject-Action-Resource-Context (SARC) allow/deny decision interface ScopeGate implements ad hoc, and the newly-approved COAZ Working Group Draft (AuthZEN Profile for MCP Tool Authorization, 2026-06-15) profiles MCP tool invocations into SARC, so an API/AI gateway, service mesh, or downstream PDP can authorize a model-emitted tool call at the invocation point. Read against ScopeGate: the same deterministic per-call decision, but a proposed interoperability standard (practitioner-opinion, a Working Group Draft) rather than an empirical, benchmark-tested control — so it is weighted below this paper's measured 0/48 / 0/29 results where they overlap, and carries no equivalent adaptive-attack evaluation. The companion AARP draft adds a shape ScopeGate has no analogue for: instead of a bare DENY, it standardizes a "not yet — here is the prerequisite" approval/attestation/delegation step (generalizing CIBA) before policy is re-evaluated — turning ScopeGate's terminal deny into a resumable governance handshake. The fuller treatment lives on AIMS.

Connections#

• Agent Identity Management System (AIMS) — the standards-body home of the OpenID AuthZEN drafts: AuthZEN's Authorization API + COAZ are the proposed-standard version of ScopeGate's per-call (tool, args) value authorization (a SARC allow/deny at the MCP tool-invocation point), and AARP adds the prerequisite/approval ("not yet") shape ScopeGate lacks — proposed Working Group Drafts, weighted below this paper's empirical measurements (detailed above)

• Off-Host, Identity-Bound Authorization — the off-host sibling: aiAuthZ (Kodathala, arXiv 2607.05518) is the other point on the "where does the authorization boundary live?" axis. Both are deterministic, fail-closed, per-call authorization gates with argument-level allowlists, out-of-band policy, and microsecond latency, sharing the same composition + corrupt-legitimately-variable-data residuals — indeed aiAuthZ's argument-only ablation baseline is essentially ScopeGate's shape. Two precise differences: (1) ScopeGate is an in-framework PDP/PEP (placement-independent by its author's argument), while aiAuthZ insists on a separate trust domain after measuring that a runtime with overlapping built-in tools bypasses even an external gateway; (2) ScopeGate has no caller-authentication step, while aiAuthZ adds per-message HMAC identity of the human sender — worth a measured 9/9 vs 4/9 edge over the argument-only baseline, because it blocks identity-spoofing (a non-owner claiming owner authority) a pure value gate cannot distinguish from legitimate owner use

• Out-of-Band Prompt-Injection Defense — where APPA (Archestra AI, empirical) is written up in full. Two things it contributes here: its per-tool declared contracts (delta / emits / requires) are a distributed alternative to ScopeGate's central operator-authored verified sets — with a measured coverage failure of its own — and its requires preconditions include a shape ScopeGate has no analogue for, history predicates (prior(k) / no_prior(k)) evaluated against an append-only committed-effect log, so a policy can say "only after an egress has already happened" or "only once." That is per-call authorization over run history rather than over argument values, and it is the axis on which APPA reports Fides cannot express three of its scenarios at all. Note also its structural anti-self-approval rule (no primary-user ruling may authorize a predicate for the direct user-response sink), which is the in-band-approval failure mode a value gate does not address. ScopeGate is a member of that out-of-band reference-monitor / PDP-PEP family (CaMeL/FIDES/Progent/RTBAS/FORGE), specialized to per-call value authorization of framework defaults; both share the "policy must be out-of-band, the gate must not be a model" doctrine, and both hit the same in-the-loop / corrupt-the-legitimate-data limit. NetInjectBench supplies that page's cost counter-evidence: its deterministic gate adds zero LLM calls and raises useful-action rate from 16.67% to 99.17% on attacks (98.33% on benign), while the model-mediated Two-Pass LLM Judge doubles inference and stops at 10.00% UTAR — so the ~15× overhead there is a property of Progent's LLM-authored policy, not of deterministic enforcement

• Non-Malleable Memory Authority (TMA-NM) — the memory-authority twin of ScopeGate's per-call value authorization: both are deterministic, out-of-band, no-model-in-the-loop gates at the tool boundary (ScopeGate re-authorizes argument values; TMA-NM binds a memory item's authority-to-act to origin), both are ~µs-cheap with no extra model call, both share the corrupt-legitimately-variable-data residual that needs value-level provenance, and both instantiate "authority/policy must be out-of-band, the gate must not be a model" — TMA-NM adds the cross-session memory dimension and a machine-checked non-malleability guarantee

• Agentic Prompt Injection — the threat this assumes and studies the next layer of: injection produces a model-emitted tool call, and this paper asks whether the runtime executes it (it does, by default)

• Least Agency — per-call value authorization is least agency at argument-value granularity: capability gating scopes which tools, ScopeGate's authz stage scopes which argument values, deterministically enforced at the tool-call boundary — the mechanism that makes "restrict what each tool can do" a hard barrier down to the value. NetInjectBench prices the difference between the two granularities: the tool-level version (globally block apply_config_change) reaches 5.00% attack UTAR but 0.00% usefulness / 100.00% overblocking on legitimate approved changes and leaves the sensitive read at 100.00% UTAR, while the value-level version reaches 0.00% at 99.17% usefulness. Least agency applied at tool granularity is the version that has to choose between safe and usable

• Blast Radius (Agentic) — ScopeGate "makes the compromised model's reachable actions bounded by policy, before side effects": bounding blast radius at the tool-call boundary, the containment (not prevention) posture "assume breach" expects

• Agent Data Injection (ADI) — ADI produces a proposed tool call ScopeGate would gate, and shares the residual: ADI forges data the agent legitimately acts on (spoofed author, fabricated tool result), which satisfies a value policy while doing harm — the same class that survives Progent (22.2%) and ScopeGate's authz stage; the value gate only helps where an allowlist constrains the corrupted argument

• Task-Specification Effects in Prompt Injection (AutoDojo) — AutoDojo's positive result ("real robustness comes from binding the agent's actions to the user's request, not filtering inputs") is the request-derived-trajectory version of this paper's operator-policy value gate; and its task-aligned-injection mechanism is exactly what drives the naive→task-aligned ASR jump (glm-4.7 0.283→1.000) measured here. It is also the standing caveat on the NetInjectBench replication above: that gate's 0/240 comes from a wholly static attacker (fixed corpus, temperature 0, no optimizer), the methodology AutoDojo shows is a lower bound, so the two zeroes corroborate each other's static suites and neither answers the adaptive question

• MCP Tool Poisoning — the delivery layer this gate assumes: ShareLock defeats detection (all LLM classifiers + entropy) and reconstructs a malicious instruction at runtime, but the reconstructed call (read api_key, exfil to an attacker address) is a model-emitted tool call that lies within granted capability — exactly the confused-deputy-within-scope class ScopeGate's per-call value authz stage denies where an allowlist constrains the argument. Detection-evasion is why the durable defense sits at the authorization layer, not the scanner. Its Agentjacking case study is the in-the-wild version of the same confused deputy: the hijacked agent emits an npx @attacker-package execution + credential-exfil egress — model-supplied argument values a per-call authz allowlist (permitted packages, permitted egress hosts) could deny, while the "fix this Sentry bug" framing is the legitimately-variable residual a value gate can't reach (vendor-reported, weighted below this paper's empirical measurement)

• Agent Identity and Authentication — complementary layers: identity/auth answers who the agent is; per-call authorization answers whether this call is allowed in that principal/session context — the "principal and session context" ScopeGate's authz stage checks against presupposes the attributable identity this control domain establishes

• Zero Trust for AI Agents — the concrete instantiation of the framework's Phase 5 "secure tool access" (parameter validation, approval escalation): the audited frameworks leave complete mediation to the integrator, and ScopeGate is one deterministic implementation of that boundary (hub)

• Impossible, Not Tedious (Design Test) — a deterministic fail-closed gate removes the capability to authorize an off-policy action (default-deny, errors-deny) rather than throttling it; "a policy engine that fails open on malformed input recreates the vulnerability with extra steps" is the test stated as an implementation rule

• Capability-Gated Model Fallback — different sense of "capability" — do not conflate. There, capability = a model's dangerous knowledge level, and the "gate" routes risky queries to a weaker model (fallback-not-refusal). Here, capability = which tools are exposed, and the point is that gating capabilities is not authorizing calls. Same word, orthogonal mechanisms (query-level model routing vs tool-call-level value authorization)

• Memory and Context Poisoning — a discordant second reading of the deployment-tier exposure gap: Bad Memory (UW, arXiv 2607.14611, empirical) reproduces the cheap-model-is-worse ordering inside one family (Haiku 4.5 63.3% vs Opus 4.7 30.0% mean single-probe ASR) and inverts it inside the other (GPT-5.2 23.3% vs GPT-5.5 60.0%, with GPT-5.5 at 100% on the subtlest goal). Different attack surface — a payload already in a memory file rather than a model-emitted unauthorized argument — but the same policy question, and it argues the tier gap is vendor- and goal-specific rather than a property of price

• OWASP — the confused-deputy failure is indirect prompt injection under OWASP LLM01 (and MITRE ATLAS AML.T0051); the paper studies the mediation layer OWASP's threat implies

• LangChain/LangGraph, LlamaIndex, and the Stripe Agent Toolkit are the audited frameworks (referenced as plain text — no entity pages)

• Authority and Audit Survive Abundance — this page's circularity doctrine ("out-of-band policy is load-bearing," gates model-independent by construction) supplied the floor under both halves of the synthesis: authority scaffolding cannot migrate into a model however capable it gets, and per-chunk retrieval permission filtering is the same authz control one layer earlier

• Write-Then-Trusted — this paper's thesis as a patched, bountied field instance: OpenAI Codex CLI's safe-command allowlist trusted the command name (git) without modeling arguments or Git's side effects — a name-level capability gate standing in for per-invocation authorization — and Pillar Security turned it into RCE ("GitPwned", patched v0.95.0, high-severity bounty, CVE pending). Pillar's own prescription, "model command policy at the invocation and side-effect level," is complete mediation restated for the shell. It also supplies the boundary of this page's control: an authorization gate that mediates every tool call still does not mediate what a separate unsandboxed process later does with a file the authorized call wrote

Open Questions#

• The 0/48 static and 0/29 adaptive results are suite- and budget-bounded (40 iterations, a GLM-5.2 attacker, one author's vector corpus). Does the deterministic gate hold under longer adaptive budgets, stateful side channels (DNS rebinding, timing), or multi-agent policy-poisoning — the future work the paper names? Partially answered on the suite half only: NetInjectBench (arXiv 2607.10490, empirical) runs an independently-constructed 80-scenario attack corpus in a different domain (network operations), by a different group, on three different models, and its metadata-aware gate also reaches 0 unsafe actions (0/240 model-scenario instances, 95% Wilson upper bound 1.58%) — plus 100/100 correct decisions on a 90-instance degraded-metadata stress suite. So the zero is not an artifact of one author's vector corpus. The budget half is untouched: that attacker is entirely static (fixed scenarios, temperature 0, no optimizer, no defense-aware adaptation), so it corroborates the 0/48 static suite and says nothing about the 0/29 adaptive run.
• The authz allowlist stops value-redirection but not corruption of legitimately-variable data. Is there a per-call scheme that constrains free-text / open-ended arguments without collapsing utility — or is that irreducibly the province of provenance/data-flow tracking (CaMeL Strict, at ~50pp utility cost)? Partially answered on the parenthetical only: APPA (arXiv 2607.24625, empirical) shows the ~50pp is not intrinsic to flow tracking — branching a restrictive read into an isolated child trajectory instead of tainting the parent recovers most of it (0–26pp of episodes, and zero on the strongest model measured). So "irreducibly the province of provenance tracking" no longer implies "irreducibly expensive." The residual itself is untouched and reproduced a third time: APPA's own hide-secret-in-status breach is a secret smuggled inside an authorized send to an authorized reader, and the authors state that content confinement inside a permitted flow "a label algebra over recipient sets does not claim to provide" — the same class that survives Progent at 22.2% and this page's authz stage. Three independent architectures now stop at the same wall.
• The deployment-tier ~3.2× exposure gap (0.603 vs 0.189) means the cheap models chosen for high-volume agent traffic are the most likely to emit the unauthorized call — exactly where a per-call gate is most load-bearing. Does model improvement shrink the attempt rate enough that the gate becomes optional, or is the gate the durable control while models stay jagged? Partially answered: on a different surface — payloads planted in agent memory files rather than model-emitted arguments — Bad Memory (arXiv 2607.14611, empirical) finds capability does not order the exposure: mean ASR falls with strength inside the Claude family (Haiku 4.5 63.3% → Opus 4.7 30.0%) and rises with it inside the Codex family (GPT-5.2 23.3% → GPT-5.5 60.0%), with the strongest Codex model at 100% ASR on the subtlest goal. Worse for the "gate becomes optional" reading: the most resistant model measured (Opus, 18.3% mean ASR under chaining) is also the most likely to leave the payload in place for a weaker successor (93.3% persistence), so improvement at the top can raise rather than lower system-level exposure. Not a direct answer — this measures neither the paper's frameworks nor unauthorized-argument emission — but it is evidence against tier-based reasoning generally.
• Out-of-band policy is load-bearing but under-specified for authoring at scale. The paper forbids any model-sourced policy element; who authors and maintains the verified sets, ceilings, and allowlists for a large tool surface, and does that authoring burden cap the control to high-stakes (money-moving) tools? Partially answered, twice, with opposite answers. APPA (Archestra AI, arXiv 2607.24625, empirical) supplies a third policy shape: not a central verified set, but a per-tool declared contract — each tool states its own label delta, its emits effect tokens, and its requires preconditions, and the engine composes them through a lattice fold whose associativity and commutativity are proven rather than tested. Distributing authorship to the tool definition is the answer that plausibly scales, since a tool surface grows one tool at a time. But APPA also supplies the first measured failure of exactly this burden, and it is the sharper data point: in the authors' own evaluation a create_finance tool declared with no sink requirement opened a store-mediated laundering path — write an HR value into finance, read it back under the finance contract — and the paper concedes "prospective enforcement is only as complete as the contracts it evaluates." So the burden does not disappear when you distribute it; it becomes a coverage problem (is every write-side tool declared?) instead of a maintenance problem, and it failed on a fourteen-scenario benchmark with seventeen tools. NetInjectBench's answer runs the other way: in an operations setting nobody authors it — the change-management system already holds it. Its six trusted fields (approval status, maintenance window, approved tool, approved device, approved patch, change-request ID) are the schema of an existing ITSM/CMDB record, so the gate consumes an out-of-band channel the enterprise maintains for its own reasons. That reframes the burden as integration rather than authoring, and suggests the answer is domain-shaped: where a change-control system of record already exists, policy is free; where it does not, the authoring problem stands. Weak as evidence — the benchmark governs two tools, so it never encounters the scale the question is about, and the record is a benchmark field rather than a live system. Escalated, not answered, 2026-08-04: Rashidi's SoK (The Balkanization of Execution-Security Research for AI Coding Agents: Isolation, Access Control, and Time-of-Check-to-Time-of-Use Vulnerabilities, empirical) makes this its Gap 4 and finds the field-wide absence — Datalog reference monitors, capability tokens, deterministic pre-action gates, information-flow graphs, "every one of them assumes the policy itself is correctly specified by a trustworthy author and asks only whether that policy is then enforced. None studies what happens when the policy is wrong, overly permissive by mistake, internally contradictory, or where a policy author under time pressure grants broader scope than intended because narrower scoping is more work." So the question is not under-answered in this vault by accident; no paper in a 39-paper execution-security corpus measures it. The survey rates it the most consequential of its first four gaps and supplies the argument for why: ShellSieve's 69–98% fragility is measured against denylists real developers wrote and shipped, so policy-authoring error is plausibly at least as large a source of real-world risk as enforcement failure — and it is the one stage of the pipeline nobody measures. The experiment it asks for is well-specified: a ShellSieve-style empirical study aimed at the access-control policies this literature proposes rather than at command denylists, to tell the field whether its mechanisms are undermined more by weak enforcement or by policies never correctly specified. Note this also outranks the two partial answers above: APPA's undeclared-create_finance-contract breach is an instance of policy-authoring error caught in the wild, which the survey's framing predicts should be common and unmeasured.

Sources#

• The Balkanization of Execution-Security Research for AI Coding Agents: Isolation, Access Control, and Time-of-Check-to-Time-of-Use Vulnerabilities — Mohammadreza Rashidi (AI and Media Analysis Lab, Berlin), The Balkanization of Execution-Security Research for AI Coding Agents: Isolation, Access Control, and Time-of-Check-to-Time-of-Use Vulnerabilities, arXiv 2607.05743, 2026-07-07, empirical. Read the tier precisely: the paper's own checkable work is the verified 39-paper corpus (every entry confirmed against its own abstract page, two misattributions caught and corrected), the four CVEs confirmed against NIST NVD, and counts machine-re-derived from a released corpus file by a released verifier. Every number it reports about how a system behaves — 69–98%, 17.1%, 23.8%, 7.2%/5.5%/66% — is restated from the underlying paper and explicitly not independently replicated (§9). Cited here for §4.3 (the six access-control/capability papers), §4.4 (ShellSieve and YoloFS), §4.13 (OverEagerBench), §5.1 (RC3 and RC4), §6.2 (Gap 2), §6.4 (Gap 4 — the honest-policy-author assumption), §6.5 (Gap 5 — scope creep unaddressed by any enforcement mechanism), §10 (the two replay experiments it proposes). Tables 1–4 verified against the PDF and matching
• Agentic Permissions Policy Algebra for Taint Confinement in LLM Agents — Kravchenko, Liventsev, Konstantinov, Iskhakov & Kukuy (Archestra AI, vendor-COI flagged), arXiv 2607.24625, 2026-07-27, empirical. Cited here for the policy-authoring and residual questions: §3 (tool contracts — delta / emits / requires, the five precondition kinds including history predicates and hard gates), §5 (atomic rulings, mandate typology, the response-sink rule), §7 (the joint-merger-brief undeclared-write-side-contract breach and the hide-secret-in-status permitted-flow breach). Full treatment on Out-of-Band Prompt-Injection Defense
• OpenID Foundation advances authorization for the agent era with new AuthZEN Working Group Drafts — OpenID Foundation, …advances authorization for the agent era with new AuthZEN Working Group Drafts, 15 June 2026, practitioner-opinion (proposed Working Group Drafts, not ratified specs; weighted below this paper's empirical measurements). The standards-track counterpart to ScopeGate: AuthZEN Authorization API 1.0 (SARC allow/deny interface), COAZ (MCP-invocation → SARC profile), AARP (prerequisite/approval pattern generalizing CIBA)
• NetInjectBench: Benchmarking Indirect Prompt Injection in Tool-Using Large Language Model Agents for Network Operations — Shayoni, Shoaib, Hossain & Mridha (Wichita State University / American International University-Bangladesh), NetInjectBench: Benchmarking Indirect Prompt Injection in Tool-Using Large Language Model Agents for Network Operations, arXiv 2607.10490, July 2026, empirical. §3.1 (threat model and its four boundaries; the metadata-integrity assumption), §3.2 (130 scenarios, the prompt/tool/trusted-policy/evaluation field separation, Tables 1–3), §3.3 (six mock tools and seven execution settings, Tables 4–6; the deterministic gate and its fallback order), §3.4 (UTAR/UAR/BR/OBR/IOR/NR, Wilson intervals, McNemar), §4.1 (Table 7 defense ladder), §4.2 (Table 8 weak-vs-strong, Table 9 per-model spread), §4.3 (Table 10 approved changes, Table 11 the 100-instance metadata-stress suite, Table 12 benign), §4.4 (Table 13 Wilson CIs, Table 14 reliability, Table 15 McNemar), §4.5 (Table 16 risk-type breakdown — the sensitive-read row; Table 17 the 186/12 split of naive unsafe actions), §5.5 (scope of the safety claim), §5.6 (threats to validity: synthetic, single-step, compact tool set, three 7–8B models at temperature 0). Figures 2 and 3 viewed per the image two-pass rule: Fig. 3 restates Table 7 exactly, and Fig. 2 confirms the gate's stage list (tool privilege level → approval status → maintenance window → approved tool/device/patch → CR ID → argument validation) and its three outcomes (allow safe action / allow approved high-impact action / block and execute safe fallback). Figs. 1 and 4 are the threat-model diagram and a restatement of Table 10.
• Capability Gates Are Not Authorization: Confused-Deputy Failures in LLM Agent Frameworks — David Mellafe Zuvic, Capability Gates Are Not Authorization: Confused-Deputy Failures in LLM Agent Frameworks, arXiv 2606.28679, June 2026, empirical. §II (threat model: trust boundary, compromise-source independence, out-of-band policy load-bearing), §III (cross-framework audit, Table I — LangChain/LangGraph, LlamaIndex, Stripe Agent Toolkit at pinned commits), §IV (measurement: deployment-tier vs flagship ASR, task-aligned framing, Table II / Figure 1 — verified deployment mean 0.603 vs flagship 0.189), §V (ScopeGate 5-stage PDP/PEP, Figure 3 + Algorithm 1, placement-independence), §VI (evaluation: LangChain/LlamaIndex PoC, 0/48 static, 0/29 adaptive, benign 0-false-deny, Latam-GPT + WhatsApp payment containment, Table III), §VII (positioning vs MiniScope/AP2), §VIII (limitations: containment≠cure, suite-bounded, public-source only). Figures 1–3 viewed per the image two-pass rule; docling's spaced decimals ("0. 603") are cosmetic and match the figures.