ACP — Protocollo di Controllo Agenti

Controllo di ammissione per azioni degli agenti.

Prima che un agente modifichi lo stato del sistema, ACP risponde a quattro domande: Chi è questo agente? Cosa è autorizzato a fare? Questa azione è conforme alle policy? L'esito può essere ricondotto a un'istituzione responsabile?

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

Sito Web Ufficiale

https://agentcontrolprotocol.xyz

Articolo

Agent Control Protocol: Controllo di Ammissione per Azioni degli Agenti Marcelo Fernandez (TraslaIA), 2026

DOI: 10.5281/zenodo.19672575  ·  arXiv: 2603.18829

Serie di Ricerca

ACP è il fondamento pubblicato di una serie di sette articoli sulla governance formale degli agenti. Ogni articolo affronta un diverso livello dello stack di governance.

Logica della serie: Il Paper 0 prova quando l'ammissibilità può essere garantita → Il Paper 1 (ACP) costruisce il protocollo → Il Paper 2 rileva la deriva invisibile all'applicazione delle policy → Il Paper 3/4 prova che un'applicazione corretta ≠ allocazione equa e stabilisce l'irriducibilità dell'architettura a quattro livelli → Il Paper 5 (RAM) fornisce chiusura operativa: quando eseguire in condizioni di osservabilità parziale → Il Paper 6 operazionalizza il RAM come un ciclo di recupero a runtime → Il Paper 7 fornisce la prima validazione empirica dell'intero stack su agenti LangGraph reali.

Perché esiste ACP

Gli agenti autonomi stanno passando dalla sperimentazione alla produzione. Interagiscono già con API, sistemi aziendali, infrastrutture finanziarie e altri agenti.

Quando un agente agisce tra organizzazioni, sorgono immediatamente diverse domande:

• Chi ha autorizzato l'agente ad agire?
• Quali capacità possiede effettivamente l'agente?
• Quale policy ha permesso l'azione?
• Cosa è stato eseguito esattamente?
• L'esecuzione può essere verificata in seguito?
• L'intera cronologia delle interazioni può essere ricostruita?

Oggi, la maggior parte dei sistemi non riesce a rispondere a queste domande in modo affidabile.

ACP introduce l'infrastruttura per rispondere a tutte queste domande.

ACP vs Protocolli Correlati

Diverse iniziative affrontano come gli agenti autonomi interagiscono con i sistemi. La maggior parte si concentra sull'accesso agli strumenti o sulla comunicazione. ACP si concentra su autorità, verifica dell'esecuzione e responsabilità istituzionale.

ACP affronta un livello diverso: chi ha autorizzato l'azione, con quale policy e chi è responsabile dell'esito.

ACP vs Sistemi di Policy e Autorizzazione

Gli ingegneri che valutano ACP spesso chiedono: "perché non usare OPA?" Questi sistemi sono complementari, non competitivi.

OPA può essere utilizzato come motore di valutazione delle policy all'interno di un sistema conforme ad ACP. ACP non sostituisce OPA — aggiunge il livello di identità dell'agente, la catena di delega e la prova di esecuzione che OPA non fornisce.

¹ ACP (Agent Control Protocol) non è correlato ad altre iniziative che condividono lo stesso acronimo.

ACP come Controllo di Ammissione

Kubernetes utilizza un Admission Controller per intercettare le richieste API prima che raggiungano il cluster — valutando le policy, applicando le quote, rifiutando operazioni non conformi. ACP applica lo stesso schema alle azioni degli agenti.``` 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 differenza da Kubernetes: ACP opera attraverso i confini istituzionali. Un agente della Banca A può essere ammesso dalla Banca B senza che la Banca B si fidi dell'infrastruttura interna della Banca A — conta solo la prova crittografica.

---

## Come Funziona ACP

ACP tratta le interazioni degli agenti come **operazioni governate**, non semplici richieste.

Ogni interazione passa attraverso sei fasi strutturate:

1. **Verifica dell'identità** — conferma chi è l'agente (`ACP-AGENT-1.0`, `ACP-HP-1.0`)
2. **Validazione delle capacità** — conferma ciò che l'agente è autorizzato a fare (`ACP-CT-1.0`, `ACP-DCMA-1.0`)
3. **Autorizzazione delle politiche** — conferma che l'azione è permessa secondo la politica corrente (`ACP-RISK-3.0`, `ACP-PSN-1.0`)
4. **Esecuzione deterministica** — esegue esattamente ciò che è stato autorizzato, niente di più (`ACP-EXEC-1.0`)
5. **Registrazione verificabile** — produce prova crittografica di ciò che è accaduto (`ACP-LEDGER-1.3`, `ACP-PROVENANCE-1.0`)
6. **Aggiornamento della fiducia** — aggiorna lo stato di reputazione e attestazione basato sull'interazione (`ACP-REP-1.2`, `ACP-LIA-1.0`)

Ciò permette alle interazioni di diventare tracciabili, verificabili e attribuibili tra organizzazioni.

---

## Invariante Costituzionale

L'esecuzione di ACP è governata da un singolo invariante architetturale.```
Execute(request) ⟹
    ValidIdentity  ∧  ValidCapability  ∧  ValidDelegationChain  ∧  AcceptableRisk

Nessuna azione dell'agente viene eseguita a meno che tutte e quattro le condizioni siano soddisfatte simultaneamente.

I livelli del protocollo esistono per imporre questo invariante a ogni confine di interazione.

Architettura del Protocollo

ACP è organizzato in cinque livelli di protocollo. Ogni livello si basa sul precedente e aggiunge una distinta capacità di governance.``` 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 │ └──────────────────────────────────────────────────────────────────┘

→ **Novità su ACP? Inizia qui:** [docs/admission-flow.md](https://github.com/chelof100/acp-framework-en/blob/HEAD/docs/admission-flow.md) — la guida completa passo-passo al controllo di ammissione

→ Modello formale del dominio e grafo delle dipendenze: [ARCHITECTURE.md](https://github.com/chelof100/acp-framework-en/blob/HEAD/ARCHITECTURE.md)

---

## Interazione tra istituzioni

ACP è progettato per interazioni tra sistemi indipendenti.
Ogni passo produce un artefatto verificabile che diventa parte del registro di interazione permanente.```
      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        │
                                          └───────────────────────────┘

Principi di Progettazione

Autorità Esplicita

Ogni azione dell'agente deve essere autorizzata da una policy definita. Nessuna autorizzazione implicita. Nessun accesso ambientale.

Esecuzione Deterministica

L'esecuzione deve corrispondere esattamente al comando autorizzato. Ciò che è stato autorizzato è ciò che viene eseguito — niente di più.

Storia Verificabile

Ogni interazione produce artefatti crittograficamente verificabili. L'esecuzione può essere dimostrata a posteriori, senza fidarsi di una singola parte.

Responsabilità Istituzionale

La responsabilità è sempre attribuibile a un attore identificabile. Le catene di delega sono complete e tracciabili fino a una radice istituzionale.

Fiducia Federata

Sistemi indipendenti possono verificarsi reciprocamente senza un'autorità centrale. La fiducia si guadagna attraverso una storia di interazioni verificabili, non si assume.

Componenti del Protocollo

L1 · Esecuzione Core

Identità, capacità, enforcement delle policy ed esecuzione deterministica.

L2 · Livello di Fiducia

Valutazione dinamica del rischio e gestione della fiducia nelle interazioni.

L3 · Esecuzione Verificabile

Ogni interazione lascia una registrazione completa e crittograficamente verificabile.

L4 · Governance

Responsabilità a lungo termine e supervisione istituzionale.

L5 · Federazione

Interoperabilità tra istituzioni indipendenti.

Versioni Attive delle Specifiche

Versione attuale per specifica. Questa tabella è il riferimento autorevole per "quale versione implementare".

¹ ACP-SIGN-1.0 rimane attiva come baseline Ed25519. ACP-SIGN-2.0 aggiunge l'estensione post-quantum (ML-DSA-65). Entrambe sono in vigore fino a quando Dilithium non sarà distribuito in produzione.

Le versioni sostituite sono archiviate in archive/specs/.

Livelli di Conformità

Le implementazioni possono adottare ACP in modo incrementale, a partire da L1.

Requisiti normativi completi per livello:

→ Definizione normativa di conformità: spec/governance/ACP-CONF-1.2.md

Specifiche

L1 · Esecuzione Core

• ACP-SIGN-1.0 — firma crittografica, baseline Ed25519
• ACP-SIGN-2.0 — firma ibrida post-quantum (Ed25519 + ML-DSA-65)
• ACP-AGENT-1.0 — identità formale dell'agente A=(ID,C,P,D,L,S)
• ACP-CT-1.0 — struttura del Capability Token, emissione e verifica
• ACP-CAP-REG-1.0 — registro canonico delle capacità acp:cap:*
• ACP-HP-1.0 — Handshake Protocol, prova crittografica del possesso di una capacità
• ACP-DCMA-1.0 — delega multi-hop, non escalation e revoca transitiva
• ACP-MESSAGES-1.0 — formato wire, 5 tipi di messaggi normalizzati

L2 · Livello di Fiducia

• ACP-RISK-2.0 — motore di rischio deterministico, Punteggio di Rischio RS (0–100), F_anom + cooldown
• ACP-RISK-3.0 — enforcement delle anomalie con scope di contesto; Regola 1 chiave da PatternKey(agentID, cap, res), elimina il mescolamento di stato tra contesti
• ACP-REV-1.0 — protocollo di revoca, endpoint e CRL
• ACP-ITA-1.0 — Ancoraggio di Fiducia Istituzionale, modello centralizzato
• ACP-ITA-1.1 — Governance dell'Ancoraggio di Fiducia, modello BFT distribuito

L3 · Esecuzione Verificabile

• ACP-EXEC-1.0 — Execution Token, monouso, validità 300 secondi
• ACP-POLICY-CTX-1.0 — stato della policy firmato al momento dell'esecuzione
• ACP-PROVENANCE-1.0 — prova retrospettiva della catena di delega all'esecuzione
• ACP-LEDGER-1.3 — registro di audit, append-only, concatenato con hash, firma istituzionale obbligatoria
• ACP-PSN-1.0 — Process-Session Node, tracciamento delle sessioni di esecuzione
• ACP-API-1.0 — API HTTP, tutti gli endpoint istituzionali

L4 · Governance

• ACP-GOV-EVENTS-1.0 — flusso di eventi di governance istituzionale
• ACP-REP-1.2 — estensione della reputazione, punteggio composito 0.6·ITS + 0.4·ERS
• ACP-LIA-1.0 — catena di responsabilità attribuita
• ACP-HIST-1.0 — API di query della cronologia delle esecuzioni sottoposte a audit
• ACP-PAY-1.0 — estensione della capacità finanziaria verificabile
• ACP-NOTIFY-1.0 — eventi e webhook
• ACP-DISC-1.0 — registro degli agenti e risoluzione
• ACP-BULK-1.0 — esecuzione batch di capacità
• ACP-CROSS-ORG-1.0 — interazioni tra agenti inter-istituzionali

L5 · Federazione

• ACP-D-1.0 — ACP decentralizzato, federazione tra istituzioni, quorum BFT

Governance

• ACP-CONF-1.2 — definizione normativa di conformità (corrente)
• ACP-CHANGELOG — cronologia delle versioni

Struttura del Repository```

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

---

## Guida rapida```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

Controllo di salute:```bash curl http://localhost:8080/acp/v1/health

[Il contenuto Markdown da tradurre non è stato fornito dopo "INPUT:". Si prega di incollare il testo sorgente per procedere con la traduzione.]```json
{
  "acp_version": "1.0",
  "status": "operational",
  "timestamp": 1718920000,
  "components": {
    "policy_engine": "operational",
    "audit_ledger": "operational",
    "agent_registry": "operational",
    "rev_endpoint": "operational"
  }
}

Roadmap

Licenza

Apache 2.0