cs.AISep 13, 2026
SaveRuntime Authorization for Resources Acquired by AI Agents
Organizations: Accentrust · Georgia Institute of Technology · Accentrust, Vancouver, Canada · Georgia Institute of Technology, Atlanta, Georgia, USA ·
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.
Figures & tables
| Layer | Primary decision object | Representative evidence | Question not settled by that object alone |
|---|---|---|---|
| Endpoint authorization | proposed API operation | caller, audience, scope, request parameters | What semantic authority does the returned resource create? |
| Commerce | represented order and transfer | intent, checkout, amount, payee, signed mandates, receipt | May the fulfilled item become usable task authority? |
| Resource accounting | source-side consumable rights | balance, reservation, ownership, settlement | Does a zero-price or nonnumeric output widen future effects? |
| Capability/tool binding | an existing named capability or tool definition | manifest, version, grant, invocation handle | What new resource instance, identity, or entitlement did this call create? |
| Acquisition activation | actual returned resource and prospective active graph | provider state, resolved manifest, canonical identity, lineage, epochs | Is this output admissible now, and what may it do later? |
Table 1. Complementary decisions in an acquisition workflow.
Figure 1. The architecture separates successful acquisition from executable authority. Provider output remains quarantined until its actual manifest, canonical identity, lineage, and prospective aggregate satisfy the current authority domain’s joint envelope. Later effects re-enter the current-closure gate and commit only by atomically redeeming a current single-use effect permit. A left-to-right acquisition pipeline places provider fulfillment before a quarantine vault and actual-capability resolver. A relational graph gate creates an active opaque handle only after validation. Every protected use passes through a current-closure gate, and the effect commit atomically revalidates the immutable single-use permit and consumes its slot; invalid or stale paths are denied or fenced.
| ID | Assumption | Operational obligation |
|---|---|---|
| A1 | Complete mediation | Every registered acquisition, provider output, activation, handle publication, and protected effect crosses the declared broker. |
| A2 | Authentic state | Grants, contracts, provider evidence, identity mappings, target–domain maps, epochs, and commitments are unforgeable within the profile. |
| A3 | Conservative resolution | The actual-capability projector is total and complete for policy-relevant fields; unknowns map to a sound upper bound or cause rejection. |
| A4 | Canonical identity | Controlled subjects, beneficiaries, resources, and aliases resolve to authoritative canonical roots; ambiguity fails closed. |
| A5 | Correct policy semantics | Capability denotation, conversion relations, graph normalization, and envelope predicates implement their registered mathematical definitions. |
| A6 | Transactional durability | Each authority-changing operation executes as one serializable storage transaction. A transaction either aborts without changing durable state or commits its complete write set at one linearization point; a successful commit is durable before success is returned. The store enforces durable constraints on , , , and ; a conflict aborts. Recovery exposes the state after the last complete commit and no incomplete write. Lifecycle transactions include every required dependent fence. A handle is derived deterministically from, and may be published only for, a committed active record. |
Table 2. Assurance assumptions.
| Field group | Bound values | Security purpose |
|---|---|---|
| Origin | root grant, task/session, canonical controller, runtime profile, request ID | attributes the proposal to one current authorization root |
| Operation | acquisition kind, provider, product/profile version, exact parameters, logical and derived root-bound provider keys | prevents operation, cross-root, and retry substitution |
| Inputs | source references, reservation evidence, contributing capability nodes | identifies every consumed or supporting input |
| Intended output | resource kinds, maximum output descriptors, multiplicity, intended beneficiary | authorizes only a bounded prospective conversion |
| Correlation | purpose, target, registered target–domain map, data domain, audience, delegation, descendants, co-possession group | preserves whole clauses instead of fieldwise unions |
| Freshness | grant, policy, contract, identity, provider-resource, and revocation epochs; expiry | makes state changes invalidate prepared authority |
Table 3. Security-relevant acquisition-effect IR.
| Crash point | Recovery rule |
|---|---|
| Before provider dispatch | retry the same durable outbox/key; no output authority exists |
| After create, before receipt | query the same logical key; any output enters quarantine |
| After resolution, before activation | discard stale preparation and resolve current state again |
| After activation commit, before handle publication | republish the deterministic handle for the same active record |
| After handle publication | durable active record already precedes the handle |
| After effect-permit preparation | re-resolve current lineage and episode; abort stale or changed binding before acceptance |
Table 4. Crash windows and durable recovery outcomes.
| Layer | Native evidence used | Evidence not inferred | Activation-layer use |
|---|---|---|---|
| AP2 | mandate, payment, receipt, transaction binding | actual resource authority, canonical controller, later activation | validate transaction-side prerequisites |
| UCP | commerce discovery, checkout/order and fulfillment records | authorization meaning of a delivered resource | identify declared product and lifecycle evidence |
| A2A | Agent Card, endpoint, declared Skills and authentication metadata | actual derived principal and complete downstream effect set | select and authenticate a remote-agent evidence profile |
| MCP | structured request, server/tool identity, OAuth context | semantics of a newly created provider resource | capture the acquisition request at the runtime boundary |
| Provider inspection | actual resource configuration in the registered observable profile | undocumented or hidden provider behavior | derive the actual-capability manifest |
| Provenance-bounded authorization | envelope, graph, resolver, lineage, epochs, activation and effect permits | payment validity or provider facts not supplied by an adapter | make the activation decision and linearize each protected effect |
Table 5. Evidence responsibility across protocol layers.
| Acquired resource | Interception point | Authoritative resolver | Quarantine primitive | Activation predicate | Effect linearization | Fail-closed behavior |
|---|---|---|---|---|---|---|
| MCP credential | final structured tool-call/result boundary at the acquisition broker | issuer/provider introspection plus canonical identity and registered scope profile | secret retained in the broker vault; no raw credential returned | resolved scope, audience, exportability, delegation, epochs, and aggregate envelope pass | broker or recipient atomically redeems the exact single-use permit with API acceptance | missing issuer, scope, audience, or mediated redemption leaves the output quarantined; a raw-return path is nonconforming |
| Cloud instance | brokered create and correlated provider result | provider inspection of canonical resource, IAM, network, storage, and runtime state | create disabled or non-routable, or withhold access behind a gateway | actual manifest and aggregate graph pass; commit-time requery shows no drift | start, attach, expose, or a protected workload effect atomically accepts the permit | ambiguous identity or state yields indeterminate; absence of quarantine or atomic acceptance makes the profile nonconforming |
| A2A child agent | child registration/task result before endpoint or credential publication | registered identity/delegation service and provider-side child state; Agent Card only selects the profile | withhold endpoint and credentials; child remains non-dispatchable | canonical parent and beneficiary, descendant, delegation, effect, epoch, and aggregate bounds pass | brokered task dispatch atomically redeems the permit at the child gateway | card-only or incomplete downstream fields, ambiguous aliases, or a non-redeemable endpoint prevent dispatch |
| AP2/UCP service | verified transaction/fulfillment result at the broker | provider account/entitlement read plus a registered delivery attestation, when used | fulfilled account, token, or entitlement retained in the broker vault | transaction prerequisites and resolved entitlement, beneficiary, delegability, epochs, and aggregate envelope pass | service invocation or recipient gateway atomically redeems the exact permit | payment or receipt alone, unavailable resolution, or ambiguous fulfillment leaves the output quarantined |
Table 6. Deployment mapping from acquired resources to post-fulfillment authorization enforcement points.
| Evidence layer | Denominator | Observation |
|---|---|---|
| Reference semantics and trace checker | 60 base fixtures; 810 canonical events; 40 refinement traces; 5 effect-replay probes; 89 checker tamper tests; 1 fresh- gid aggregate regression | 20/20 benign accepted and committed an inert effect; 40/40 unsafe rejected at the registered phase and code; checker agreement 60/60 and refinement agreement 40/40; 89/89 tamper tests and 5/5 replays rejected; the joint fresh- gid aggregate rejected by both evaluators |
| Observation-limited separation predicates | 6 registered predicates; 60 constructed fixtures each | each accepted 60/60, including 40/40 envelope-violating witnesses; proposition-level separation test, not a full-system comparison |
| Runtime-boundary mapping | 60 paired logical cases; 120 adapter replays; 48 fail-closed probes | 60/60 pairs produced identical complete IR obligations; 48/48 probes rejected; 2/2 frozen source boundaries passed |
| Frozen upstream MCP client components | 2 source trees; 9 logical cases per runtime; 3 fresh client/server process pairs per case | 54/54 stdio calls completed initialize, discovery, invocation, server observation, and response; all normalized wire/context bindings agreed across repetitions |
| AP2 target profile | 4 primary and 5 dependency schemas; 1 positive; 25 mutants in 13 families; 39 activation fields | 9/9 source files matched frozen paths, bytes, and digests; 1/1 positive was structurally consistent but remained non-active; 25/25 mutants rejected; 39/39 fields classified |
| Crash and replay | 15 activation cuts; 5 effect cuts; 32 schedules; 32 effect replays; 192 receipt substitutions; 7 activation-recovery probes; 5 publication drifts; 8 contract-security probes; 10 effect-security probes; 16 late-success schedules | no duplicate active record, published handle, or accepted effect; every registered cut, schedule, replay, substitution, recovery, security, publication-drift, and late-arrival outcome passed |
Table 7. Registered safety, composition, portability, and external-evidence results, including the staged case-to-boundary matrix.
| Path (samples) | p50 | p95 | p99 |
|---|---|---|---|
| Grant installation (12,000) | 38.250 | 51.208 | 55.125 |
| Proposal normalization (16,000) | 226.584 | 264.458 | 360.209 |
| Source reservation (16,000) | 24.875 | 27.750 | 32.834 |
| Dispatch (16,000) | 227.250 | 264.541 | 357.084 |
| Delivery lifecycle (17,000) | 17.083 | 19.083 | 22.917 |
| Quarantine receive (17,000) | 48.833 | 54.417 | 62.708 |
Table 8. Local in-process latency in microseconds; sample counts reflect which actions occur in the fixed 60-fixture matrix over 200 measured rounds.
| Evidence | Establishes | Does not by itself establish |
|---|---|---|
| Formal proof | all reachable accepted traces preserve the stated invariants under A1–A11 | correctness of a concrete resolver, identity service, provider, or deployment premise |
| Reference semantics | registered fixtures instantiate the formal state, exact permit binding, currentness, and slot obligations under the frozen finite profile | a machine-checked forward simulation for every implementation state, provider behavior, or production-scale performance |
| Independent trace checker | emitted flat-trace records satisfy registered finite event, state, and aggregate invariants without reusing runtime decision code | arbitrary hypergraph derivations or completeness of events that bypass the declared boundary |
| Runtime source/profile audit | frozen adapter captures the stated final logical acquisition request within explicit exclusions | an upstream patch, raw network-wire coverage, or unknown execution paths |
| Frozen upstream MCP client-component execution | both frozen clients complete initialize, discovery, stdio call, server observation, and response for all registered cases | a complete CLI session, model-driven selection, or direct execution of the Codex higher-level capture point |
| Local container integration | real create/inspect/certificate/re-inspect/start ordering and configuration checks on the registered host profile | durable activation-record atomicity, arbitrary cloud IAM, kernel compromise, or containment of an unsafe image |
Table 9. Interpretation of evidence layers.
More in this topic
AI Agent Security
Artificial intelligence agent security studies attacks and safeguards for tool-using, persistent, and collaborative systems across digital and physical settings.
See all 508 papers