ACP — Protocolo de Controle de Agentes

Controle de admissão para ações de agentes.

Antes que qualquer agente altere o estado do sistema, o ACP responde a quatro perguntas: Quem é este agente? O que ele está autorizado a fazer? Esta ação está em conformidade com a política? O resultado pode ser atribuído a uma instituição responsável?

Identidade criptográfica · Tokens de capacidade com escopo · Cadeias de delegação verificáveis · Prova de execução

Site Oficial

https://agentcontrolprotocol.xyz

Artigo

Protocolo de Controle de Agentes: Controle de Admissão para Ações de Agentes Marcelo Fernandez (TraslaIA), 2026

DOI: 10.5281/zenodo.19672575  ·  arXiv: 2603.18829

Série de Pesquisa

O ACP é a base publicada de uma série de sete artigos sobre governança formal de agentes. Cada artigo aborda uma camada distinta da pilha de governança.

Lógica da série: O Artigo 0 prova quando a admissibilidade pode ser garantida → O Artigo 1 (ACP) constrói o protocolo → O Artigo 2 detecta desvios invisíveis para a aplicação → O Artigo 3/4 prova que aplicação correta ≠ alocação justa e estabelece a irredutibilidade da arquitetura de quatro camadas → O Artigo 5 (RAM) fornece fechamento operacional: quando executar sob observabilidade parcial → O Artigo 6 operacionaliza o RAM como um Loop de Recuperação em tempo de execução → O Artigo 7 fornece a primeira validação empírica da pilha completa em agentes LangGraph reais.

Por Que o ACP Existe

Agentes autônomos estão saindo da experimentação para a produção. Eles já interagem com APIs, sistemas corporativos, infraestrutura financeira e outros agentes.

Quando um age entre organizações, várias perguntas surgem imediatamente:

• Quem autorizou o agente a agir?
• Que capacidades o agente realmente possui?
• Qual política permitiu a ação?
• O que exatamente foi executado?
• Isso pode ser verificado posteriormente?
• O histórico completo da interação pode ser reconstruído?

Hoje, a maioria dos sistemas não consegue responder a essas perguntas de forma confiável.

O ACP introduz a infraestrutura para responder a todas elas.

ACP vs. Protocolos Relacionados

Diversas iniciativas abordam como agentes autônomos interagem com sistemas. A maioria foca em acesso a ferramentas ou comunicação. O ACP foca em autoridade, verificação de execução e responsabilidade institucional.

O ACP aborda uma camada diferente: quem autorizou a ação, sob qual política e quem é responsável pelo resultado.

ACP vs. Sistemas de Política e Autorização

Engenheiros avaliando o ACP frequentemente perguntam: "por que não usar OPA?" Esses sistemas são complementares, não concorrentes.

A OPA pode ser usada como o motor de avaliação de políticas dentro de um sistema compatível com ACP. O ACP não substitui a OPA — ele adiciona a camada de identidade do agente, cadeia de delegação e prova de execução que a OPA não fornece.

¹ ACP (Agent Control Protocol) não está relacionado a outras iniciativas que compartilham o mesmo acrônimo.

ACP como Controle de Admissão

O Kubernetes usa um Controlador de Admissão para interceptar requisições de API antes que elas cheguem ao cluster — avaliando políticas, aplicando cotas, rejeitando operações não conformes. O ACP aplica o mesmo padrão a ações de agentes.``` 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

A diferença em relação ao Kubernetes: ACP opera através de fronteiras institucionais. Um agente do Banco A pode ser admitido pelo Banco B sem que o Banco B confie na infraestrutura interna do Banco A — apenas a prova criptográfica importa.

---

## Como o ACP Funciona

ACP trata as interações entre agentes como **operações governadas**, não como simples solicitações.

Cada interação passa por seis estágios estruturados:

1. **Verificação de identidade** — confirmar quem é o agente (`ACP-AGENT-1.0`, `ACP-HP-1.0`)
2. **Validação de capacidade** — confirmar o que o agente está autorizado a fazer (`ACP-CT-1.0`, `ACP-DCMA-1.0`)
3. **Autorização de política** — confirmar se a ação é permitida sob a política atual (`ACP-RISK-3.0`, `ACP-PSN-1.0`)
4. **Execução determinística** — executar exatamente o que foi autorizado, nada mais (`ACP-EXEC-1.0`)
5. **Registro verificável** — produzir prova criptográfica do que ocorreu (`ACP-LEDGER-1.3`, `ACP-PROVENANCE-1.0`)
6. **Atualização de confiança** — atualizar o estado de reputação e atestado com base na interação (`ACP-REP-1.2`, `ACP-LIA-1.0`)

Isso permite que as interações se tornem rastreáveis, auditáveis e atribuíveis entre organizações.

---

## Invariante Constitucional

A execução do ACP é governada por um único invariante arquitetônico.```
Execute(request) ⟹
    ValidIdentity  ∧  ValidCapability  ∧  ValidDelegationChain  ∧  AcceptableRisk

Nenhuma ação do agente é executada a menos que todas as quatro condições sejam satisfeitas simultaneamente.

As camadas do protocolo existem para garantir esse invariante em cada limite de interação.

Arquitetura do Protocolo

O ACP é organizado em cinco camadas de protocolo. Cada camada constrói sobre a anterior e adiciona uma capacidade de governança distinta.``` 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 │ └──────────────────────────────────────────────────────────────────┘

→ **Novo no ACP? Comece aqui:** [docs/admission-flow.md](https://github.com/chelof100/acp-framework-en/blob/HEAD/docs/admission-flow.md) — o guia completo passo a passo para a verificação de admissão

→ Modelo formal de domínio e grafo de dependências: [ARCHITECTURE.md](https://github.com/chelof100/acp-framework-en/blob/HEAD/ARCHITECTURE.md)

---

## Interação Entre Instituições

O ACP foi projetado para interações entre sistemas independentes.
Cada etapa produz um artefato verificável que passa a fazer parte do registro permanente de interação.```
      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        │
                                          └───────────────────────────┘

Princípios de Design

Autoridade Explícita

Cada ação do agente deve ser autorizada por uma política definida. Sem permissões implícitas. Sem acesso ambiente.

Execução Determinística

A execução deve corresponder exatamente ao comando autorizado. O que foi autorizado é o que é executado — nada mais.

Histórico Verificável

Cada interação produz artefatos criptograficamente verificáveis. A execução pode ser comprovada posteriormente, sem confiar em nenhuma parte isolada.

Responsabilidade Institucional

A responsabilidade é sempre atribuível a um ator identificável. As cadeias de delegação são completas e rastreáveis até uma raiz institucional.

Confiança Federada

Sistemas independentes podem verificar uns aos outros sem uma autoridade central. A confiança é conquistada através do histórico de interação verificável, não presumida.

Componentes do Protocolo

L1 · Execução Central

Identidade, capacidades, aplicação de políticas e execução determinística.

L2 · Camada de Confiança

Avaliação dinâmica de risco e gerenciamento de confiança de interação.

L3 · Execução Verificável

Cada interação deixa um registro completo e criptograficamente verificável.

L4 · Governança

Responsabilidade de longo prazo e supervisão institucional.

L5 · Federação

Interoperabilidade entre instituições independentes.

Versões Ativas das Especificações

Versão ativa atual por especificação. Esta tabela é a referência autoritativa para "qual versão implementar".

¹ ACP-SIGN-1.0 permanece ativo como base Ed25519. ACP-SIGN-2.0 adiciona a extensão pós-quântica (ML-DSA-65). Ambos estão em vigor até que Dilithium seja implantado em produção.

Versões substituídas estão arquivadas em archive/specs/.

Níveis de Conformidade

Implementações podem adotar o ACP incrementalmente, começando pelo L1.

Requisitos normativos completos por nível:

→ Definição normativa de conformidade: spec/governance/ACP-CONF-1.2.md

Especificações

L1 · Execução Central

• ACP-SIGN-1.0 — assinatura criptográfica, base Ed25519
• ACP-SIGN-2.0 — assinatura híbrida pós-quântica (Ed25519 + ML-DSA-65)
• ACP-AGENT-1.0 — identidade formal do agente A=(ID,C,P,D,L,S)
• ACP-CT-1.0 — estrutura, emissão e verificação do Token de Capacidade
• ACP-CAP-REG-1.0 — registro canônico de capacidades acp:cap:*
• ACP-HP-1.0 — Protocolo de Handshake, prova criptográfica de posse de capacidade
• ACP-DCMA-1.0 — delegação em múltiplos saltos, não escalonamento e revogação transitiva
• ACP-MESSAGES-1.0 — formato de fio, 5 tipos de mensagens normalizados

L2 · Camada de Confiança

• ACP-RISK-2.0 — motor de risco determinístico, Pontuação de Risco RS (0–100), F_anom + cooldown
• ACP-RISK-3.0 — aplicação de anomalias com escopo de contexto; Regra 1 chaveada por PatternKey(agentID, cap, res), elimina a mistura de estados entre contextos
• ACP-REV-1.0 — protocolo de revogação, endpoint e CRL
• ACP-ITA-1.0 — Âncora de Confiança Institucional, modelo centralizado
• ACP-ITA-1.1 — Governança de Âncora de Confiança, modelo BFT distribuído

L3 · Execução Verificável

• ACP-EXEC-1.0 — Tokens de Execução, uso único, validade de 300s
• ACP-POLICY-CTX-1.0 — estado de política assinado no momento da execução
• ACP-PROVENANCE-1.0 — prova retrospectiva da cadeia de delegação na execução
• ACP-LEDGER-1.3 — livro-razão de auditoria, somente anexação, encadeado por hash, assinatura institucional obrigatória
• ACP-PSN-1.0 — Nó de Sessão de Processo, rastreamento de sessão de execução
• ACP-API-1.0 — API HTTP, todos os endpoints institucionais

L4 · Governança

• ACP-GOV-EVENTS-1.0 — fluxo de eventos de governança institucional
• ACP-REP-1.2 — extensão de reputação, pontuação composta 0.6·ITS + 0.4·ERS
• ACP-LIA-1.0 — cadeia de responsabilidade atribuída
• ACP-HIST-1.0 — API de consulta de histórico de execução auditado
• ACP-PAY-1.0 — extensão de capacidade financeira verificável
• ACP-NOTIFY-1.0 — eventos e webhooks
• ACP-DISC-1.0 — registro e resolução de agentes
• ACP-BULK-1.0 — execução em lote de capacidades
• ACP-CROSS-ORG-1.0 — interações interinstitucionais de agentes

L5 · Federação

• ACP-D-1.0 — ACP descentralizado, federação entre instituições, quorum BFT

Governança

• ACP-CONF-1.2 — definição normativa de conformidade (atual)
• ACP-CHANGELOG — histórico de versões

Estrutura do Repositório```

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

## Início Rápido```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

Verificação de saúde:```bash curl http://localhost:8080/acp/v1/health

[No content provided in the INPUT section. Please provide the Markdown text to translate.]```json
{
  "acp_version": "1.0",
  "status": "operational",
  "timestamp": 1718920000,
  "components": {
    "policy_engine": "operational",
    "audit_ledger": "operational",
    "agent_registry": "operational",
    "rev_endpoint": "operational"
  }
}

Roadmap

Licença

Apache 2.0