Runtime system limits new authorities for autonomous ai agents

AcquireBound: Runtime Authorization for Resources Acquired by AI Agents

Artificial IntelligenceCryptography and Security

Summary

Autonomous AI agents can gain access to various resources like services, credentials, or accounts, which may allow them to act with new powers. The authors found it is tricky to ensure these new resources don’t let agents do things they shouldn’t. They created AcquireBound, a system that carefully quarantines and checks new resources before fully activating them, using detailed records of where each resource came from and what it can do. Their approach catches unsafe actions without blocking safe ones and works well across different types of resources.

What this means in practice

  • For cloud security teams: Prevent unauthorized escalation of privileges when AI agents gain new cloud resources during operations.
  • For devops engineers: Enforce precise activation checks on newly created or delegated service credentials in automated deployment pipelines.

Authors

Genliang Zhu

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 AcquireBound, 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.