Runtime Authorization for Resources Acquired by AI Agents
Payment or fulfillment does not make a resource safe to use as authority. Runtime authorization closes the gap between acquisition and activation.
Overview
Autonomous agents can acquire compute, credentials, accounts, services, or other agents. Existing payment, budget, OAuth, mandate, and fulfillment checks may validate the transaction without deciding whether the returned resource should become usable authority inside the task.
The architecture quarantines every acquired output, resolves its actual capabilities from authenticated provider evidence, and activates it only through a current transaction that checks provenance, epochs, the resolved manifest, and correlated limits over identity, effects, data, delegation, and the wider resource graph.
Core contributions
- 01
Activation-gap formulation
Separates successful acquisition or fulfillment from the security decision that allows a returned resource to introduce new authority into an agent task.
- 02
Quarantine and resolution
Keeps acquired outputs inert until a versioned resolver derives their actual capabilities from authenticated provider evidence.
- 03
Relational authorization envelope
Binds activation to provenance, epochs, and downward-closed graph constraints that preserve correlated identity, effect, data, delegation, and graph-wide limits.
- 04
Effect-time enforcement
Revalidates and consumes single-use effect permits at linearization, with reference traces, an independent checker, tamper tests, MCP clients, staged Docker composition, and a multi-source field audit.
How runtime authorization extends the governance stack
OpenPort, IGAC, and EBTE govern tool access, user intent, and action claims, while ClosureBound binds grants to the dependency-closed identity of an executing skill. Resource acquisition introduces a different transition: a task can receive a new principal or capability source after fulfillment.
Runtime authorization keeps that resource quarantined until a current, provenance-bound activation proves that its resolved capability graph fits the permitted envelope. The resource cannot inherit authority merely because the transaction succeeded.
- 01Acquired resource
- 02Quarantine
- 03Resolved manifest
- 04Bound activation
- 05Controlled effect
Evidence and scope
This is an arXiv preprint and a reference architecture, not a claim of production readiness. Its guarantees depend on authenticated provider evidence, complete mediation, correct resolution and normalization, authoritative epochs and linearization, and enforcement of the relational envelope. The reported MCP and Docker studies are deterministic or staged evaluations, and the field audit does not show that any surveyed unit supplies a complete production activation profile.
Abstract
By acquiring compute, credentials, accounts, services, and other agents, autonomous AI agents can introduce new authority into a task. Payment, budget, OAuth, mandate, and fulfillment checks can validate transaction conditions without deciding whether a returned resource may become usable authority. This post-fulfillment activation gap spans tool-mediated creation, inter-agent delegation, and agentic commerce. We present a provenance-bounded runtime authorization architecture. It quarantines acquired outputs, resolves their actual capabilities from authenticated provider evidence through a versioned resolver, and activates them only through a current activation transaction that checks the resolved manifest, provenance, epochs, and a downward-closed relational envelope over a typed resource-capability hypergraph. The envelope preserves correlated identity, effect, data, delegation, and graph-wide limits. Single-use effect permits are revalidated and consumed at effect linearization. Under explicit assumptions, we prove eight safety properties covering quarantine, backing, non-amplification, split non-evasion, crash/retry, refunds, epochs, and effect confinement. Across five resource classes, reference semantics accepted 20/20 benign traces and rejected 40/40 registered unsafe traces over 810 events; an independent checker agreed on 60 base and 40 refinement traces and rejected 89/89 tamper tests. Frozen Codex and Gemini Model Context Protocol (MCP) client components completed 54/54 deterministic local stdio calls. In a registered 18-case staged MCP-to-Docker composition, both benign paths completed, and none of the 16 unsafe paths added an unauthorized Docker start request. A five-source audit classified 1,248 field pairs across 32 units; no unit alone supplied a complete activation profile.
Cite this work
Use the DOI record for stable bibliographic information and citation formats.