ACP — Agent Control Protocol

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

Official Website

https://agentcontrolprotocol.xyz

Paper

Agent Control Protocol: Admission Control for Agent Actions Marcelo Fernandez (TraslaIA), 2026

DOI: 10.5281/zenodo.19672575 · arXiv: 2603.18829

Research Series

ACP is the published foundation of a ten-paper series on formal agent governance. Each paper addresses a distinct layer of the governance stack.

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.

Why ACP Exists

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:

Who authorized the agent to act?
What capabilities does the agent actually have?
What policy allowed the action?
What exactly was executed?
Can that execution be verified later?
Can the full interaction history be reconstructed?

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.

ACP addresses a different layer: who authorized the action, under what policy, and who is accountable for the outcome.

ACP vs Policy & Auth Systems

Engineers evaluating ACP often ask: "why not use OPA?" These systems are complementary, not competitive.

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.

ACP as Admission Control

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.

How ACP Works

ACP treats agent interactions as governed operations, not simple requests.

Every interaction passes through six structured stages:

Identity verification — confirm who the agent is (ACP-AGENT-1.0, ACP-HP-1.0)
Capability validation — confirm what the agent is authorized to do (ACP-CT-1.0, ACP-DCMA-1.0)
Policy authorization — confirm the action is permitted under current policy (ACP-RISK-3.0, ACP-PSN-1.0)
Deterministic execution — execute exactly what was authorized, nothing more (ACP-EXEC-1.0)
Verifiable recording — produce cryptographic proof of what occurred (ACP-LEDGER-1.3, ACP-PROVENANCE-1.0)
Trust update — update reputation and attestation state based on the interaction (ACP-REP-1.2, ACP-LIA-1.0)

This allows interactions to become traceable, auditable and attributable across organizations.

Constitutional Invariant

ACP execution is governed by a single architectural invariant.

Execute(request) ⟹
    ValidIdentity  ∧  ValidCapability  ∧  ValidDelegationChain  ∧  AcceptableRisk

Condition	Meaning
`ValidIdentity`	The agent has a verified, signed identity

No agent action is executed unless all four conditions are satisfied simultaneously.

The protocol layers exist to enforce this invariant at every interaction boundary.

Protocol Architecture

ACP is organized in five protocol layers. Each layer builds on the previous and adds a distinct governance capability.

                    ACP PROTOCOL ARCHITECTURE

             ┌──────────────────────────────────────┐
             │                ACTORS                │
             │       Humans · Systems · Agents      │
             └──────────────────────────────────────┘
                                │
                                ▼
==================================================================== L1 — CORE EXECUTION

┌──────────────────────────────────────────────────────────────────┐
│ IDENTITY & CAPABILITIES                                          │
│ SIGN · AGENT · CT · CAP-REG                                      │
│                                                                  │
│ Agent identity, credential verification and capability registry  │
└──────────────────────────────────────────────────────────────────┘
                                │
                                ▼
┌──────────────────────────────────────────────────────────────────┐
│ POLICY & AUTHORITY                                               │
│ HP · DCMA                                                        │
│                                                                  │
│ Policy evaluation and authorization decision                     │
└──────────────────────────────────────────────────────────────────┘
                                │
                                ▼
┌──────────────────────────────────────────────────────────────────┐
│ EXECUTION                                                        │
│ MESSAGES                                                         │
│                                                                  │
│ Deterministic command execution and interaction handling         │
└──────────────────────────────────────────────────────────────────┘

==================================================================== L2 — TRUST LAYER

┌──────────────────────────────────────────────────────────────────┐
│ RISK MANAGEMENT                                                  │
│ RISK · REV                                                       │
│                                                                  │
│ Risk scoring and revocation control                              │
└──────────────────────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────────────────────┐
│ INTERACTION TRUST                                                │
│ ITA                                                              │
│                                                                  │
│ Trust attestations for interactions                              │
└──────────────────────────────────────────────────────────────────┘

==================================================================== L3 — VERIFIABLE EXECUTION

┌──────────────────────────────────────────────────────────────────┐
│ EXECUTION RECORD                                                 │
│ EXEC · POLICY-CTX                                                │
│                                                                  │
│ Proof of execution and policy context snapshot                   │
└──────────────────────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────────────────────┐
│ PROVENANCE                                                       │
│ PROVENANCE GRAPH                                                 │
│                                                                  │
│ Interaction lineage and cross-system event tracking              │
└──────────────────────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────────────────────┐
│ LEDGER                                                           │
│                                                                  │
│ Tamper-resistant storage for verifiable execution history        │
└──────────────────────────────────────────────────────────────────┘

==================================================================== L4 — GOVERNANCE

┌──────────────────────────────────────────────────────────────────┐
│ GOVERNANCE EVENTS                                                │
│ GOV-EVENTS                                                       │
│                                                                  │
│ Institutional governance tracking                                │
└──────────────────────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────────────────────┐
│ REPUTATION & LIABILITY                                           │
│ REP · LIA                                                        │
│                                                                  │
│ Reputation accumulation and liability attribution                │
└──────────────────────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────────────────────┐
│ HISTORICAL RECORD                                                │
│ HIST                                                             │
│                                                                  │
│ Verifiable long-term interaction history                         │
└──────────────────────────────────────────────────────────────────┘

==================================================================== L5 — FEDERATION

┌──────────────────────────────────────────────────────────────────┐
│ DECENTRALIZED ACP                                                │
│ ACP-D                                                            │
│                                                                  │
│ Cross-institution federation and verification                    │
└──────────────────────────────────────────────────────────────────┘

→ New to ACP? Start here: docs/admission-flow.md — the complete step-by-step guide to the admission check

→ Formal domain model and dependency graph: ARCHITECTURE.md

Cross-Institution Interaction

ACP is designed for interactions between independent systems. Every step produces a verifiable artifact that becomes part of the permanent interaction record.

      INSTITUTION A                               INSTITUTION B
┌─────────────────────────────┐           ┌─────────────────────────────┐
│                             │           │                             │
│           AGENT A           │           │           AGENT B           │
│                             │           │                             │
└──────────────┬──────────────┘           └──────────────┬──────────────┘
               │                                         │
               │  1  interaction request                 │
               └────────────────────────────────────────►│
                                                         ▼
                                          ┌───────────────────────────┐
                                          │       AUTHORITY (HP)      │
                                          │  policy evaluation        │
                                          │  capability validation    │
                                          │  risk / revocation check  │
                                          └─────────────┬─────────────┘
                                                        │  2  decision
                                                        ▼
                                          ┌───────────────────────────┐
                                          │        EXECUTION          │
                                          │  deterministic action     │
                                          │  command execution        │
                                          └─────────────┬─────────────┘
                                                        │  3  execution record
                                                        ▼
                                          ┌───────────────────────────┐
                                          │        PROVENANCE         │
                                          │  interaction lineage      │
                                          │  cross-org attribution    │
                                          └─────────────┬─────────────┘
                                                        │  4  verifiable record
                                                        ▼
                                          ┌───────────────────────────┐
                                          │          LEDGER           │
                                          │  execution hash           │
                                          │  policy context snapshot  │
                                          └─────────────┬─────────────┘
                                                        │  5  trust update
                                                        ▼
                                          ┌───────────────────────────┐
                                          │        REPUTATION         │
                                          │  ITA attestation          │
                                          │  reputation update        │
                                          └───────────────────────────┘

Design Principles

Explicit Authority

Every agent action must be authorized by a defined policy. No implicit permissions. No ambient access.

Deterministic Execution

Execution must match the authorized command exactly. What was authorized is what gets executed — nothing more.

Verifiable History

Every interaction produces cryptographically verifiable artifacts. Execution can be proven after the fact, without trusting any single party.

Institutional Accountability

Responsibility is always attributable to an identifiable actor. Delegation chains are complete and traceable to an institutional root.

Federated Trust

Independent systems can verify each other without a central authority. Trust is earned through verifiable interaction history, not assumed.

Protocol Components

L1 · Core Execution

Identity, capabilities, policy enforcement and deterministic execution.

L2 · Trust Layer

Dynamic risk evaluation and interaction trust management.

Component	Role
RISK	Deterministic risk engine — Risk Score RS (0–100)
REV	Revocation protocol — endpoint and CRL
ITA	Institutional Trust Anchor — trust attestations per interaction

L3 · Verifiable Execution

Every interaction leaves a complete, cryptographically verifiable record.

Component	Role
EXEC	Execution Tokens — single-use, 300s validity
POLICY-CTX

L4 · Governance

Long-term accountability and institutional oversight.

Component	Role
GOV-EVENTS

L5 · Federation

Interoperability across independent institutions.

Component	Role
ACP-D	Decentralized ACP — cross-institution federation, BFT quorum

Active Specification Versions

Current active version per specification. This table is the authoritative reference for "which version to implement".

¹ ACP-SIGN-1.0 remains active as the Ed25519 baseline. ACP-SIGN-2.0 adds the post-quantum extension (ML-DSA-65). Both are in effect until Dilithium is deployed in production.

Superseded versions are archived in archive/specs/.

Conformance Levels

Implementations may adopt ACP incrementally, starting from L1.

Full normative requirements per level:

→ Normative conformance definition: spec/governance/ACP-CONF-1.2.md

Specifications

L1 · Core Execution

ACP-SIGN-1.0 — cryptographic signing, Ed25519 baseline
ACP-SIGN-2.0 — post-quantum hybrid signing (Ed25519 + ML-DSA-65)
ACP-AGENT-1.0 — formal agent identity A=(ID,C,P,D,L,S)
ACP-CT-1.0 — Capability Token structure, issuance and verification
ACP-CAP-REG-1.0 — canonical capability registry acp:cap:*
ACP-HP-1.0 — Handshake Protocol, cryptographic proof of capability possession
ACP-DCMA-1.0 — multi-hop delegation, non-escalation and transitive revocation
ACP-MESSAGES-1.0 — wire format, 5 normalized message types

L2 · Trust Layer

ACP-RISK-2.0 — deterministic risk engine, Risk Score RS (0–100), F_anom + cooldown
ACP-RISK-3.0 — context-scoped anomaly enforcement; Rule 1 keyed by PatternKey(agentID, cap, res), eliminates cross-context state-mixing
ACP-REV-1.0 — revocation protocol, endpoint and CRL
ACP-ITA-1.0 — Institutional Trust Anchor, centralized model
ACP-ITA-1.1 — Trust Anchor Governance, distributed BFT model

L3 · Verifiable Execution

ACP-EXEC-1.0 — Execution Tokens, single-use, 300s validity
ACP-POLICY-CTX-1.0 — signed policy state at execution time
ACP-PROVENANCE-1.0 — retrospective proof of delegation chain at execution
ACP-LEDGER-1.3 — audit ledger, append-only, hash-chained, mandatory institutional sig
ACP-PSN-1.0 — Process-Session Node, execution session tracking
ACP-API-1.0 — HTTP API, all institutional endpoints

L4 · Governance

ACP-GOV-EVENTS-1.0 — institutional governance event stream
ACP-REP-1.2 — reputation extension, composite score 0.6·ITS + 0.4·ERS
ACP-LIA-1.0 — attributed liability chain
ACP-HIST-1.0 — audited execution history query API
ACP-PAY-1.0 — verifiable financial capability extension
ACP-NOTIFY-1.0 — events and webhooks
ACP-DISC-1.0 — agent registry and resolution
ACP-BULK-1.0 — batch capability execution
ACP-CROSS-ORG-1.0 — inter-institutional agent interactions

L5 · Federation

ACP-D-1.0 — decentralized ACP, cross-institution federation, BFT quorum

Governance

ACP-CONF-1.2 — normative conformance definition (current)
ACP-CHANGELOG — version history

Repository Structure

acp-framework/
├── spec/
│   ├── core/          ← L1: identity, capability, delegation
│   ├── security/      ← L2: trust, risk, revocation
│   ├── operations/    ← L3–L4: execution, ledger, governance
│   ├── governance/    ← conformance, events, process
│   └── decentralized/ ← L5: ACP-D
├── openapi/
│   └── acp-api-1.0.yaml  ← OpenAPI 3.1.0 spec for all ACP-API-1.0 endpoints
├── compliance/
│   ├── ACP-TS-1.1.md      ← test vector format specification
│   ├── test-vectors/      ← single-shot conformance vectors (CORE · DCMA · HP · LEDGER · EXEC · RISK-2.0)
│   │   └── sequence/      ← stateful sequence vectors (ACR-1.0, 5 scenarios)
│   ├── adversarial/       ← adversarial evaluation (Exp 1–12: cooldown evasion, multi-agent, backend stress, token replay, deviation collapse, threshold sensitivity, multi-tool IPI)
│   └── runner/            ← ACR-1.0 compliance runner (library mode + HTTP mode)
├── tla/
│   ├── ACP.tla                   ← base formal model — Safety · LedgerAppendOnly · RiskDeterminism (v1.17)
│   ├── ACP.cfg                   ← TLC configuration for ACP.tla
│   ├── ACP_Extended.tla          ← extended model — F_anom · cooldown · liveness · 11 invariants + 4 temporal (v1.25)
│   ├── ACP_Extended.cfg          ← single-agent config — 5,684,342 states · 3,147,864 distinct · depth 15 · 0 violations
│   └── ACP_Extended_2agents.cfg  ← two-agent config — 4,294,930,695 distinct states · LEDGER_BOUND=11 · 11 invariants · 0 violations
├── archive/
│   └── specs/         ← superseded specification versions (historical reference)
├── impl/
│   └── go/            ← reference implementation
├── ARCHITECTURE.md    ← formal domain model, dependency graph
├── CHANGELOG.md
└── README.md

Quick Start

# Option 1: Go reference server
cd impl/go
docker compose up

# Option 6: ACR-1.0 sequence compliance runner — validate ACP-RISK-3.0 stateful behavior
cd compliance/runner
go run . --mode library --dir ../test-vectors/sequence --strict
# PASS 5/5 — SEQ-BENIGN-001 SEQ-BOUNDARY-001 SEQ-PRIVJUMP-001 SEQ-FANOM-RULE3-001 SEQ-COOLDOWN-001

# Option 5: Multi-org demo — Org-A issues signed policy+reputation, Org-B validates independently
cd examples/multi-org-demo
docker compose up
# Org-A: http://localhost:8081  |  Org-B: http://localhost:8082

# Option 2: Python SDK — core admission control pattern (no server required)
cd impl/python
pip install -e .
python examples/admission_control_demo.py

# Option 3: Python SDK — LangChain integration (@acp_tool decorator)
cd impl/python
pip install -e .
python examples/langchain_agent_demo.py

# Option 4: LangChain + real LLM agent
pip install langchain langchain-openai
export OPENAI_API_KEY=sk-...
python examples/langchain_agent_demo.py --with-llm

# Option 7: Real-LLM IPI demo (Ollama + DeepSeek-R1:8b) — ACP blocks IPI-induced fund_transfer
# Requires: ollama serve && ollama pull deepseek-r1:8b
cd demos/ollama-agent
python agent_demo.py
# ACP denies every IPI-induced fund_transfer (RS=80); cooldown activates after 3 denials

Health check:

curl http://localhost:8080/acp/v1/health

{
  "acp_version": "1.0",
  "status": "operational",
  "timestamp": 1718920000,
  "components": {
    "policy_engine": "operational",
    "audit_ledger": "operational",
    "agent_registry": "operational",
    "rev_endpoint": "operational"
  }
}

Roadmap

License

Apache 2.0

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

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	—

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	—

SIGN	Cryptographic signing — foundation of all protocol objects
AGENT	Formal agent identity specification `A=(ID,C,P,D,L,S)`
CT	Capability Token — structure, issuance and verification
CAP-REG	Canonical capability registry `acp:cap:*`
HP	Handshake Protocol — cryptographic proof of capability possession
DCMA	Multi-hop delegation — non-escalation and transitive revocation
MESSAGES	Wire format — 5 normalized message types

ACP-CONF-1.2	✅ Complete — sole normative conformance source
ACP-LEDGER-1.3	✅ Complete — sig normatively mandatory
OpenAPI spec (`openapi/acp-api-1.0.yaml`)	✅ Complete — OpenAPI 3.1.0, all ACP-API-1.0 endpoints
Conformance test vectors (CORE · DCMA · HP · LEDGER · EXEC · PROV · PCTX · REP · RISK-2.0)	✅ Complete — 73 signed + 65 unsigned RISK-2.0 test vectors
Reference implementation — 23 Go packages (L1–L4)	✅ Complete — `impl/go/pkg/` covers all conformance levels
`pkg/psn` policy snapshot	✅ Complete — atomic transitions, single ACTIVE snapshot
Python SDK — `ACPAdmissionGuard` + `@acp_tool` (LangChain)	✅ Complete — `impl/python/`
ACP-RISK-2.0 — `F_anom` + Cooldown + `pkg/risk`	✅ Complete — deterministic, sub-µs, 65 vectors
ACP-RISK-3.0 — context-scoped Rule 1 (`pkg/risk/engine.go`)	✅ Complete — v1.22 · `CountPattern(ctxKey, 60s)` replaces `CountRequests(agentID)` · cross-context state-mixing eliminated
Payment-agent demo (`examples/payment-agent/`)	✅ Complete — v1.16
ACP-SIGN-2.0 — Post-quantum hybrid (Ed25519 + ML-DSA-65)	✅ Complete — spec v1.16; real ML-DSA-65 via `cloudflare/circl` `pkg/sign2/` v1.20
ACR-1.0 sequence compliance runner (`compliance/runner/`)	✅ Complete — v1.17 · library + HTTP mode · 5/5 PASS
Sequence test vectors (`compliance/test-vectors/sequence/`)	✅ Complete — v1.17 · 5 stateful scenarios
TLA+ base model (`tla/ACP.tla`)	✅ Complete — v1.17 · 3 invariants · 0 violations
TLA+ extended model (`tla/ACP_Extended.tla`)	✅ Complete — v1.28 · 11 invariants + 4 temporal properties · single-agent: 5,684,342 states · two-agent LB=11: 4,294,930,695 distinct states · 0 violations
Adversarial evaluation (`compliance/adversarial/`)	✅ Complete — v1.29 · 14 experiments · real benchmark numbers (N=5 runs, mean±std)
Redis pipelining (`compliance/adversarial/redis_pipelined.go`)	✅ Complete — v1.20 · 2 RTTs/request · ~1.8× speedup
ML-DSA-65 benchmarks (`pkg/sign2/sign2_bench_test.go`)	✅ Complete — v1.20 · Ed25519 ~25 µs sign / ~56 µs verify · ML-DSA-65 ~100–130 µs sign / ~81 µs verify
NullQuerier + StatelessEngine (`pkg/risk/null_querier.go`, `stateless_engine.go`)	✅ Complete — v1.21 · zero-state LedgerQuerier baseline for stateless/stateful comparison
Stateless vs. stateful experiment (Exp 6, `pkg/risk/stateless_comparison_test.go`)	✅ Complete — v1.21 · 500 req · stateless 500/500 vs ACP 2/500 (0.4%) · detection latency 11 actions
State-mixing vulnerability test (Exp 7, `pkg/risk/statemixing_test.go`)	✅ Complete — v1.21 · cross-context Rule 1 contamination · RS +20 · ESCALATED→DENIED after 11 data.read
State-mixing attack analysis (paper §State-Mixing Vulnerability)	✅ Complete — v1.21 · formal characterization · Exp 7 numbers · ACP-RISK-3.0 mitigation path
State-mixing fix (Exp 8, `pkg/risk/statemixing_fix_test.go`)	✅ Complete — v1.22 · RISK-3.0 · 3 scenarios · clean RS=50 ESCALATED · contaminated RS=50 ESCALATED · same-context burst RS=85 DENIED
Paper v1.23 — Sprint fixes	✅ Complete — v1.23 · §RISK-3.0 in §Technical Mechanisms · contrafactual thesis · 767--921 ns unified · Exp 3b→Exp 4 renumbered · Exp 3 N=5 · all 7 cross-check fixes
Deviation collapse (Exp 9, `compliance/adversarial/exp_deviation_collapse.go`)	✅ Complete — v1.23 · 3-phase: baseline BAR=0.70 → collapse BAR=0.00 → counterfactual BAR=1.00
Phase D drift simulation (Exp 9 extension)	✅ Complete — v1.25 · 5 batches × 20 cases · 0%→80% sanitization · ΔBAR early-warning fires at batch 2 (3 batches before collapse)
ITA trust model (paper §Trust Model and Failure Modes)	✅ Complete — v1.20 · bootstrap / compromise window / revocation authority — semi-formal claims
TypeScript SDK (`impl/typescript/`)	✅ Complete — v1.4.0 · zero-deps · 68 tests
Rust SDK (`impl/rust/`)	✅ Complete — v1.4.0 · ed25519-dalek v2 · 43 tests
`pkg/barmonitor` — BAR-Monitor with ΔBAR trend detection (`impl/go/pkg/barmonitor/`)	✅ Complete — v1.24 · 18 tests · AlertThreshold + AlertTrend (fires before threshold) · thread-safe ring buffer
`EvaluateCounterfactual` API (`impl/go/pkg/risk/counterfactual.go`)	✅ Complete — v1.24 · 14 tests · 3 mutation factories (structural/behavioral/temporal) · BAR(results) · fail-closed
Phase D drift simulation (Exp 9) + `computeTrend()` ring buffer fix	✅ Complete — v1.25 · ΔBAR early-warning before threshold · temporal order bug fixed
TLA+ `FailureConditionPreservation` + `NoDegenerateAdmissibility` (11 invariants)	✅ Complete — v1.27 · 0 violations · 4,294,930,695 distinct states (two-agent LB=11, 10.5h)
`POST /acp/v1/counterfactual` HTTP endpoint (`impl/go/cmd/acp-server/`)	✅ Complete — v1.25 · 7 integration tests · structural + behavioral mutations via HTTP
Formal adversary model A=(K,S,B) + experiment taxonomy (Exp 1–14)	✅ Complete — v1.29 · black-box / formula-aware / full-state · all experiments mapped
Threshold sensitivity analysis (Exp 11, 5 configs ±10 pts)	✅ Complete — v1.26 · false-denial rate 0.00 all configs · BAR monotone 0.75→0.60 · T3 local optimum
Detection guarantees — Proposition + binomial P(detect)	✅ Complete — v1.26 · W=40 τ=0.10 · P=1.00 at p₁=0.00 · P=0.95 at p₁=0.05
AgentSpec functional comparison (5 dimensions)	✅ Complete — v1.26 · composable, not competitive · governance collapse detection differentiator
Exp 12: Multi-tool IPI admission control (`compliance/adversarial/exp_agent_multitool.go`)	✅ Complete — v1.27 · 4 tools · 3 phases · BAR A=0.30/B=1.00/C=0.30 · stateful F_anom 24h persistence
Real-LLM IPI demo (`demos/ollama-agent/agent_demo.py`)	✅ Complete — v1.27 · DeepSeek-R1:8b · 5 turns · IPI blocked · cooldown activated
False-denial rate analysis (§False-Denial Rate Analysis)	✅ Complete — v1.27 · 0.00 clean-state (Exp 11) · 0.00 post-attack low-risk (Exp 12 Phase C)
Deployment maturity model (Tier 1/2/3) + PolicyConfig profiles (Low/Medium/High/Critical)	✅ Complete — v1.27 · BAR baseline per profile · migration guide RISK-2.0→RISK-3.0
Exp 13: Bounded coordination window (`compliance/adversarial/exp_coordination_window.go`)	✅ Complete — v1.28 · CW=2N exact linearity · evaluate-then-mutate semantics · k₀=2 per agent · O(N) bound
LLM Agent Integration subsection moved to §Technical Mechanisms	✅ Complete — v1.28 · after §Deterministic Risk Evaluation · composable with IPI prompt filters
Exp 14: OPA vs ACP capability comparison (`compliance/adversarial/exp_opa_benchmark.go`)	✅ Complete — v1.29 · 3 scenarios · stateless engines cannot enforce frequency/cooldown without external state · ACP enforces natively · ~852 ns/op ACP vs ~16,000 ns/op OPA
§Related Work — Formal Verification and Runtime Enforcement (expanded)	✅ Complete — v1.29 · OPA expressiveness boundary · Schneider security automaton alignment · Exp 14 cross-reference
Governance series integration: Papers 3–4 cited in §15; `fernandez2026comp` bib entry	✅ Complete — v1.30
v1.x	Core protocol and reference implementation — active
v2.0	Decentralized ACP (ACP-D) — in design
future	ZK verification, decentralized governance

ACP-SIGN	2.0 ¹	L1
ACP-AGENT	1.0	L1
ACP-CT	1.0	L1
ACP-CAP-REG	1.0	L1
ACP-HP	1.0	L1
ACP-DCMA	1.0	L1
ACP-MESSAGES	1.0	L1
ACP-RISK	3.0	L2
ACP-REV	1.0	L2
ACP-ITA	1.1	L2/L4
ACP-API	1.0	L3
ACP-EXEC	1.0	L3
ACP-LEDGER	1.3	L3
ACP-PROVENANCE	1.0	L3
ACP-POLICY-CTX	1.0	L3
ACP-PSN	1.0	L3
ACP-PAY	1.0	L4
ACP-REP	1.2	L4
ACP-GOV-EVENTS	1.0	L4
ACP-LIA	1.0	L4
ACP-HIST	1.0	L4
ACP-NOTIFY	1.0	L4
ACP-DISC	1.0	L4
ACP-BULK	1.0	L4
ACP-CROSS-ORG	1.0	L4
ACP-REP-PORTABILITY	1.1	L4
ACP-CONF	1.2	—

L1	Core	Identity, capability tokens and execution
L2	Security	Risk scoring, revocation and trust anchors
L3	Verifiable Execution	Execution tokens, ledger and provenance
L4	Governance	Reputation, history and liability
L5	Federation	Decentralized ACP networks

L1	SIGN · AGENT · CT · CAP-REG · HP · DCMA · MESSAGES
L2	L1 + RISK · REV · ITA-1.0
L3	L2 + API · EXEC · LEDGER · PROVENANCE · POLICY-CTX · PSN
L4	L3 + PAY · REP-1.2 · ITA-1.1 · GOV-EVENTS · LIA · HIST · NOTIFY · DISC · BULK · CROSS-ORG · REP-PORTABILITY
L5	L4 + ACP-D · ITA-1.1 BFT quorum

acp-framework-en

Beliebteste

ACP — Agent Control Protocol

Official Website

Paper

Research Series

Why ACP Exists

ACP vs Related Protocols

ACP vs Policy & Auth Systems

ACP as Admission Control

How ACP Works

Constitutional Invariant

Protocol Architecture

Cross-Institution Interaction

Design Principles

Explicit Authority

Deterministic Execution

Verifiable History

Institutional Accountability

Federated Trust

Protocol Components

L1 · Core Execution

L2 · Trust Layer

L3 · Verifiable Execution

L4 · Governance

L5 · Federation

Active Specification Versions

Conformance Levels

Specifications

L1 · Core Execution

L2 · Trust Layer

L3 · Verifiable Execution

L4 · Governance

L5 · Federation

Governance

Repository Structure

Quick Start

Roadmap

License