AgentCap: Capability-Based Runtime Authorization for Secure LLM Agent Execution

What it is

AgentCap is a runtime authorization layer for LLM agents, from Aravinda Kashyap Kabbinamakki Suresh and Peng Gao at Virginia Tech. It is a workshop paper (NeurIPS 2026, Agents in the Wild), posted to arXiv on 31 October 2026 as v1. It wraps MCP tool access so that the model proposes calls but a separate policy engine and gateway decide whether they run.

How it works

Each proposed call declares an intent. The policy engine issues a signed capability token only if all seven conditions hold:

flowchart LR
    A[Not sandboxed] --> G{All seven pass?}
    B[Capability in catalog] --> G
    C[Bound args have trusted provenance] --> G
    D[Intent in whitelist] --> G
    E[Trust at or above threshold] --> G
    F[Prerequisite tokens held, same session] --> G
    H[No forbidden combination in session] --> G
    G -->|yes| T[Issue token, gateway verifies]
    G -->|no| X[Deny, log, decay trust]

• Token: an Ed25519-signed JWT binding token id, agent, action, resource, intent, session, trust at issuance, issue and expiry times, call budget, prerequisites, deny-combination groups and an audit reference. The gateway also checks expiry, revocation, remaining budget, presenting agent and action/resource match.
• Argument provenance: a bound_params declaration (for example a payment recipient) marks arguments that must be supported by trusted context, meaning the task instruction or designated application fields. An argument whose only support is untrusted tool output is rejected. A value that also appears in trusted context is allowed.
• Delegation: a child token must keep the parent's action and resource, with budget ≤, expiry ≤ and remaining depth strictly lower. Verification walks the chain leaf to root, checking each hop's signature and revocation. Agents outside the lineage cannot use the token even if they exchange messages.
• Trust: each agent has a score t. Normal outcomes apply t′ = t + r(1−t), anomalies apply t′ = t(1−d). Denials count as anomalies. Defaults are t0 = 0.8, d = 0.3, r = 0.01, giving 0.560, 0.392 and 0.274 after three anomalies. Write authority is lost after the second and the agent is sandboxed after the third. The paper ran a one-factor sweep over 23 configurations; the fetched text cuts off before the results.
• Policy language: five block types (grant, deny_combination, delegation, on_trust, workflow). The first four drive runtime enforcement. workflow blocks are used only by a static surface analyzer, which flags over- and under-permissive interactions and capabilities made unreachable by inconsistent constraints.

The paper's example grant for send_money sets trust: >= 0.8, ttl: 30s, budget: 1, requires: [get_balance] and bound_params: [recipient].

Results stated

On AgentDojo and InjecAgent, attack success falls in every evaluated model and benchmark pairing, and is 0% with GPT-5.4 on both. Controlled single- and multi-agent scenarios show 0% attack success with all legitimate operations exercised still working. The fetched text has no per-model tables, baselines or utility numbers.

Caveats

• Policy, provenance labels and outcome labels are trusted configuration supplied by the deployer. The paper says the analyzer and audit log cannot compensate for a wrongly trusted source or an over-permissive policy.
• Intent is supplied by the model. It only ties a call to purposes the policy already allows for that capability.
• The guarantee assumes the policy engine, MCP wrapper, gateway, keys and transport are trusted, and that the adversary cannot bypass the mediated tool interface.
• The 0% adversarial result covers scenarios the authors built, not an open-ended attack search.