Protocol Positioning

ACP is the admission control layer between agent intent and system state mutation. It is not an agent framework, a policy engine, or an auth service — it is the governance protocol that ties them together. Here is how ACP relates to adjacent technologies.

ACP vs. Agent Frameworks

These systems build and run agents. ACP governs what those agents are permitted to do.

Protocol / Framework	Primary Focus	Primary Limitation	ACP's Approach
MCP (Model Context Protocol)	Standardized tool access for LLMs	Does not enforce authority verification or robust execution governance across institutions.	ACP is the governance wrapper around MCP: before an MCP tool call executes, ACP verifies identity, capability, and policy.
A2A (Agent-to-Agent)	Standardizing routing and communication between autonomous agents.	Does not address the underlying institutional accountability or policy constraints for requested actions.	ACP ensures every A2A message carries a verifiable authority chain traceable back to an institutional root.
OpenAI Agents SDK / LangGraph / CrewAI	Development and orchestration of autonomous agents.	Vendor-specific or framework-specific; lacks cross-institution governance and cryptographic execution proofs.	ACP operates independently of the orchestration framework, adding a standardized governance layer compatible with any agent runtime.
ACP (Agent Control Protocol)	Admission control for agent actions	Does not orchestrate tools or handle LLM reasoning natively.	Works alongside existing orchestrators. Any agent framework can use ACP as its governance layer.

ACP vs. Policy & Auth Systems

These systems evaluate permissions. ACP complements them by adding a cryptographic authority chain, delegation model, and immutable execution record specific to autonomous agents.

System	What it does well	What it does not cover	How ACP relates
OPA (Open Policy Agent)	Evaluates Rego policies against structured data. Excellent for static rule evaluation.	No cryptographic identity for agents. No delegation chain. No execution proof or immutable audit log.	ACP can call OPA as the policy evaluation backend (AcceptableRisk check) while adding the identity, delegation, and ledger layers OPA does not provide.
AWS IAM / Azure RBAC	Static role-based permissions for cloud resources. Well understood by platform teams.	Permissions are static and user-centric. No model for dynamic agent delegation, capability scoping, or action-level audit chains.	ACP's capability tokens extend IAM-style permissions to autonomous agents: scoped, time-bounded, with a cryptographic delegation chain from human principal to agent.
OAuth 2.0 + OIDC	Delegated API access for user-facing applications. Tokens grant access to APIs on behalf of users.	Designed for human-initiated flows. No support for agent-to-agent delegation, risk scoring, or action-level execution proofs.	ACP extends the OAuth2 delegation model to multi-agent chains: human → agent → sub-agent → tool, with cryptographic proof at each step and an immutable execution record.
SPIFFE / SPIRE	Workload identity via X.509 SVIDs. Excellent for service-to-service mTLS.	Establishes who the workload is, not what it is authorized to do or what policy governed its action.	ACP can use SPIFFE identities as the root of the ACP delegation chain, adding the capability, policy, and execution governance layers on top of workload identity.
ACP (Agent Control Protocol)	Cryptographic authority chain + delegation + execution proof, designed for autonomous agents	Does not replace policy engines or identity providers — it orchestrates them.	ACP is the governance protocol layer. OPA, IAM, and SPIFFE are building blocks it can integrate with.