Implementación de Referencia

El Agent Control Protocol incluye una implementación de referencia en Go de calidad de producción que cubre los cinco niveles de conformidad. Es el artefacto canónico para entender cómo el invariante constitucional se aplica en software real — con criptografía real, cadenas de hash reales y una suite de pruebas de cumplimiento verificable.

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

Qué cubre la implementación

23 Paquetes Go

Un paquete por spec ACP, desde pkg/agent (identidad) pasando por pkg/ledger (registro de auditoría con hash encadenado) hasta pkg/pay (gobernanza de pagos). Cada paquete es importable de forma independiente.

5 Niveles de Conformidad

L1 Core → L2 Security → L3 Full → L4 Extended → L5 Decentralized. Cada nivel construye sobre el anterior, permitiendo adopción parcial comenzando desde la capa de identidad y capacidad.

138 + 5 Vectores de Prueba de Cumplimiento

138 vectores individuales firmados (CORE, DCMA, HP, LEDGER, EXEC, PROV, PCTX, REP, RISK-2.0) más 5 escenarios de secuencia con estado (ACR-1.0): activación de cooldown, detección de patrones F_anom Rule 3, umbrales exactos y saltos de privilegio.

Runner de Conformidad ACR-1.0

Runner Go que valida el comportamiento con estado de ACP-RISK-3.0. Modo library (directo) o modo HTTP (servidor externo). Ejecutá go run . --mode library --dir ../test-vectors/sequence --strict para verificar cualquier implementación de extremo a extremo.

Primitivas Criptográficas

Firmas Ed25519 sobre JSON normalizado con JCS (RFC 8785). Las cadenas de hash usan SHA-256 con base64 (RFC 4648). La firma usa base64url sin padding (RFC 4648 §5).

Estructura de Paquetes

ACP-PROTOCOL-ES/impl/go/
├── pkg/
│   ├── crypto/     # ACP-SIGN-1.0 + ACP-AGENT-1.0 — Firma + identidad (L1)
│   ├── tokens/     # ACP-CT-1.0      — Tokens de capacidad (L1)
│   ├── registry/   # ACP-CAP-REG-1.0 — Registro de capacidades (L1)
│   ├── handshake/  # ACP-HP-1.0      — Protocolo de handshake (L1)
│   ├── delegation/ # ACP-DCMA-1.1    — Cadenas de delegación (L1)
│   ├── provenance/ # ACP-PROVENANCE-1.0 — Procedencia de autoridad (L1)
│   ├── risk/       # ACP-RISK-3.0    — Puntuación de riesgo + F_anom + Cooldown (L2)
│   ├── revocation/ # ACP-REV-1.0     — Protocolo de revocación (L2)
│   ├── reputation/ # ACP-REP-1.2     — Módulo de reputación (L2)
│   ├── execution/  # ACP-EXEC-1.0    — Tokens de ejecución (L3)
│   ├── ledger/     # ACP-LEDGER-1.3  — Ledger de auditoría (L3)
│   ├── psn/        # ACP-PSN-1.0     — Snapshots de política (L3)
│   ├── policyctx/  # ACP-POLICY-CTX-1.1 — Contexto de política (L3)
│   ├── lia/        # ACP-LIA-1.0     — Atribución de responsabilidad (L3)
│   ├── hist/       # ACP-HIST-1.0    — Consultas históricas (L4)
│   ├── govevents/  # ACP-GOV-EVENTS-1.0 — Eventos de gobernanza (L4)
│   ├── notify/     # ACP-NOTIFY-1.0  — Notificaciones (L4)
│   ├── disc/       # ACP-DISC-1.0    — Descubrimiento de servicios (L4)
│   ├── bulk/       # ACP-BULK-1.0    — Operaciones en lote (L4)
│   ├── crossorg/   # ACP-CROSS-ORG-1.1 — Protocolo bilateral tolerante a fallos (L4)
│   ├── pay/        # ACP-PAY-1.0     — Gobernanza de pagos (L4)
│   └── sign2/      # ACP-SIGN-2.0    — Híbrido Ed25519 + ML-DSA-65 real (cloudflare/circl, v1.21)
├── cmd/
│   ├── gen-ledger-vectors/   # Generador de vectores de cumplimiento (LEDGER)
│   └── gen-exec-vectors/     # Generador de vectores de cumplimiento (EXEC)
├── tla/
│   ├── ACP.tla               # Modelo formal base — Safety · RiskDeterminism (v1.17)
│   ├── ACP.cfg               # Configuración TLC para ACP.tla
│   ├── ACP_Extended.tla      # Modelo extendido — estado temporal de cooldown · integridad de delegación (v1.21)
│   └── ACP_Extended.cfg      # Config TLC — 5,684,342 estados · 9 invariantes · 0 violaciones
└── compliance/
    ├── adversarial/          # Evaluación adversarial — Exp 1–4 (evasión de cooldown, multi-agente, backend stress, replay)
    ├── runner/               # Runner de conformidad de secuencia ACR-1.0
    └── test-vectors/         # 73 firmados + 65 sin firma RISK-2.0 + 5 vectores de secuencia

Flujo de Admisión: Cómo ACP Intercepta las Acciones de Agentes

Toda acción de un agente pasa por una verificación de admisión de 6 pasos antes de ejecutarse. La guía docs/admission-flow.md explica cada paso con referencias a la spec, códigos de error y ejemplos en Go y Python.

La Verificación en 6 Pasos

Validación de identidad → Verificación de capacidad → Cadena de delegación → Snapshot de política → Puntuación de riesgo → Emisión de token de ejecución. Cada paso puede resultar en APPROVED, DENIED o ESCALATED.

Patrón ACPAdmissionGuard

Un wrapper drop-in para cualquier acción de agente. Envuelve construcción de token de capacidad, solicitud de admisión y manejo de la decisión. Funciona offline (verificación local de firma) o online (flujo completo con servidor).

Integración con LangChain — @acp_tool

Reemplazo directo del @tool de LangChain. Cada invocación de herramienta es interceptada por ACP antes de ejecutarse — el agente LLM no puede saltarse el control. Retorna APPROVED, lanza ACPDeniedError o ACPEscalatedError.

@acp_tool(guard=guard,
          capability="acp:cap:financial.payment",
          resource="bank://accounts/*")
def transfer_funds(amount: float, ...) -> str:
    # solo se ejecuta si ACP → APPROVED
    return bank.transfer(amount, ...)

Integración con Pydantic AI — deps RunContext

El guard se inyecta como dependencia RunContext — cada @agent.tool lo recibe via ctx.deps. Las acciones DENIED lanzan ModelRetry, que Pydantic AI expone al agente sin revelar estado interno.

@agent.tool
async def transfer_funds(
    ctx: RunContext[ACPAdmissionGuard],
    amount: float, to_account: str,
) -> str:
    result = ctx.deps.check(capability, resource)
    if result.denied:
        raise ModelRetry(f"DENIED: {result.error_code}")
    return bank.transfer(amount, to_account)

Integración con MCP — ACPToolDispatcher

Control de admisión ACP a nivel del dispatcher MCP. Cada solicitud tools/call pasa por ACP antes de ejecutar el handler. Compatible con Claude Desktop y cualquier cliente MCP. Retorna isError: true para acciones DENIED/ESCALATED.

@dispatcher.tool(
    capability="acp:cap:financial.payment",
    resource="bank://accounts/*",
    risk_params=["amount"],
)
def transfer_funds(amount: float, ...) -> str:
    # solo se ejecuta si ACP → APPROVED
    return bank.transfer(amount, ...)

Performance

ACP es compute-cheap but state-sensitive. La evaluación de decisiones incurre en overhead mínimo; el throughput del sistema está acotado por el state backend, no por la lógica del protocolo. Esto es por diseño: la abstracción LedgerQuerier separa claramente ambas capas.

~820 ns
ruta APPROVED
concurrencia base
~88 ns
ruta cooldown
9.5× más rápido — salida temprana Step 2
~920k
req/s · 10 workers
degrada a ~712k en 500
6.7×
diferencia por contención
carga 1-agente vs 100-agentes
Resultados — Intel Core i7-8665U · Go 1.22 · Windows/amd64
Ruta ns/op allocs/op
APPROVED (baseline) 767 5
DENIED 784 5
F_anom todas las reglas (peor caso) 921 5
Cooldown activo (short-circuit Step 2) 102 2

Ejecutar benchmarks: go test ./pkg/risk/... -bench=. -benchmem -benchtime=3s

Ejecutar el Servidor de Referencia

Inicia el servidor ACP en un solo comando — sin necesidad de instalar Go.

docker run -p 8080:8080 \
  -e ACP_INSTITUTION_PUBLIC_KEY=cA4s58S2dEJ-qye6EpJaJKKaVfvPT8mAQf97Vo8TInk \
  ghcr.io/chelof100/acp-server:latest

O explora el código fuente completo — comienza con pkg/ para los paquetes o compliance/test-vectors/ para la suite de pruebas firmadas.

Explorar la Implementación de Referencia de ACP