chelof100/acp-framework-enAgent Control Protocol (ACP) — Official English specification. Cryptographically verifiable authorization architecture for autonomous AI agents.
Admission control for agent actions.
Before any agent mutates system state, ACP answers four questions: Who is this agent? What are they authorized to do? Is this action policy-compliant? Can the outcome be traced to an accountable institution?
Cryptographic identity · Scoped capability tokens · Verifiable delegation chains · Execution proof
https://agentcontrolprotocol.xyz
Agent Control Protocol: Admission Control for Agent Actions Marcelo Fernandez (TraslaIA), 2026
DOI: 10.5281/zenodo.19672575 · arXiv: 2603.18829
ACP is the published foundation of a ten-paper series on formal agent governance. Each paper addresses a distinct layer of the governance stack.
| Paper | Title | Repo | Status |
|---|---|---|---|
| Paper 0 | Atomic Decision Boundaries | decision-boundary-model | Zenodo · arXiv:2604.17511 |
| Paper 1 | Agent Control Protocol (ACP) — this repo | acp-framework-en | Zenodo · arXiv:2603.18829 |
| Paper 2 | From Admission to Invariants (IML) | iml-benchmark | Zenodo · arXiv:2604.17517 |
| Paper 3/4 | Irreducible Governance Structure | governance-structure | Zenodo · arXiv: on appeal |
| Paper 5 | Reconstructive Authority Model (RAM) | reconstructive-authority-model | Zenodo · arXiv:2604.22898 |
| Paper 6 | Operationalizing Reconstructive Authority | operationalizing-ram | Zenodo · arXiv:2605.23935 |
| Paper 7 | Closing the Execution Gap (Empirical) | agent-governance-applied | Zenodo · arXiv: on appeal |
| Paper 8 | Identity-Bound Governance (APB) | identity-bound-governance | Zenodo · arXiv: on appeal |
| Paper 9 | MCP-Native Governance | mcp-governed-agents | Zenodo · arXiv: pending |
| Paper 10 | Non-Blocking Governance | non-blocking-governance | Zenodo · arXiv: pending |
Series logic: Paper 0 proves when admissibility can be guaranteed → Paper 1 (ACP) builds the protocol → Paper 2 detects drift invisible to enforcement → Paper 3/4 proves correct enforcement ≠ fair allocation and establishes the irreducibility of the four-layer architecture → Paper 5 (RAM) provides operational closure: when to execute under partial observability → Paper 6 operationalizes RAM as a runtime Recovery Loop → Paper 7 provides the first empirical validation of the full stack on real LangGraph agents → Paper 8 establishes identity-bound accountability for halted agents (Phase II: governance of governance) → Paper 9 deploys that governance transparently at the MCP protocol layer → Paper 10 makes it non-blocking via escrow-based asynchronous human oversight.
Autonomous agents are moving from experimentation into production. They already interact with APIs, enterprise systems, financial infrastructure, and other agents.
When one acts across organizations, several questions immediately arise:
Today, most systems cannot answer these questions reliably.
ACP introduces the infrastructure to answer all of them.
Several initiatives address how autonomous agents interact with systems. Most focus on tool access or communication. ACP focuses on authority, execution verification, and institutional accountability.
| Protocol | Focus | Scope boundary |
|---|---|---|
| MCP (Model Context Protocol) | Tool access for LLMs | Authority verification, policy enforcement, execution auditability |
| A2A (Agent-to-Agent) | Agent communication patterns | Institutional trust, governance, accountability chain |
| OpenAI Agents SDK | Tool orchestration | Cross-organization authority, provenance, liability |
| Agent Client Protocol ¹ | Runtime client/agent integration | Governance, delegation chains, verifiable execution history |
| ACP (Agent Control Protocol) | Governance & accountability infrastructure | — |
ACP addresses a different layer: who authorized the action, under what policy, and who is accountable for the outcome.
Engineers evaluating ACP often ask: "why not use OPA?" These systems are complementary, not competitive.
| System | What it does | What ACP adds |
|---|---|---|
| OPA (Open Policy Agent) | Evaluates policies from data and rules | Cryptographic agent identity + delegation chain + execution proof |
| AWS IAM / Azure RBAC | Static permission model for cloud resources | Dynamic agent-to-agent delegation with verifiable chain + ledger |
| OAuth 2.0 + OIDC | User and service authorization via tokens | Multi-hop agent delegation with non-escalation + institutional liability |
| SPIFFE / SPIRE | Cryptographic workload identity | ACP builds on workload identity to add capability scoping + governance |
| ACP | Admission control for agent actions | — |
OPA can be used as the policy evaluation engine inside an ACP-compliant system. ACP does not replace OPA — it adds the agent identity layer, delegation chain, and execution proof that OPA does not provide.
¹ ACP (Agent Control Protocol) is unrelated to other initiatives sharing the same acronym.
Kubernetes uses an Admission Controller to intercept API requests before they reach the cluster — evaluating policies, enforcing quotas, rejecting non-compliant operations. ACP applies the same pattern to agent actions.
agent intent
↓
[1] Identity check → pkg/agent + pkg/hp (ACP-AGENT-1.0, ACP-HP-1.0)
↓
[2] Capability check → pkg/ct + pkg/dcma (ACP-CT-1.0, ACP-DCMA-1.0)
↓
[3] Policy check → pkg/risk + pkg/psn (ACP-RISK-3.0, ACP-PSN-1.0)
↓
[4] ADMIT / DENY / ESCALATE
↓ (if ADMIT)
[5] Execution token → pkg/exec (ACP-EXEC-1.0)
↓
[6] Ledger record → pkg/ledger (ACP-LEDGER-1.3)
↓
system state mutation
The difference from Kubernetes: ACP operates across institutional boundaries. An agent from Bank A can be admitted by Bank B without Bank B trusting Bank A's internal infrastructure — only the cryptographic proof matters.
ACP treats agent interactions as governed operations, not simple requests.
Every interaction passes through six structured stages: