ACP — Agent Control Protocol

Contrôle d'admission pour les actions des agents.

Avant qu'un agent ne modifie l'état du système, ACP répond à quatre questions : Qui est cet agent ? Que sont-ils autorisés à faire ? Cette action est-elle conforme à la politique ? Le résultat peut-il être attribué à une institution responsable ?

Cryptographic identity · Scoped capability tokens · Verifiable delegation chains · Execution proof

Site Web Officiel

https://agentcontrolprotocol.xyz

Article

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

DOI: 10.5281/zenodo.19672575  ·  arXiv: 2603.18829

Série de Recherche

ACP est le fondement publié d'une série de sept articles sur la gouvernance formelle des agents. Chaque article traite d'une couche distincte de la pile de gouvernance.

Logique de la série : Paper 0 prouve quand l'admissibilité peut être garantie → Paper 1 (ACP) construit le protocole → Paper 2 détecte les dérives invisibles à l'application → Paper 3/4 prouve que l'application correcte ≠ allocation équitable et établit l'irréductibilité de l'architecture à quatre couches → Paper 5 (RAM) fournit une fermeture opérationnelle : quand exécuter sous observabilité partielle → Paper 6 opérationnalise RAM en tant que boucle de récupération d'exécution → Paper 7 fournit la première validation empirique de la pile complète sur des agents LangGraph réels.

Pourquoi ACP Existe

Les agents autonomes passent de l'expérimentation à la production. Ils interagissent déjà avec les API, les systèmes d'entreprise, l'infrastructure financière et d'autres agents.

Lorsqu'un agent agit entre organisations, plusieurs questions se posent immédiatement :

• Qui a autorisé l'agent à agir ?
• Quelles capacités l'agent possède-t-il réellement ?
• Quelle politique a autorisé l'action ?
• Qu'a-t-il été exactement exécuté ?
• Cette exécution peut-elle être vérifiée ultérieurement ?
• L'historique complet des interactions peut-il être reconstruit ?

Aujourd'hui, la plupart des systèmes ne peuvent pas répondre à ces questions de manière fiable.

ACP introduit l'infrastructure pour répondre à toutes ces questions.

ACP vs Protocoles Connexes

Plusieurs initiatives abordent la manière dont les agents autonomes interagissent avec les systèmes. La plupart se concentrent sur l'accès aux outils ou la communication. ACP se concentre sur l'autorité, la vérification de l'exécution et la responsabilité institutionnelle.

ACP aborde une couche différente : qui a autorisé l'action, sous quelle politique, et qui est responsable du résultat.

ACP vs Systèmes de Politique et d'Authentification

Les ingénieurs évaluant ACP demandent souvent : « pourquoi ne pas utiliser OPA ? » Ces systèmes sont complémentaires, pas concurrents.

OPA peut être utilisé comme moteur d'évaluation de politiques à l'intérieur d'un système conforme à ACP. ACP ne remplace pas OPA — il ajoute la couche d'identité de l'agent, la chaîne de délégation et la preuve d'exécution qu'OPA ne fournit pas.

¹ ACP (Agent Control Protocol) n'est pas lié à d'autres initiatives partageant le même acronyme.

ACP comme Contrôle d'Admission

Kubernetes utilise un Admission Controller pour intercepter les requêtes API avant qu'elles n'atteignent le cluster — évaluant les politiques, appliquant les quotas, rejetant les opérations non conformes. ACP applique le même modèle aux actions des agents.``` 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

La différence avec Kubernetes : ACP opère à travers les frontières institutionnelles. Un agent de la Banque A peut être admis par la Banque B sans que la Banque B fasse confiance à l'infrastructure interne de la Banque A — seule la preuve cryptographique compte.

---

## Comment fonctionne ACP

ACP traite les interactions des agents comme des **opérations gouvernées**, et non comme de simples demandes.

Chaque interaction passe par six étapes structurées :

1. **Vérification d'identité** — confirmer qui est l'agent (`ACP-AGENT-1.0`, `ACP-HP-1.0`)
2. **Validation des capacités** — confirmer ce que l'agent est autorisé à faire (`ACP-CT-1.0`, `ACP-DCMA-1.0`)
3. **Autorisation de politique** — confirmer que l'action est autorisée selon la politique en vigueur (`ACP-RISK-3.0`, `ACP-PSN-1.0`)
4. **Exécution déterministe** — exécuter exactement ce qui a été autorisé, rien de plus (`ACP-EXEC-1.0`)
5. **Enregistrement vérifiable** — produire une preuve cryptographique de ce qui s'est passé (`ACP-LEDGER-1.3`, `ACP-PROVENANCE-1.0`)
6. **Mise à jour de la confiance** — mettre à jour la réputation et l'état d'attestation en fonction de l'interaction (`ACP-REP-1.2`, `ACP-LIA-1.0`)

Cela permet aux interactions de devenir traçables, auditables et attribuables entre les organisations.

---

## Invariant constitutionnel

L'exécution d'ACP est régie par un seul invariant architectural.```
Execute(request) ⟹
    ValidIdentity  ∧  ValidCapability  ∧  ValidDelegationChain  ∧  AcceptableRisk

| Condition | Signification | |---|---|---| | ValidIdentity | L'agent possède une identité vérifiée et signée | | ValidCapability | L'agent détient un jeton de capacité autorisé | | ValidDelegationChain | Chaque étape de délégation est traçable jusqu'à une racine institutionnelle | | AcceptableRisk | Le score de risque est dans les limites des politiques institutionnelles |

Aucune action d'agent n'est exécutée à moins que les quatre conditions ne soient satisfaites simultanément.

Les couches de protocole existent pour appliquer cet invariant à chaque frontière d'interaction.

Architecture du protocole

L'ACP est organisé en cinq couches de protocole. Chaque couche s'appuie sur la précédente et ajoute une capacité de gouvernance distincte.``` 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 │ └──────────────────────────────────────────────────────────────────┘

→ **Nouveau sur ACP ? Commencez ici :** [docs/admission-flow.md](https://github.com/chelof100/acp-framework-en/blob/HEAD/docs/admission-flow.md) — le guide complet étape par étape pour le contrôle d'admission

→ **Modèle de domaine formel et graphe de dépendances :** [ARCHITECTURE.md](https://github.com/chelof100/acp-framework-en/blob/HEAD/ARCHITECTURE.md)

---

## Interaction entre institutions

ACP est conçu pour les interactions entre systèmes indépendants.
Chaque étape produit un artefact vérifiable qui fait partie de l'enregistrement permanent de l'interaction.```
      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        │
                                          └───────────────────────────┘

Principes de Conception

Autorité Explicite

Toute action d'un agent doit être autorisée par une politique définie. Pas de permissions implicites. Pas d'accès ambiant.

Exécution Déterministe

L'exécution doit correspondre exactement à la commande autorisée. Ce qui est autorisé est ce qui est exécuté — rien de plus.

Historique Vérifiable

Chaque interaction produit des artefacts cryptographiquement vérifiables. L'exécution peut être prouvée a posteriori, sans faire confiance à un seul parti.

Responsabilité Institutionnelle

La responsabilité est toujours attribuable à un acteur identifiable. Les chaînes de délégation sont complètes et traçables jusqu'à une racine institutionnelle.

Confiance Fédérée

Des systèmes indépendants peuvent se vérifier mutuellement sans autorité centrale. La confiance se gagne par un historique d'interactions vérifiable, elle n'est pas supposée.

Composants du Protocole

L1 · Exécution de Base

Identité, capacités, application des politiques et exécution déterministe.

L2 · Couche de Confiance

Évaluation dynamique des risques et gestion de la confiance dans les interactions.

L3 · Exécution Vérifiable

Chaque interaction laisse un enregistrement complet et cryptographiquement vérifiable.

L4 · Gouvernance

Responsabilité à long terme et supervision institutionnelle.

L5 · Fédération

Interopérabilité entre institutions indépendantes.

Versions Actives des Spécifications

Version active actuelle par spécification. Ce tableau est la référence faisant autorité pour « quelle version implémenter ».

¹ ACP-SIGN-1.0 reste actif en tant que base Ed25519. ACP-SIGN-2.0 ajoute l'extension post-quantique (ML-DSA-65). Les deux sont en vigueur jusqu'au déploiement de Dilithium en production.

Les versions remplacées sont archivées dans archive/specs/.

Niveaux de Conformité

Les implémentations peuvent adopter ACP de manière incrémentale, en commençant par L1.

Exigences normatives complètes par niveau :

→ Définition normative de la conformité : spec/governance/ACP-CONF-1.2.md

Spécifications

L1 · Exécution de Base

• ACP-SIGN-1.0 — signature cryptographique, base Ed25519
• ACP-SIGN-2.0 — signature hybride post-quantique (Ed25519 + ML-DSA-65)
• ACP-AGENT-1.0 — identité formelle d'agent A=(ID,C,P,D,L,S)
• ACP-CT-1.0 — structure des Jetons de Capacité, émission et vérification
• ACP-CAP-REG-1.0 — registre canonique des capacités acp:cap:*
• ACP-HP-1.0 — Protocole de Poignée de Main, preuve cryptographique de possession de capacité
• ACP-DCMA-1.0 — délégation multi-saut, non-escalade et révocation transitive
• ACP-MESSAGES-1.0 — format filaire, 5 types de messages normalisés

L2 · Couche de Confiance

• ACP-RISK-2.0 — moteur de risque déterministe, Score de Risque RS (0–100), F_anom + temps de refroidissement
• ACP-RISK-3.0 — application de l'anomalie contextuelle ; Règle 1 clé par PatternKey(agentID, cap, res), élimine le mélange d'état inter-contexte
• ACP-REV-1.0 — protocole de révocation, point de terminaison et CRL
• ACP-ITA-1.0 — Ancre de Confiance Institutionnelle, modèle centralisé
• ACP-ITA-1.1 — Gouvernance de l'Ancre de Confiance, modèle BFT distribué

L3 · Exécution Vérifiable

• ACP-EXEC-1.0 — Jetons d'exécution, usage unique, validité 300s
• ACP-POLICY-CTX-1.0 — état de politique signé au moment de l'exécution
• ACP-PROVENANCE-1.0 — preuve rétrospective de la chaîne de délégation lors de l'exécution
• ACP-LEDGER-1.3 — registre d'audit, à ajout seul, chaîné par hachage, signature institutionnelle obligatoire
• ACP-PSN-1.0 — Nœud de session processus, suivi des sessions d'exécution
• ACP-API-1.0 — API HTTP, tous les points de terminaison institutionnels

L4 · Gouvernance

• ACP-GOV-EVENTS-1.0 — flux d'événements de gouvernance institutionnelle
• ACP-REP-1.2 — extension de réputation, score composite 0.6·ITS + 0.4·ERS
• ACP-LIA-1.0 — chaîne de responsabilité attribuée
• ACP-HIST-1.0 — API d'interrogation de l'historique d'exécution audité
• ACP-PAY-1.0 — extension de capacité financière vérifiable
• ACP-NOTIFY-1.0 — événements et webhooks
• ACP-DISC-1.0 — registre d'agents et résolution
• ACP-BULK-1.0 — exécution par lots de capacités
• ACP-CROSS-ORG-1.0 — interactions inter-institutionnelles entre agents

L5 · Fédération

• ACP-D-1.0 — ACP décentralisé, fédération inter-institutions, quorum BFT

Gouvernance

• ACP-CONF-1.2 — définition normative de la conformité (en vigueur)
• ACP-CHANGELOG — historique des versions

Structure du Dépôt```

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

---

## Démarrage rapide```bash
# 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

Vérification de santé :```bash curl http://localhost:8080/acp/v1/health

ENTRÉE :```json
{
  "acp_version": "1.0",
  "status": "operational",
  "timestamp": 1718920000,
  "components": {
    "policy_engine": "operational",
    "audit_ledger": "operational",
    "agent_registry": "operational",
    "rev_endpoint": "operational"
  }
}

Feuille de route

Licence

Apache 2.0