Capability Gates Are Not Authorization: Confused-Deputy Failures in LLM Agent Frameworks

Abstract: Tool-using LLM agents increasingly read untrusted content while holding side-effecting tools such as payments, email, CRM, and infrastructure APIs, yet common framework defaults still conflate tool exposure with authorization. We audit whether LangChain/LangGraph, LlamaIndex, and the Stripe Agent Toolkit re-authorize each model-emitted call, with concrete argument values, before execution. Across pinned public-source commits, all three provide capability gating by default, but none provides a deterministic fail-closed per-call value authorization gate by default. We introduce ScopeGate, a five-stage PDP/PEP for agent tool calls: scope, authorization, money ceiling, idempotency, and default deny. Evaluation shows the identical unauthorized payout call executes under LangChain's default dispatch (with a companion LlamaIndex PoC) but is denied by ScopeGate; the tested control reports 0/48 static bypasses, 0/29 unauthorized attempts (40-iteration adaptive run), 0/10 benign false-denies, and Latam-GPT payment-agent containment at 10/10. ASR denotes attempted unauthorized action, containment is not a cure, deployment-tier claims are inference over measured model classes, and no CVE is asserted.

• The paper demonstrates that conflating capability gating with per-call authorization leads to confused-deputy vulnerabilities in LLM agent frameworks.
• It employs empirical measurements across 27 models, revealing higher unauthorized action rates in cost-optimized deployments due to prompt injection risks.
• The proposed ScopeGate system enforces deterministic, out-of-band policy authorization to block unauthorized tool calls while permitting legitimate actions.

Capability Gating vs. Per-Call Authorization in LLM Agent Frameworks

Problem Statement and Motivation

Agentic LLM frameworks—such as LangChain/LangGraph, LlamaIndex, and the Stripe Agent Toolkit—are increasingly deployed to read untrusted user- or document-supplied content and invoke side-effecting tools (e.g., for payments, CRM, or infrastructure APIs). The security posture of such frameworks is critically determined by how they mediate model-emitted tool calls, particularly when the LLM acts as an untrusted parser and planner. This paper demonstrates that the majority of deployed frameworks conflate capability gating (i.e., restricting tool exposure) and authorization (i.e., policy-based validation of each concrete tool call with its arguments in context), leading to confused-deputy vulnerabilities analogous to classic systems security failures (2606.28679).

Threat Model and Systemic Analysis

The core threat considered is not whether prompt injection is possible (which is well-established [greshake23]), but whether, given compromise of an untrusted model engaged with attacker-controlled content, the framework deterministically mediates tool calls with authorization rooted out-of-band (i.e., not model influenced). If not, a compromised or malicious model can escalate privilege by emitting well-typed but unauthorized tool calls (e.g., initiate a payment to an attacker's account).

The adversary is assumed to control only content (e.g., emails, web pages, workflow outputs), not agent code or runtime policy. The attack surface thus encompasses indirect prompt injections (OWASP LLM01, MITRE ATLAS AML.T0051). The security objective is that the only calls to privileged side-effect tools should be subject to complete mediation by operator-authored policy, unaffected by model outputs at any life cycle stage.

Cross-Framework Default Gaps

A public-source audit of LangChain/LangGraph, LlamaIndex, and the Stripe Agent Toolkit revealed that while all provide static tool access control (capability gating), none implements a fail-closed, deterministic per-call value authorization gate by default in the main dispatch paths. The frameworks validate tool presence and input schema but do not check if tool arguments (such as beneficiary account or refund destination) are specifically allowed under operator policy. Instead, the frameworks rely on the absence of type errors, not explicit authorization, making them vulnerable to the confused deputy problem.

For example, unless the application integrator implements custom middleware, a model output like update_payout_account(account=acct_ATTACKER_999) may be directly executed, provided it is well-typed and the tool exists, with no argument-level authorization. This pattern was confirmed across all three frameworks examined.

Empirical Measurement of Risk

To quantify the magnitude of this framework gap, a deterministic adversarial suite and task-aligned prompt injection benchmarks were run on 27 models spanning deployment- and flagship-tiers. The key takeaways are:

• Deployment-tier (cost-optimized, high-traffic) models had a mean unauthorized action attempt rate (ASR) of 0.603, compared to 0.189 for flagship models. The incidence of high ASR exists in both tiers, but lower-cost models are considerably more susceptible.
• In paired $\Delta$ runs, task-aligned framing (presenting malicious actions as necessary for task completion) was shown to strongly increase unauthorized tool call rates for most models.
• In all cases, the ability for a model to emit well-typed, unauthorized, side-effecting tool calls was consistently observed, further emphasizing the deficiency of mere capability gating.

ScopeGate: Deterministic Per-Call Authorization

ScopeGate is proposed as a reference five-stage Policy Decision Point/Policy Enforcement Point (PDP/PEP) to enforce deterministic authorization at the tool-call boundary. ScopeGate systematically applies:

1. Scope check: Tool must be present in operator-defined policy.
2. Authorization check: Argument values must be present in value allowlists (e.g., only merchant-verified accounts).
3. Money ceiling: For payment/refund actions, values must be finite and within specified range.
4. Idempotency enforcement: If tool semantics require an idempotency key, its absence results in denial.
5. Default deny: All failures or runtime errors result in denial, providing strong fail-closed semantics.

Crucially, policy is managed out-of-band and cannot be modified by any model output, at authoring, session initiation, or at runtime, thereby preventing both direct and indirect (e.g., session-seeded) policy manipulation.

Evaluation and Numerical Results

• Real-framework proof-of-concept with LangChain (and LlamaIndex) establishes that, under default dispatch, a model can successfully execute unauthorized payout calls. With ScopeGate in place, the same calls are deterministically denied at the authorization stage.
• A 48-vector static bypass suite (including case/whitespace mutations, type confusions, edge-case money amounts, idempotency mutations) demonstrated zero bypasses under ScopeGate.
• An adaptive black-box attacker (GLM-5.2) failed over 40 iterations to generate a bypass; all unauthorized attempts were denied.
• Benign control trials showed no false denies.
• In a sovereign-model Latam-GPT (Llama-3.1-70B-LatamGPT-SFT-1.0) payment-agent containment scenario, all 10 unauthorized payout attempts were denied, with all benign authorized actions allowed.

These results provide strong evidence that deterministic, out-of-band policy enforcement at each tool-call is necessary for agentic frameworks exposed to untrusted LLM outputs.

Implications and Future Directions

The research underscores that capability gating is not equivalent to authorization. Complete mediation must occur for every side-effecting action, with all policies sourced outside any model context. Integrators should not rely on schema or tool-level access alone, as these can be subverted by prompt-injected, compromised, or backdoored models.

The practical implication is clear: fail-closed value-gating should be mandatory, not optional. Framework defaults need to shift toward explicit per-call authorization. The theoretical implication extends to broader agent system design: delegation of action selection to LLMs without policy mediation violates well-understood systems security principles, with consequences for both traditional confused-deputy failures and modern AI-specific threats.

Future work should address distributed, multi-agent flows, third-party red-teaming beyond single-turn scenarios, and defense-in-depth strategies that combine on-policy mediation with LLM-side behavioral constraints and provenance assurance.

Conclusion

Agentic LLM frameworks across public-source implementations show a reproducible, cross-framework default gap: capability gating is provided, but per-call value authorization is absent. The result is a material escalation path for adversaries via indirect prompt injection and compromised model behavior. ScopeGate provides a deterministic, policy-rooted fix at the tool-call boundary, ensuring that every side-effecting action is mediated by operator policy, not untrusted model output. The approach delivers zero-bypass and zero-false-deny results on tested corpora and scenarios, but containment is not cure; the broader security ecosystem must embrace explicit, out-of-band authorization as a default.