AgentCap: Capability-Based Runtime Authorization for Secure LLM Agent Execution
AgentCap is a runtime authorization layer for LLM agents from Virginia Tech (Suresh and Gao), posted to arXiv on 31 October 2026. The model proposes MCP tool calls, and a policy engine issues Ed25519-signed capability tokens only after checks on provenance, intent, trust and prerequisites. It reports 0% attack success with GPT-5.4 on AgentDojo and InjecAgent, but only on scenarios the authors built.
What it claims
AgentCap separates choosing a tool call from authorizing it. The model proposes each MCP call with a declared intent. A policy engine outside the model decides whether to issue a short-lived, budget-limited capability token, and a separate gateway verifies that token before the call reaches the MCP server. The paper is a workshop paper at NeurIPS 2026 (Agents in the Wild). It reports lower attack success in every model and benchmark setting on the full AgentDojo suite and on InjecAgent, with 0% attack success for GPT-5.4 on both. In the authors' own single- and multi-agent scenarios, every unauthorized execution was blocked and every legitimate operation they tested still ran.
How it works
A token is issued only when all seven checks pass:
- The agent is not sandboxed.
- The tool is in the capability catalog.
- Protected arguments have acceptable provenance.
- The declared intent is on that capability's whitelist.
- The agent's trust score meets the threshold.
- Every prerequisite token is already held in the same session.
- No forbidden combination with tokens already held is created.
Intent is supplied by the model, so it is not trusted. It only ties a token to one purpose the policy pre-approved.
Argument provenance. The policy author labels the task instruction and chosen application fields as trusted, and retrieved or tool-produced text as untrusted. A sensitive argument listed in bound_params, such as a payment recipient, is rejected when its value comes only from untrusted content. A recipient taken from an injected document is blocked, while a recipient the user named is allowed.
Tokens. Tokens are JWTs signed with Ed25519. Each binds agent, action, resource, intent, session, trust at issuance, expiry, budget, prerequisites and deny groups. The gateway also checks revocation, remaining budget and the identity of the agent presenting the token.
Delegation. A child token must keep the parent's action and resource. Its budget and expiry may only shrink, and its delegation depth must strictly decrease. A request that widens authority is malformed. Verification checks every hop of the chain, including signatures, attenuation and revocation, with no cached validity. Being able to message another agent does not give an agent that agent's authority.
Trust. A normal outcome moves trust toward 1 (t' = t + r(1 − t)). An anomaly, including any denial, decays it (t' = t(1 − d)). With the defaults t0 = 0.8, d = 0.3 and r = 0.01, three anomalies give trust of 0.560, 0.392 and 0.274. The agent loses write authority after the second and is sandboxed after the third. The authors swept 23 configurations, one factor at a time.
flowchart LR
A[Agent proposes call + intent] --> P{7 policy checks}
P -- any fail --> D[Deny, audit log]
D --> T[Trust decays]
T -- below threshold --> S[Revoke / sandbox]
P -- all pass --> K[Signed token]
K --> G{Gateway verifies}
G -- valid --> M[MCP server]
K -.attenuated delegation.-> W[Worker token] --> GHow to use it
Policies use a declarative language with five block types: grant, deny_combination, delegation, on_trust and workflow. A grant from the paper's banking example:
grant send_money {
action: write
resource: "bank_account/transfers"
intent: [pay_bill, send_payment]
trust: >= 0.8
requires: [get_balance]
ttl: 30s
budget: 1
deny_groups: [financial_write]
bound_params: [recipient]
}workflow blocks are used only by a static surface analyzer. Before deployment, it flags policies that grant too much or too little, and capabilities that inconsistent constraints make unreachable. The fetched text gives no repository, install command or licence.
Limits
The guarantee holds only if the policy is correct. The authors treat policy, provenance labels and outcome labels as security-critical configuration. The analyzer cannot make up for a source wrongly marked trusted or a policy that grants too much. The trusted computing base includes the policy engine, wrapper, gateway, keys and transport. The fetched text ends partway through the trust-parameter sweep, so it gives no per-model attack numbers for models other than GPT-5.4 and no utility or latency figures.
Organisations named here
- Virginia Tech
- NeurIPS
- Aravinda Kashyap Kabbinamakki Suresh
- Peng Gao
Technologies named here
- GPT-5.4
- Model Context Protocol
- AgentDojo
- InjecAgent
- JWT
- LLM
- AgentCap
- Ed25519
Techniques named here
- Ed25519-signed JWT capability tokens
Concepts named here
- Argument provenance
- Capability delegation
- Deny-combination
- Model-supplied intent
- Static surface analysis
- Trust score decay
Related in agents



