Agent Control Protocol: Admission Control for Agent Actions

Agent Control Protocol ACP v1.13: Admission Control for Agent Actions Technical Specification and Reference Implementation Marcelo Fernandez TraslaIA info@traslaia.com https://agentcontrolprotocol.xyz March 2026 Draft Standard Abstract Agent Control Protocol (ACP) is a formal technical specification for governance of autonomous agents in B2B institutional environments. ACP is the admission control layer between agent intent and system state mutation: before any agent action reaches execution, it must pass a cryptographic admission check that validates identity, capability scope, delegation chain, and policy compliance simultaneously. ACP defines the mechanisms of cryptographic identity, capability-based authorization, de- terministic risk evaluation, verifiable chained delegation, transitive revocation, and immutable auditing that a system must implement for autonomous agents to operate under explicit institu- tional control. ACP operates as an additional layer on top of RBAC and Zero Trust, without replacing them. It is designed specifically for the problem that neither model solves: governing what an autonomous agent can do, under what conditions, with what limits, and with complete traceability for external auditing—including across organizational boundaries. The v1.13 specification comprises 36 technical documents organized into five conformance levels (L1–L5). It includes a Go reference implementation of 22 packages covering all L1–L4 capabilities, 51 signed conformance test vectors (Ed25519 + SHA-256), and an OpenAPI 3.1.0 specification for all HTTP endpoints. It defines more than 62 verifiable requirements, 12 prohibited behaviors, and the mechanisms for interoperability between institutions. Specification and implementation:https://github.com/chelof100/acp-framework-en Contents 1 The Problem ACP Solves4 1.1 The Structural Gap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 ACP as Admission Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3 Why RBAC and Zero Trust Are Insufficient . . . . . . . . . . . . . . . . . . . . . . . 5 1.4 The Concrete Scenario ACP Prevents . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1 arXiv:2603.18829v1 [cs.CR] 19 Mar 2026 2 What ACP Is6 2.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2 Design Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3 Formal Agent Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.4 Layered Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3 Technical Mechanisms7 3.1 Serialization and Signing (ACP-SIGN-1.0) . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2 Capability Token (ACP-CT-1.0) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3 Handshake and Proof-of-Possession (ACP-HP-1.0) . . . . . . . . . . . . . . . . . . . 8 3.4 Deterministic Risk Evaluation (ACP-RISK-1.0) . . . . . . . . . . . . . . . . . . . . . 8 3.5 Verifiable Chained Delegation (ACP-DCMA-1.1) . . . . . . . . . . . . . . . . . . . . 9 3.6 Execution Token (ACP-EXEC-1.0) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.7 Audit Ledger (ACP-LEDGER-1.3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4 Inter-Institutional Trust10 4.1 Institutional Trust Anchor (ACP-ITA-1.0) . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2 Mutual Recognition (ACP-ITA-1.1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.3 Institutional Key Rotation and Revocation . . . . . . . . . . . . . . . . . . . . . . . 11 5 Cross-Organization Execution11 5.1 Interaction Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.2 Fault Tolerance and Retry Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.3 Derived Interaction Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.4 Interaction State Invariants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.5 Pending Review SLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.6 CROSS_ORG_ACK as a First-Class Ledger Event . . . . . . . . . . . . . . . . . . . 12 5.7 Security Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6 Security Model13 6.1 Threat Model (STRIDE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.2 Guaranteed Security Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.3 Declared Residual Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7 Conformance and Interoperability14 2 7.1 Conformance Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.2 Conformance Declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.3 Prohibited Behaviors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.4 B2B Interoperability Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8 Use Cases15 8.1 Financial Sector — Inter-Institutional Payment Agents . . . . . . . . . . . . . . . . . 15 8.2 Digital Government — Document Processing . . . . . . . . . . . . . . . . . . . . . . 16 8.3 Enterprise AI — Multi-Company Orchestration . . . . . . . . . . . . . . . . . . . . . 16 8.4 Critical Infrastructure — Monitoring and Actuation Agents . . . . . . . . . . . . . . 16 9 Specification and Implementation Status16 9.1 Active Specifications — v1.13 (36 documents) . . . . . . . . . . . . . . . . . . . . . . 16 9.2 Reference Implementation — 22 Go Packages . . . . . . . . . . . . . . . . . . . . . . 16 9.3 Conformance Test Vectors — 51 Signed Vectors . . . . . . . . . . . . . . . . . . . . . 16 9.4 Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 10 How to Implement ACP16 10.1 Minimum Requirements for L1 Conformance . . . . . . . . . . . . . . . . . . . . . . 17 10.2 Additional Requirements for L3 Conformance . . . . . . . . . . . . . . . . . . . . . . 18 10.3 What ACP Does Not Prescribe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 11 Conclusion19 A Glossary20 3 1 The Problem ACP Solves Autonomous agents are being deployed in institutional environments without a technical standard to govern their behavior. This is not a tooling problem—it is a protocol problem. 1.1 The Structural Gap When an autonomous agent makes a decision and executes it, there is a critical moment between both actions. In current models, that moment does not formally exist: the decision and the execution are the same event. The agent decides and acts. There is no intermediate validation. There is no point of intervention. There is no structured record of why the decision was made. This is acceptable when a human executes that action, because the human bears responsibility and can be questioned. An autonomous agent cannot be questioned. It can only be audited—and only if there is something to audit. The problem is not whether agents are trustworthy. The problem is that currently no formal technical mechanism exists that allows an institution to demonstrate that its agents operated within authorized limits. 1.2 ACP as Admission Control The clearest frame for understanding what ACP does is the Kubernetes Admission Controller analogy. Kubernetes intercepts every API request before it reaches the cluster and runs it through a sequence of admission checks—ValidatingWebhookConfiguration,ResourceQuotaenforcement, OPA Gatekeeper policies. If any check fails, the request is rejected before touching cluster state. ACP applies this pattern to agent actions: agent intent | [1] Identity check (ACP-AGENT-1.0, ACP-HP-1.0) | is this agent who they claim to be? [2] Capability check (ACP-CT-1.0, ACP-DCMA-1.1) | does the agent hold a valid token for this action? [3] Policy check (ACP-RISK-1.0, ACP-PSN-1.0) | is this action within current policy? [4] ADMIT / DENY / ESCALATE | (if ADMIT) [5] Execution token (ACP-EXEC-1.0) | single-use cryptographic proof of admission [6] Ledger record (ACP-LEDGER-1.3) | immutable signed audit entry system state mutation The critical difference from Kubernetes: ACP’s admission check operates across institutional boundaries. An agent from Bank A can be admitted by Bank B without Bank B trusting Bank A’s 4 internal infrastructure—the cryptographic proof is self-contained and verifiable with Bank A’s published public key alone. This admission control framing also clarifies the relationship with related tools: •OPA (Open Policy Agent) [3] can serve as the policy evaluation engine inside Step 3. ACP does not replace OPA; it adds the identity and delegation chain layers above it. • AWS IAM / Azure RBAC model static role permissions for humans. ACP adds dynamic agent delegation with execution proof. •OAuth 2.0 [1] handles API access tokens. ACP extends delegation to multi-agent chains with non-escalation and verifiable provenance. • SPIFFE / SPIRE [5] provides cryptographic workload identity. ACP builds on that identity to add capability scoping and governance. 1.3 Why RBAC and Zero Trust Are Insufficient RBAC and Zero Trust are the predominant control layers in enterprise environments. Both are necessary. Neither solves the problem of governing autonomous agents: CriterionRBACZero TrustACP Designed forHuman roles Network accessAutonomous agents Cryptographic identityNoPartialYes (Ed25519, mandatory) Verifiable dynamic delegationNoNoYes (chained, auditable) Decision/execution separationNoNoYes (Execution Tokens) Real-time risk evaluationNoPartialYes (deterministic) Multi-institutional auditingNon-standard Non-standardNative (signed ledger) Transitive delegation revocationNoNoYes (formal propagation) B2B interoperability for agents Unstructured UnstructuredCentral protocol design Table 1: Comparison of ACP with RBAC and Zero Trust across agent governance criteria. ACP does not replace RBAC or Zero Trust. It adds a governance layer oriented specifically to autonomous agents that operates above existing controls. 1.4 The Concrete Scenario ACP Prevents Without ACP: A financial processing agent receives instructions from another agent to execute a transfer. The agent executes the action. If the instruction was legitimate, everything works. If it was compromised, injected, or generated by an unauthorized agent, the transfer occurs anyway. No formal mechanism exists to prevent it, nor is there a technical record that allows reconstructing the authorization chain. With ACP: The agent requesting the transfer must present a Capability Token cryptographically signed by the issuing institution, demonstrate possession of the associated private key, and the request passes through the risk engine before receiving an Execution Token. The ET is single-use. The entire chain is recorded in the Audit Ledger with an externally verifiable institutional signature. 5 2 What ACP Is A formal technical specification—not a framework, not a platform, not a set of best practices. A protocol with precise definitions, formal state models, verifiable flows, and explicit conformance requirements. 2.1 Definition Agent Control Protocol (ACP) is a technical specification that defines the mechanisms by which autonomous institutional agents are identified, authorized, monitored, and governed in B2B envi- ronments. It establishes the formal contract between an agent, the institution that operates it, and the institutions with which it interacts. Core invariant: Execute(request) =⇒ ValidIdentity(agent)∧ ValidCapability∧ ValidDelegationChain∧ AcceptableRisk No action of an ACP agent can be executed without all four predicates being simultaneously true. If any fails, the action is denied. No exceptions. 2.2 Design Principles ACP was designed with five principles that are non-negotiable at implementation time: P1Fail Closed. On any internal component failure, the action is denied. Never approved by default. P2Identity is cryptography.AgentID=base58(SHA-256(public_key)). No usernames. No arbitrary IDs. Identity cannot be claimed—it must be demonstrated in every request. P3 Delegation does not expand privileges. The delegated agent’s permissions are always a strict subset of the delegator’s permissions. This property is cryptographically verified at every chain hop. P4Complete auditability. Every decision—approved, denied, or escalated—is recorded in an append-only ledger with institutional signature. Not just successes. Everything. P5 External verification possible. Any institution can verify ACP artifacts from another institution using only the public key registered in the ITA. No dependency on proprietary systems. 2.3 Formal Agent Model In ACP, an agent is a formal tuple with well-defined state: A = ( AgentID, capabilities, autonomy_level, state, limits ) 6 FieldTypeDescription AgentIDString (43–44 chars) base58(SHA-256(pk)). Derived from public key. Immutable. capabilitiesList of stringsExplicit permissions.Format: acp:cap:<domain>.<action>. Never ab- stract roles. autonomy_level Integer 0–4 Determines risk evaluation thresholds. 0 = no autonomy. 4 = maximum. stateEnum active | restricted | suspended | revoked . Transition torevokedis unidirec- tional. limitsObjectRate limits, maximum amounts, time windows. Not modifiable at runtime. Table 2: ACP formal agent tuple fields. 2.4 Layered Architecture ACP does not replace existing security infrastructure. It is added as an upper layer: ACP Layer -- Autonomous agent governance: identity, authorization, risk, auditing RBAC Layer -- Role-based access control for human users Zero Trust -- Continuous identity and network access verification 3 Technical Mechanisms ACP defines six interdependent mechanisms. Each has its own formal specification, state model, data structure, protocol flow, and error codes. 3.1 Serialization and Signing (ACP-SIGN-1.0) Every verification in ACP begins with signature verification. ACP-SIGN-1.0 defines the exact process that produces a binary result—valid or invalid—without ambiguity: 1.Canonicalization with JCS (RFC 8785) [4]. Produces a deterministic representation of the JSON object, independent of field order and the system that generated it. 2. SHA-256 hash over the canonical output in UTF-8. 3. Ed25519 signature (RFC 8032) [2] over the hash. 32-byte key, 64-byte signature. 4. Base64url encoding without padding for transmission. Signature verification precedes all semantic validation. An object with an invalid signature is rejected without processing its content. This rule has no exceptions (PROHIB-003, PROHIB-012). 7 3.2 Capability Token (ACP-CT-1.0) The Capability Token is ACP’s central artifact. It is a signed JSON object that specifies exactly what an agent can do, on what resource, for how long, and whether it can delegate that capability to other agents. "ver": "1.0", "iss": "<AgentID_issuer>", "sub": "<AgentID_subject>", "cap": ["acp:cap:financial.payment"], "res": "org.example/accounts/ACC-001", "exp": 1718923600, "nonce": "<128bit_CSPRNG_base64url>", "deleg": "allowed": true, "max_depth": 2 , "parent_hash": null, "sig": "<Ed25519_base64url>" Critical fields:expis mandatory—a token without expiry is invalid by definition. The 128-bit nonce prevents replay attacks.parent_hashchains delegated tokens in a verifiable way. The signature covers all fields except sig. 3.3 Handshake and Proof-of-Possession (ACP-HP-1.0) Possessing a valid Capability Token is not sufficient to act. ACP-HP-1.0 requires that the bearer demonstrate in every request that they possess the private key corresponding to the AgentID declared in the token. This eliminates the possibility of impersonating an agent with a stolen token. The protocol is stateless—it does not establish sessions, does not produce a session_id, does not require server-side state between requests. The proof occurs in every interaction: 1.The receiving system issues a 128-bit challenge generated by CSPRNG, valid for 30 seconds and single-use. 2. The agent signs the challenge together with the HTTP method, path, and body hash of the request. 3. The receiver verifies the signature using the agent’s public key, obtained from the ITA. 4. The challenge is deleted immediately after use—it cannot be reused. This sequence guarantees four formal properties: identity authentication, cryptographic request binding, anti-replay, and transport channel independence. 3.4 Deterministic Risk Evaluation (ACP-RISK-1.0) Each authorization request passes through a deterministic risk function that produces a Risk Score (RS) in the range [0,100]. The same input always produces the same result—no stochastic elements, no machine learning in the critical path. 8 RS = min 100, B(c) + F ctx (x) + F hist (h) + F res (r) Factor DescriptionExample values B(c)Baseline by capability *.read = 0,financial.payment = 35 F ctx (x) Request contextNon-corporate IP +20; outside hours +15 F hist (h) Agent history (24h)Recent denial +20; anomalous fre- quency +15 F res (r) Resource classification public = 0 ;sensitive = 15; restricted = 45 Table 3: ACP-RISK-1.0 risk scoring factors. The RS determines the decision according to the thresholds configured for the agent’sautonomy_level. Withautonomy_level2 (standard):RS ≤39→APPROVED;RS ∈[40,69]→ESCALATED; RS≥ 70 → DENIED. An agent with autonomy_level 0 always receives DENIED. 3.5 Verifiable Chained Delegation (ACP-DCMA-1.1) ACP allows an agent to delegate capabilities to another agent, which in turn can delegate to a third, up to the maximum depth defined in the root token. Delegation guarantees three properties: •No privilege escalation. The delegated agent’s capability set is always⊆the delegator’s set. Cryptographically verified at every hop via the parent_hash field. •Bounded depth. Themax_depthfield establishes the chain limit. A chain that exceeds it is invalid. • Transitive revocation. Revoking an agent’s token automatically invalidates all delegated tokens that descend from it. 3.6 Execution Token (ACP-EXEC-1.0) The separation between authorization and execution is a core principle of ACP. When the autho- rization engine approves a request, it returns an Execution Token (ET): a single-use artifact with a short lifetime that authorizes exactly that action, on that resource, at that moment. • An ET can only be consumed once. A second presentation is rejected (PROHIB-002). • An expired ET is invalid even if it was never used. • The target system that consumes the ET notifies the ACP endpoint, closing the audit cycle. 3.7 Audit Ledger (ACP-LEDGER-1.3) The Audit Ledger is a chain of cryptographically signed events where each event includes the hash of the previous event: 9 h n = SHA-256( e n ∥ h n−1 ) This structure makes it impossible to modify or delete an event without invalidating the entire subse- quent chain. The ledger records all lifecycle event types: GENESIS, AUTHORIZATION (including DENIED and ESCALATED), RISK_EVALUATION, TOKEN_ISSUED, TOKEN_REVOKED, EXECUTION_TOKEN_ISSUED, and EXECUTION_TOKEN_CONSUMED. Institutions with FULL conformance expose the ledger viaGET /acp/v1/audit/query, allowing external partners to verify chain integrity using only the institutional ITA public key. Modifying or deleting ledger events is prohibited (PROHIB-007, PROHIB-008). It is important to note that the ledger provides verifiable evidence of execution, not enforcement itself. Enforcement in ACP occurs at the policy evaluation and execution layers (ACP-EXEC-1.0, ACP-DCMA-1.1): the Execution Token is the cryptographic artifact that gates actual system-state mutation. The ledger’s role is to make every admission decision—and its outcome—auditable and tamper-evident after the fact. 4 Inter-Institutional Trust In a B2B environment, agents of one institution interact with another institution’s systems. ACP defines the exact mechanism by which this trust is established, verified, and can be revoked. 4.1 Institutional Trust Anchor (ACP-ITA-1.0) The ITA is the authoritative registry that links aninstitution_idto an Ed25519 public key. It is the only point where ACP depends on an out-of-band mechanism: the initial distribution of the ITA authority’s public key. Once that key is resolved, all subsequent verification is autonomous and cryptographic. Each institution registers in the ITA its Root Institutional Key (RIK)—the private key held in HSM that never leaves it. All ACP artifacts from that institution (tokens, ledger events, API responses) are signed with that key. Any third party can verify them by resolving the public key from the ITA. 4.2 Mutual Recognition (ACP-ITA-1.1) When two institutions operate under different ITA authorities, ACP-ITA-1.1 defines the mutual recognition protocol. The process requires both authorities to sign a Mutual Recognition Agreement (MRA) establishing: the scope of recognition, the agreement’s validity period, and the proxy resolution mechanism. Recognition is explicitly non-transitive. If A recognizes B and B recognizes C, A does not au- tomatically recognize C. Each bilateral relationship requires its own signed MRA. This prevents uncontrolled expansion of the trust graph. 10 4.3 Institutional Key Rotation and Revocation Normal rotation includes a transition period of up to 7 days during which both keys are valid, allowing artifacts signed with the old key to be verified during the transition. Emergency rotation is activated when a key is compromised. The result is immediate: the key is markedrevoked, all artifacts signed with it are invalid from that moment, and there is no transition period. 5 Cross-Organization Execution ACP-CROSS-ORG-1.1 defines a fault-tolerant bilateral protocol for interactions between indepen- dent institutions, each operating its own ACP ledger. The protocol closes five gaps identified in the 1.0 version: undefined status tracking, absent retry protocol, unregistered ACK event type, pending_review without SLA, and a stale header reference. 5.1 Interaction Model A cross-organization interaction involves two ACP-compliant institutions: a source institution that originates the bundle and a target institution that validates, executes, and acknowledges it. The protocol operates asynchronously—the source does not block waiting for an ACK. Each interaction carries a mandatoryinteraction_id(UUIDv7), immutable and reused across all retries. This is distinct fromevent_id(UUIDv4), which is unique per emission. The target deduplicates by interaction_id, not by event_id. For example, an agent in Institution A may request execution in Institution B. The request is recorded as aCROSS_ORG_INTERACTIONevent in A’s ledger, transmitted to B, validated against B’s policy and capability registry, and resolved through aCROSS_ORG_ACKevent registered in both ledgers. Institution A derives final execution state from the ACK without storing mutable status. 5.2 Fault Tolerance and Retry Protocol When no CROSS_ORG_ACK is received within the 300-second timeout, the source retries up to three times with exponential backoff: Attempt Wait after timeout 1 (initial) — 2+30 s 3+60 s 4 (final) +120 s After three failed attempts the interaction transitions toretry_exhausted(CROSS-012) and an operational alert is raised. If a valid ACK arrives at any point, all retry timers are cancelled immediately. 11 5.3 Derived Interaction Status The status of a cross-organization interaction is never stored as mutable state. It is always derived from events present in the ledger: Derived status Condition pending_ack CROSS_ORG_INTERACTION exists, no ACK ackedACK with status = accepted rejectedACK with status = rejected pending_review ACK with status = pending_review expired pending_review AND now > review_deadline Precedence rule:accepted > rejected > pending_review. A mutableCROSS_ORG_STATUS_UPDATE event is explicitly prohibited as an anti-pattern that introduces race conditions and divergent audit trails. 5.4 Interaction State Invariants For any interaction_id, ACP enforces the following invariants: • At most one terminal state. Only oneacceptedorrejectedACK may exist per interaction_id; a duplicate with a different payload is rejected (CROSS-014). •ACK dominates retries. A validCROSS_ORG_ACKcancels all pending retry timers immedi- ately, regardless of attempt number. •Immutable correlation key. Retry operations MUST NOT create newinteraction_id values; only event_id changes across attempts. •No terminal-to-non-terminal regression. Onceacceptedorrejected, the status cannot change. The transitionpending_review → pending_reviewis also prohibited (CROSS-015). 5.5 Pending Review SLA When the target returnspending_review, a 24-hour SLA applies. The ACK payload includes a review_deadlinefield (Unix seconds). Valid terminal transitions are:accepted,rejected, or expired (implicit, when now > review_deadline). 5.6 CROSS_ORG_ACK as a First-Class Ledger Event CROSS_ORG_ACKis registered in ACP-LEDGER-1.3 §5.15 as a first-class event type, signed with Ed25519 and serialized via JCS (RFC 8785). This enables verifiable and auditable execution across independent institutional boundaries, eliminating the audit gap that existed in version 1.0. 5.7 Security Considerations ACP-CROSS-ORG-1.1 assumes authenticated communication channels between institutions. All CROSS_ORG_INTERACTIONandCROSS_ORG_ACKevents are signed with the originating institution’s 12 Ed25519 ITA key and serialized via JCS (RFC 8785), providing authenticity, integrity, and non- repudiation. Without this cryptographic layer, cross-organization events would be subject to forgery, replay, and unauthorized status derivation. Specifically, ACP mitigates: •Replay attacks:interaction_id(UUIDv7) andevent_id(UUIDv4) allow the target to detect and reject duplicate submissions. •Event forgery: Ed25519 signatures over JCS-canonical payloads prevent an adversary from injecting valid-looking ACK or interaction events. •Audit divergence: BecauseCROSS_ORG_ACKis a first-class ledger event on both sides, independent auditors can verify consistency without trusting either institution’s mutable state. ACP does not eliminate all sources of failure in distributed systems, but provides a structured model for detecting, handling, and auditing them. 6 Security Model ACP explicitly defines which threats it mitigates, which properties it guarantees, and which risks fall outside its scope. 6.1 Threat Model (STRIDE) CategoryThreatMitigation in ACP SpoofingAgentID impersonationAgentID=SHA-256(pk). Without valid signature → immediate DENIED. TamperingToken or event alterationEd25519 covers all fields. Chained ledger: altering one event invalidates all subse- quent. RepudiationAgent denies executed actionActionRequest digitally signed. Non- repudiation by design. Info Disclosure Capability exposureTokens reveal only the necessary subset. Channel confidentiality via TLS. DoSRequest floodingRate limits peragent_id. Anomalous fre- quency control. ElevationDelegation that expands privileges C delegated ⊆ C original . Cryptographically verified at each hop. Table 4: STRIDE threat model and ACP mitigations. 6.2 Guaranteed Security Properties ACP guarantees the following properties when the implementation is compliant: • Artifact integrity. EUF-CMA security of Ed25519. Impossible to modify a token or event without invalidating the signature. 13 •Identity authenticity. Only whoever possessesskcan generate a valid signature under the corresponding pk. • No privilege escalation via delegation. Demonstrable by induction over the delegation chain. • Anti-replay. The single-use challenge makes reusing a proof of possession ineffective. •Effective revocation.Valid(t) =valid_sig∧¬expired∧¬revoked∧ valid_delegation. All four conditions must be true simultaneously. 6.3 Declared Residual Risks ACP explicitly declares what it cannot resolve: •Total compromise of the RIK held in HSM. ACP defines the emergency rotation process but cannot prevent a physical compromise of the custody infrastructure. • Coordinated institutional collusion. If multiple institutions act maliciously in a coordi- nated manner, they can generate valid artifacts. ACP guarantees traceability, not prevention of malicious agreements between parties. • Implementation failures. ACP is a specification. An implementation that violates pro- hibited behaviors can compromise all protocol guarantees. Conformance requires formal testing. •ITA bootstrap. The only point that depends on an out-of-band channel. Once the ITA root key is resolved, everything subsequent is autonomous. 7 Conformance and Interoperability 7.1 Conformance Levels LevelRequired documentsEnabled capability L1 — COREACP-SIGN-1.0, ACP-CT-1.0, ACP-HP-1.0Token issuance with cryptographic PoP L2 — SECURITYL1 + ACP-RISK-1.0, ACP-REV-1.0, ACP-ITA-1.0Risk eval, transitive revocation, ITA L3 — FULLL2 + ACP-API-1.0, ACP-EXEC-1.0, ACP-LEDGER-1.3Complete verifiable auditing L4 — EXTENDEDL3 + ACP-PAY-1.0, ACP-NOTIFY-1.0, ACP-DISC-1.0, . . . Full governance suite L5 — DECENTRAL. L4 + ACP-D suiteFederation without central ITA Table 5: ACP-CONF-1.2 conformance levels. 7.2 Conformance Declaration Every compliant implementation MUST expose a public endpoint without authentication: GET https://<endpoint>/acp/v1/conformance This endpoint returns the achieved level, implemented documents, declared extensions, and declara- tion date. It allows any external partner to verify the conformance level of a counterparty before establishing an ACP relationship. 14 7.3 Prohibited Behaviors ACP defines 12 behaviors that no compliant implementation can exhibit. If any is exhibited, the implementation cannot declare conformance at any level: CodeProhibited behavior PROHIB-001 Approving a request when any evaluation component fails PROHIB-002 Reusing an already-consumed Execution Token PROHIB-003 Omitting signature verification on any incoming artifact PROHIB-004 Treating a not-found token_id as active in a revocation context PROHIB-005 Allowing state transition from revoked PROHIB-006 Issuing an ET without a prior APPROVED AuthorizationDecision PROHIB-007 Modifying or deleting Audit Ledger events PROHIB-008 Silencing ledger corruption detection PROHIB-009 Ignoring max_depth in delegation chains PROHIB-010 Implementing an offline policy more permissive than ACP-REV-1.0 PROHIB-011 Approving requests from agents with autonomy_level 0 PROHIB-012 Continuing to process an artifact with an invalid signature Table 6: ACP prohibited behaviors. Exhibiting any disqualifies conformance at all levels. 7.4 B2B Interoperability Conditions • L1 Interoperability: Institution A can verify tokens from B if both implement ACP-CONF- L1, A has access to B’s public key (via ITA or out-of-band), and B’s tokens use ACP-SIGN-1.0 algorithms. • L2 Interoperability: A can delegate to B’s agents if both implement ACP-CONF-L2, are registered in a common ITA or with mutual recognition, and B’s revocation endpoint is accessible to A. •L3 Interoperability: A can audit B’s ledger if B implements ACP-CONF-L3, A can resolve B’s public key via ITA, and B exposes GET /acp/v1/audit/query. 8 Use Cases ACP is sector-agnostic. The mechanisms are identical regardless of industry. What varies is the configuration of capabilities, resources, and autonomy levels. 8.1 Financial Sector — Inter-Institutional Payment Agents ACP-PAY-1.0 extends the capability registry with formal specifications foracp:cap:financial.payment andacp:cap:financial.transfer. Mandatory constraints in the token includemax_amountand currency. 12 specific validation steps cover limit verification, beneficiary validation, and time window control. In a financial B2B scenario, Bank A can authorize an agent to execute payments up to a defined amount to pre-approved beneficiaries, with a complete record verifiable by Bank B without needing shared proprietary systems. 15 8.2 Digital Government — Document Processing Government agents that process documents can operate under ACP withautonomy_level1 or 2, requiring human review for any action with a Risk Score above the configured threshold. Ledger traceability provides forensic evidence for regulatory audits and transparency processes. 8.3 Enterprise AI — Multi-Company Orchestration In agent pipelines that cross organizational boundaries, ACP allows each organization to maintain formal control over what other organizations’ agents can do in their systems. Chained delegation allows an agent in company A to operate in company B’s systems with explicitly delegated capabilities, without B needing to trust A’s internal controls—only the chain of signed tokens. 8.4 Critical Infrastructure — Monitoring and Actuation Agents For systems where an incorrect action has irreversible consequences,autonomy_level0 ensures any actuation request is DENIED without evaluating the Risk Score. The ledger provides the forensic record needed for post-incident analysis. 9 Specification and Implementation Status ACP v1.13 is a complete Draft Standard specification with a full Go reference implementation. 9.1 Active Specifications — v1.13 (36 documents) 9.2 Reference Implementation — 22 Go Packages The Go reference implementation inimpl/go/covers all L1–L4 conformance levels. All 22 packages passgo test ./.... A Python SDK (impl/python/) covers the ACP-HP-1.0 handshake and all ACP-API-1.0 endpoints. 9.3 Conformance Test Vectors — 51 Signed Vectors The compliance/test-vectors/ directory contains 51 signed test vectors per ACP-TS-1.1: 9.4 Roadmap 10 How to Implement ACP ACP is a specification—it does not require adopting any specific platform. It can be implemented on top of existing infrastructure. 16 Level DocumentTitle L1ACP-SIGN-1.0Serialization and Signature L1ACP-AGENT-1.0Agent Identity L1ACP-CT-1.0Capability Tokens L1ACP-CAP-REG-1.0Capability Registry L1ACP-HP-1.0Handshake / Proof-of-Possession L1ACP-DCMA-1.1Delegated Chain Multi-Agent L1ACP-MESSAGES-1.0Wire Message Format L1ACP-PROVENANCE-1.0Authority Provenance L2ACP-RISK-1.0Deterministic Risk Engine L2ACP-REV-1.0Revocation Protocol L2ACP-ITA-1.0Institutional Trust Anchor L2ACP-ITA-1.1ITA Mutual Recognition L2ACP-REP-1.2Reputation Module L2ACP-REP-PORTABILITY-1.0 Reputation Portability L3ACP-API-1.0HTTP API L3ACP-EXEC-1.0Execution Tokens L3ACP-LEDGER-1.3Audit Ledger (mandatory institutional sig) L3ACP-PSN-1.0Policy Snapshot L3ACP-POLICY-CTX-1.0Policy Context Snapshot L3ACP-LIA-1.0Liability Attribution L4ACP-HIST-1.0History Query API L4ACP-PAY-1.0Financial Capability L4ACP-NOTIFY-1.0Event Notifications L4ACP-DISC-1.0Service Discovery L4ACP-BULK-1.0Batch Operations L4ACP-CROSS-ORG-1.1Cross-Organization Bundles L4ACP-GOV-EVENTS-1.0Governance Event Stream Gov. ACP-CONF-1.2Conformance — sole normative source Gov. ACP-TS-1.1Test Vector Format Gov. RFC-PROCESSSpecification Process Gov. RFC-REGISTRYSpecification Registry Gov. ACR-1.0Change Request Process Table 7: ACP v1.13 active specification documents by conformance level (32 primary documents shown). The remaining 4 documents are the ACP-D decentralized suite (L5, design phase) not yet published. Superseded versions (CONF-1.0, CONF-1.1, LEDGER-1.2, REP-1.1, AGENT-SPEC-0.3, DCMA-1.0, CROSS-ORG-1.0) archived in archive/specs/. 10.1 Minimum Requirements for L1 Conformance • Ed25519 public key infrastructure. Key pair for each agent. • JCS implementation (RFC 8785). Deterministic canonicalization for all signed artifacts. •Capability Token issuance and verification with all mandatory fields per ACP-CT-1.0 §5. • Handshake endpoint to issue and verify challenges (ACP-HP-1.0 §6). • Capability registry with the core domains of ACP-CAP-REG-1.0. 17 PackageSpecLevel pkg/cryptoACP-SIGN-1.0 + ACP-AGENT-1.0 L1 pkg/tokensACP-CT-1.0L1 pkg/registryACP-CAP-REG-1.0L1 pkg/handshake ACP-HP-1.0L1 pkg/delegation ACP-DCMA-1.1L1 pkg/provenance ACP-PROVENANCE-1.0L1 pkg/riskACP-RISK-1.0L2 pkg/revocation ACP-REV-1.0L2 pkg/reputation ACP-REP-1.2L2 pkg/execution ACP-EXEC-1.0L3 pkg/ledgerACP-LEDGER-1.3L3 pkg/psnACP-PSN-1.0L3 pkg/policyctx ACP-POLICY-CTX-1.0L3 pkg/liaACP-LIA-1.0L3 pkg/histACP-HIST-1.0L4 pkg/govevents ACP-GOV-EVENTS-1.0L4 pkg/notifyACP-NOTIFY-1.0L4 pkg/discACP-DISC-1.0L4 pkg/bulkACP-BULK-1.0L4 pkg/crossorgACP-CROSS-ORG-1.1L4 pkg/payACP-PAY-1.0L4 cmd/acp-server ACP-API-1.0L3 Table 8: Go reference implementation packages. All pass go test ./.... SuitePositive Negative Spec CORE (SIGN, CT, HP) 44L1 DCMA22L1 HP28L1 LEDGER38L3 EXEC27L3 PROV27L1 Total1536 Table 9: Conformance test vector suites. All positive vectors carry real Ed25519 signatures (RFC 8037 Test Key A) and real SHA-256 hash chains. 10.2 Additional Requirements for L3 Conformance • Root Institutional Key held in HSM with documented rotation process. • Registration with an ITA authority (centralized or federated model). • Deterministic risk engine with the four factors of ACP-RISK-1.0. • Revocation endpoint (Mechanism A: online endpoint, or Mechanism B: CRL). • Append-only storage for the Audit Ledger with per-event signing. • Complete HTTP API per ACP-API-1.0, including health and conformance endpoints. • Public conformance declaration at GET /acp/v1/conformance. 18 ItemStatus Core specs (L1–L4), 36 documentsComplete Go reference implementation (22 packages)Complete Conformance test vectors (51 signed)Complete OpenAPI 3.1.0 (openapi/acp-api-1.0.yaml)Complete Python SDK (impl/python/)Complete (L1 + full API client) Docker image (ghcr.io/chelof100/acp-server:latest) Complete L5 Decentralized (ACP-D)Specification in design (v2.0) Post-quantum algorithm migrationResearch phase IETF RFC submissionAfter L5 stabilization Table 10: ACP v1.13 development roadmap. 10.3 What ACP Does Not Prescribe ACP defines the what—mechanisms, flows, data structures, requirements. It does not prescribe the how of internal implementation: programming language, database, HSM provider, ITA provider, or specific integration with existing RBAC or Zero Trust systems. 11 Conclusion Autonomous agents are already operating in institutional environments. The question is not whether they will operate—it is whether they will do so with or without formal governance. ACP proposes that they operate with formal governance, with verifiable mechanisms, and with traceability that can withstand an external audit. ACP is not the first attempt to control autonomous agents. It is the first attempt to do so through a formal technical specification with precise state models, demonstrable security properties, and verifiable conformance requirements. The difference between a best-practices policy and a formal protocol is exactly that: behaviors are defined, failures have specific error codes, and conformance can be verified. The goal of ACP is not to make agents more capable. It is to make them governable. That is a necessary condition for their institutional deployment to be sustainable at scale. ACP does not eliminate all sources of failure in distributed agent systems. It does not prescribe network transport, consensus mechanisms, or business-level dispute resolution. What it provides is a structured, auditable, and formally specified model for admission control, delegation, revocation, and cross-organization interaction— the layer that existing identity and policy frameworks leave unaddressed. The v1.13 specification is complete. A full Go reference implementation (22 packages, L1–L4) and 51 signed conformance test vectors are publicly available athttps://github.com/chelof100/ acp-framework-en. The specification and implementation are open for technical review, pilot implementation, and formal standardization. TraslaIA invites organizations interested in adopting ACP, contributing to its evolution, or partici- pating in the standardization process to reach out directly. 19 Marcelo Fernandez | TraslaIA info@traslaia.com | https://agentcontrolprotocol.xyz A Glossary TermDefinition AgentIDCryptographic identifier:base58(SHA-256(Ed25519_public_key)). Immutable and unforgeable. Capability Token (CT)Signed JSON artifact authorizing an agent to perform specific actions on a defined resource during a limited period. Execution Token (ET) Single-use artifact issued after an APPROVED decision. Autho- rizes exactly that action at that moment. ITAInstitutional Trust Anchor. Authoritative registry linking institution_id to institutional Ed25519 public key. RIK Root Institutional Key. Institution’s Ed25519 key pair held in HSM. Risk Score (RS) Integer in [0,100] produced by the deterministic risk function. Determines the authorization decision. Autonomy Level Integer 0–4 assigned to an agent determining applicable risk evalu- ation thresholds. PoPProof-of-Possession. Cryptographic proof that the bearer of a CT possesses the corresponding private key. Audit LedgerChain of signed events whereh n =SHA-256(e n ∥h n−1 ). Append- only and immutable. MRAMutual Recognition Agreement. Bilateral document signed by two ITA authorities for cross-authority interoperability. ESCALATEDACP decision when RS is in the intermediate range. Action not executed until explicit resolution. Fail ClosedDesign principle: on any internal failure, the action is denied. Never approved by default. Table 11: ACP Glossary. Acknowledgements The ACP specification emerged from analysis of operational challenges in deploying autonomous agents in regulated B2B environments. The protocol design was informed by the IETF RFC process, the Kubernetes admission control architecture, and the SPIFFE/SPIRE workload identity model. References [1] Dick Hardt. The OAuth 2.0 authorization framework. RFC 6749, Internet Engineering Task Force, October 2012. IETF RFC 6749. [2]Simon Josefsson and Ilari Liusvaara. Edwards-curve digital signature algorithm (EdDSA). RFC 8032, Internet Engineering Task Force, January 2017. IETF RFC 8032. 20 [3]Open Policy Agent Contributors. Open policy agent, 2024. Policy evaluation engine. ACP- RISK-1.0 Step 3 is compatible with OPA as backend. [4] Anders Rundgren, Bret Jordan, and Samuel Erdtman. JSON canonicalization scheme (JCS). RFC 8785, Internet Engineering Task Force, June 2020. IETF RFC 8785. [5]SPIFFE Project. SPIFFE / SPIRE: Secure production identity framework for everyone, 2024. Cryptographic workload identity. ACP builds on SPIFFE identity to add capability scoping. 21