Control de admisión para acciones de agentes.
Antes de que un agente mute el estado del sistema, ACP responde cuatro preguntas: ¿Quién es este agente? ¿Qué está autorizado a hacer? ¿Esta acción cumple la política vigente? ¿Puede el resultado atribuirse a una institución responsable?
Identidad criptográfica · Tokens de capacidad con scope · Cadenas de delegación verificables · Prueba de ejecución
https://agentcontrolprotocol.xyz
Agent Control Protocol: Admission Control for Agent Actions Marcelo Fernandez (TraslaIA), 2026
DOI: 10.5281/zenodo.19672575 · arXiv: 2603.18829
ACP es la base publicada de una serie de seis papers sobre gobernanza formal de agentes. Cada paper aborda una capa distinta del stack de gobernanza.
| Paper | Título | Repo | Estado |
|---|---|---|---|
| Paper 0 | Fronteras de Decisión Atómica | decision-boundary-model | Zenodo · arXiv:2604.17511 |
| Paper 1 | Agent Control Protocol (ACP) — este repo | acp-framework | Zenodo · arXiv:2603.18829 |
| Paper 2 | De Admisión a Invariantes (IML) | iml-benchmark | Zenodo · arXiv:2604.17517 |
| Paper 3 | Gobernanza Atómica Justa | fair-atomic-governance | Zenodo · arXiv: bajo revisión |
| Paper 4 | Gobernanza Multi-Escala Irreducible | compositional-governance | Zenodo · arXiv: bajo revisión |
| Paper 5 | Modelo de Autoridad Reconstructiva (RAM) | reconstructive-authority-model | Zenodo · arXiv: bajo revisión |
Lógica de la serie: Paper 0 prueba cuándo puede garantizarse admisibilidad → Paper 1 (ACP) construye el protocolo → Paper 2 detecta deriva invisible al enforcement → Paper 3 prueba que enforcement correcto ≠ asignación justa → Paper 4 compone todas las capas y prueba su necesidad conjunta → Paper 5 (RAM) provee cierre operacional: cuándo ejecutar bajo observabilidad parcial.
Los agentes autónomos están pasando de la experimentación a la producción. Ya interactúan con APIs, sistemas empresariales, infraestructura financiera y otros agentes.
Cuando un agente actúa entre organizaciones, surgen inmediatamente varias preguntas:
- ¿Quién autorizó al agente a actuar?
- ¿Qué capacidades tiene realmente el agente?
- ¿Qué política permitió la acción?
- ¿Qué se ejecutó exactamente?
- ¿Puede verificarse esa ejecución después?
- ¿Puede reconstruirse el historial completo de interacción?
Hoy, la mayoría de los sistemas no pueden responder estas preguntas de forma confiable.
ACP introduce la infraestructura para responderlas todas.
Varias iniciativas abordan cómo los agentes autónomos interactúan con los sistemas. La mayoría se centra en acceso a herramientas o comunicación. ACP se centra en autoridad, verificación de ejecución y responsabilidad institucional.
| Protocolo | Enfoque | Límite de scope |
|---|---|---|
| MCP (Model Context Protocol) | Acceso a herramientas para LLMs | Verificación de autoridad, aplicación de políticas, auditabilidad de ejecución |
| A2A (Agent-to-Agent) | Patrones de comunicación entre agentes | Confianza institucional, gobernanza, cadena de responsabilidad |
| OpenAI Agents SDK | Orquestación de herramientas | Autoridad cross-organization, provenance, responsabilidad |
| Agent Client Protocol ¹ | Integración runtime cliente/agente | Gobernanza, cadenas de delegación, historial de ejecución verificable |
| ACP (Agent Control Protocol) | Infraestructura de gobernanza y responsabilidad | — |
ACP aborda una capa diferente: quién autorizó la acción, bajo qué política y quién es responsable del resultado.
Los ingenieros que evalúan ACP frecuentemente preguntan: "¿por qué no usar OPA?" Estos sistemas son complementarios, no competitivos.
| Sistema | Qué hace | Qué agrega ACP |
|---|---|---|
| OPA (Open Policy Agent) | Evalúa políticas a partir de datos y reglas | Identidad criptográfica del agente + cadena de delegación + prueba de ejecución |
| AWS IAM / Azure RBAC | Modelo de permisos estático para recursos cloud | Delegación dinámica agente-a-agente con cadena verificable + ledger |
| OAuth 2.0 + OIDC | Autorización de usuarios y servicios vía tokens | Delegación multi-hop de agentes con no-escalación + responsabilidad institucional |
| SPIFFE / SPIRE | Identidad criptográfica de workloads | ACP construye sobre identidad de workload para agregar scope de capacidades + gobernanza |
| ACP | Control de admisión para acciones de agentes | — |
OPA puede usarse como motor de evaluación de políticas dentro de un sistema ACP-conforme. ACP no reemplaza a OPA — agrega la capa de identidad del agente, la cadena de delegación y la prueba de ejecución que OPA no provee.
¹ ACP (Agent Control Protocol) no está relacionado con otras iniciativas que comparten el mismo acrónimo.
Kubernetes usa un Admission Controller para interceptar solicitudes a la API antes de que lleguen al cluster — evaluando políticas, aplicando cuotas, rechazando operaciones no conformes. ACP aplica el mismo patrón a las acciones de agentes.
intención del agente
↓
[1] Verificación de identidad → pkg/agent + pkg/hp (ACP-AGENT-1.0, ACP-HP-1.0)
↓
[2] Verificación de capacidad → pkg/ct + pkg/dcma (ACP-CT-1.0, ACP-DCMA-1.0)
↓
[3] Verificación de política → pkg/risk + pkg/psn (ACP-RISK-3.0, ACP-PSN-1.0)
↓
[4] ADMIT / DENY / ESCALATE
↓ (si ADMIT)
[5] Token de ejecución → pkg/exec (ACP-EXEC-1.0)
↓
[6] Registro en ledger → pkg/ledger (ACP-LEDGER-1.3)
↓
mutación del estado del sistema
La diferencia con Kubernetes: ACP opera entre fronteras institucionales. Un agente del Banco A puede ser admitido por el Banco B sin que el Banco B confíe en la infraestructura interna del Banco A — solo importa la prueba criptográfica.
ACP trata las interacciones de agentes como operaciones gobernadas, no como simples solicitudes.
Cada interacción pasa por seis etapas estructuradas:
- Verificación de identidad — confirma quién es el agente (
ACP-AGENT-1.0,ACP-HP-1.0) - Validación de capacidad — confirma qué está autorizado a hacer el agente (
ACP-CT-1.0,ACP-DCMA-1.0) - Autorización de política — confirma que la acción está permitida bajo la política actual (
ACP-RISK-3.0,ACP-PSN-1.0) - Ejecución determinística — ejecuta exactamente lo que fue autorizado, nada más (
ACP-EXEC-1.0) - Registro verificable — produce prueba criptográfica de lo ocurrido (
ACP-LEDGER-1.3,ACP-PROVENANCE-1.0) - Actualización de confianza — actualiza el estado de reputación y attestation basado en la interacción (
ACP-REP-1.2,ACP-LIA-1.0)
Esto permite que las interacciones sean trazables, auditables y atribuibles entre organizaciones.
La ejecución de ACP está gobernada por un único invariante arquitectónico.
Execute(request) ⟹
ValidIdentity ∧ ValidCapability ∧ ValidDelegationChain ∧ AcceptableRisk
| Condición | Significado |
|---|---|
ValidIdentity |
El agente tiene una identidad verificada y firmada |
ValidCapability |
El agente posee un Capability Token autorizado |
ValidDelegationChain |
Cada paso de delegación es trazable a una raíz institucional |
AcceptableRisk |
El risk score está dentro de los umbrales de política institucional |
Ninguna acción de agente se ejecuta a menos que las cuatro condiciones se satisfagan simultáneamente.
Las capas del protocolo existen para aplicar este invariante en cada frontera de interacción.
ACP está organizado en cinco capas de protocolo. Cada capa construye sobre la anterior y agrega una capacidad de gobernanza distinta.
ARQUITECTURA DEL PROTOCOLO ACP
┌──────────────────────────────────────┐
│ ACTORES │
│ Humanos · Sistemas · Agentes │
└──────────────────────────────────────┘
│
▼
==================================================================== L1 — EJECUCIÓN CORE
┌──────────────────────────────────────────────────────────────────┐
│ IDENTIDAD Y CAPACIDADES │
│ SIGN · AGENT · CT · CAP-REG │
│ │
│ Identidad del agente, verificación de credenciales y registro │
│ de capacidades │
└──────────────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────────┐
│ POLÍTICA Y AUTORIDAD │
│ HP · DCMA │
│ │
│ Evaluación de política y decisión de autorización │
└──────────────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────────┐
│ EJECUCIÓN │
│ MESSAGES │
│ │
│ Ejecución determinística de comandos y manejo de interacciones │
└──────────────────────────────────────────────────────────────────┘
==================================================================== L2 — CAPA DE CONFIANZA
┌──────────────────────────────────────────────────────────────────┐
│ GESTIÓN DE RIESGO │
│ RISK · REV │
│ │
│ Scoring de riesgo y control de revocación │
└──────────────────────────────────────────────────────────────────┘
┌──────────────────────────────────────────────────────────────────┐
│ CONFIANZA EN INTERACCIONES │
│ ITA │
│ │
│ Attestations de confianza para interacciones │
└──────────────────────────────────────────────────────────────────┘
==================================================================== L3 — EJECUCIÓN VERIFICABLE
┌──────────────────────────────────────────────────────────────────┐
│ REGISTRO DE EJECUCIÓN │
│ EXEC · POLICY-CTX │
│ │
│ Prueba de ejecución y snapshot del contexto de política │
└──────────────────────────────────────────────────────────────────┘
┌──────────────────────────────────────────────────────────────────┐
│ PROVENANCE │
│ PROVENANCE GRAPH │
│ │
│ Linaje de interacción y seguimiento de eventos cross-sistema │
└──────────────────────────────────────────────────────────────────┘
┌──────────────────────────────────────────────────────────────────┐
│ LEDGER │
│ │
│ Almacenamiento resistente a manipulaciones del historial │
│ de ejecución verificable │
└──────────────────────────────────────────────────────────────────┘
==================================================================== L4 — GOBERNANZA
┌──────────────────────────────────────────────────────────────────┐
│ EVENTOS DE GOBERNANZA │
│ GOV-EVENTS │
│ │
│ Seguimiento de gobernanza institucional │
└──────────────────────────────────────────────────────────────────┘
┌──────────────────────────────────────────────────────────────────┐
│ REPUTACIÓN Y RESPONSABILIDAD │
│ REP · LIA │
│ │
│ Acumulación de reputación y atribución de responsabilidad │
└──────────────────────────────────────────────────────────────────┘
┌──────────────────────────────────────────────────────────────────┐
│ REGISTRO HISTÓRICO │
│ HIST │
│ │
│ Historial de interacción verificable a largo plazo │
└──────────────────────────────────────────────────────────────────┘
==================================================================== L5 — FEDERACIÓN
┌──────────────────────────────────────────────────────────────────┐
│ ACP DESCENTRALIZADO │
│ ACP-D │
│ │
│ Federación y verificación cross-institución │
└──────────────────────────────────────────────────────────────────┘
→ ¿Nuevo en ACP? Comienza aquí: docs/admission-flow.md — guía completa paso a paso del control de admisión
→ Modelo de dominio formal y grafo de dependencias: ARCHITECTURE.md
ACP está diseñado para interacciones entre sistemas independientes. Cada paso produce un artefacto verificable que pasa a formar parte del registro permanente de interacción.
INSTITUCIÓN A INSTITUCIÓN B
┌─────────────────────────────┐ ┌─────────────────────────────┐
│ │ │ │
│ AGENTE A │ │ AGENTE B │
│ │ │ │
└──────────────┬──────────────┘ └──────────────┬──────────────┘
│ │
│ 1 solicitud de interacción │
└────────────────────────────────────────►│
▼
┌───────────────────────────┐
│ AUTORIDAD (HP) │
│ evaluación de política │
│ validación de capacidad │
│ verificación de riesgo │
└─────────────┬─────────────┘
│ 2 decisión
▼
┌───────────────────────────┐
│ EJECUCIÓN │
│ acción determinística │
│ ejecución de comando │
└─────────────┬─────────────┘
│ 3 registro de ejecución
▼
┌───────────────────────────┐
│ PROVENANCE │
│ linaje de interacción │
│ atribución cross-org │
└─────────────┬─────────────┘
│ 4 registro verificable
▼
┌───────────────────────────┐
│ LEDGER │
│ hash de ejecución │
│ snapshot de política │
└─────────────┬─────────────┘
│ 5 actualización de confianza
▼
┌───────────────────────────┐
│ REPUTACIÓN │
│ attestation ITA │
│ actualización reputación │
└───────────────────────────┘
Toda acción de agente debe estar autorizada por una política definida. Sin permisos implícitos. Sin acceso ambiental.
La ejecución debe coincidir exactamente con el comando autorizado. Lo que fue autorizado es lo que se ejecuta — nada más.
Toda interacción produce artefactos criptográficamente verificables. La ejecución puede probarse a posteriori, sin confiar en ninguna parte única.
La responsabilidad siempre es atribuible a un actor identificable. Las cadenas de delegación son completas y trazables a una raíz institucional.
Los sistemas independientes pueden verificarse mutuamente sin una autoridad central. La confianza se gana a través del historial de interacción verificable, no se asume.
Identidad, capacidades, aplicación de políticas y ejecución determinística.
| Componente | Rol |
|---|---|
| SIGN | Firma criptográfica — base de todos los objetos del protocolo |
| AGENT | Especificación formal de identidad del agente A=(ID,C,P,D,L,S) |
| CT | Capability Token — estructura, emisión y verificación |
| CAP-REG | Registro canónico de capacidades acp:cap:* |
| HP | Handshake Protocol — prueba criptográfica de posesión de capacidad |
| DCMA | Delegación multi-hop — no-escalación y revocación transitiva |
| MESSAGES | Formato wire — 5 tipos de mensajes normalizados |
Evaluación dinámica de riesgo y gestión de confianza en interacciones.
| Componente | Rol |
|---|---|
| RISK | Motor de riesgo determinístico — Risk Score RS (0–100) |
| REV | Protocolo de revocación — endpoint y CRL |
| ITA | Institutional Trust Anchor — attestations de confianza por interacción |
Cada interacción deja un registro completo y criptográficamente verificable.
| Componente | Rol |
|---|---|
| EXEC | Tokens de ejecución — single-use, 300s de validez |
| POLICY-CTX | Policy Context Snapshot — estado firmado de política en tiempo de ejecución |
| PROVENANCE | Authority Provenance — prueba retrospectiva de la cadena de delegación |
| LEDGER | Audit Ledger — append-only, encadenado por hash |
Responsabilidad a largo plazo y supervisión institucional.
| Componente | Rol |
|---|---|
| GOV-EVENTS | Flujo de eventos de gobernanza — seguimiento institucional |
| REP | Extensión de reputación — score compuesto 0.6·ITS + 0.4·ERS |
| LIA | Liability Traceability — cadena de responsabilidad atribuida |
| HIST | History Query API — historial de ejecución auditado |
Interoperabilidad entre instituciones independientes.
| Componente | Rol |
|---|---|
| ACP-D | ACP Descentralizado — federación cross-institución, quórum BFT |
Versión activa actual por especificación. Esta tabla es la referencia autoritativa para "qué versión implementar".
| Spec | Versión activa | Nivel |
|---|---|---|
| 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 | — |
¹ ACP-SIGN-1.0 permanece activo como baseline Ed25519. ACP-SIGN-2.0 agrega la extensión post-cuántica (ML-DSA-65). Ambas están en vigencia hasta que Dilithium se despliegue en producción.
Las versiones supersedidas están archivadas en archive/specs/.
Las implementaciones pueden adoptar ACP incrementalmente, comenzando desde L1.
| Nivel | Nombre | Qué se obtiene |
|---|---|---|
| L1 | Core | Identidad, capability tokens y ejecución |
| L2 | Security | Scoring de riesgo, revocación y trust anchors |
| L3 | Verifiable Execution | Tokens de ejecución, ledger y provenance |
| L4 | Governance | Reputación, historial y responsabilidad |
| L5 | Federation | Redes ACP descentralizadas |
Requerimientos normativos completos por nivel:
| Nivel | Specs requeridas |
|---|---|
| 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 · quórum BFT ITA-1.1 |
→ Definición normativa de conformidad: spec/governance/ACP-CONF-1.2.md
- ACP-SIGN-1.0 — firma criptográfica, baseline Ed25519
- ACP-SIGN-2.0 — firma híbrida post-cuántica (Ed25519 + ML-DSA-65)
- ACP-AGENT-1.0 — identidad formal del agente
A=(ID,C,P,D,L,S) - ACP-CT-1.0 — estructura, emisión y verificación de Capability Token
- ACP-CAP-REG-1.0 — registro canónico de capacidades
acp:cap:* - ACP-HP-1.0 — Handshake Protocol, prueba criptográfica de posesión de capacidad
- ACP-DCMA-1.0 — delegación multi-hop, no-escalación y revocación transitiva
- ACP-MESSAGES-1.0 — formato wire, 5 tipos de mensajes normalizados
- ACP-RISK-2.0 — motor de riesgo determinístico, Risk Score RS (0–100),
F_anom+ cooldown - ACP-RISK-3.0 — enforcement de anomalías con scope de contexto; Rule 1 indexada por
PatternKey(agentID, cap, res), elimina state-mixing cross-context - ACP-REV-1.0 — protocolo de revocación, endpoint y CRL
- ACP-ITA-1.0 — Institutional Trust Anchor, modelo centralizado
- ACP-ITA-1.1 — Trust Anchor Governance, modelo BFT distribuido
- ACP-EXEC-1.0 — Tokens de ejecución, single-use, 300s de validez
- ACP-POLICY-CTX-1.0 — estado firmado de política en tiempo de ejecución
- ACP-PROVENANCE-1.0 — prueba retrospectiva de la cadena de delegación en ejecución
- ACP-LEDGER-1.3 — audit ledger, append-only, encadenado por hash, firma institucional obligatoria
- ACP-PSN-1.0 — Process-Session Node, seguimiento de sesión de ejecución
- ACP-API-1.0 — API HTTP, todos los endpoints institucionales
- ACP-GOV-EVENTS-1.0 — flujo de eventos de gobernanza institucional
- ACP-REP-1.2 — extensión de reputación, score compuesto
0.6·ITS + 0.4·ERS - ACP-LIA-1.0 — cadena de responsabilidad atribuida
- ACP-HIST-1.0 — API de consulta de historial de ejecución auditado
- ACP-PAY-1.0 — extensión de capacidad financiera verificable
- ACP-NOTIFY-1.0 — eventos y webhooks
- ACP-DISC-1.0 — registro y resolución de agentes
- ACP-BULK-1.0 — ejecución de capacidades en lote
- ACP-CROSS-ORG-1.0 — interacciones de agentes inter-institucionales
- ACP-D-1.0 — ACP descentralizado, federación cross-institución, quórum BFT
- ACP-CONF-1.2 — definición normativa de conformidad (actual)
- ACP-CHANGELOG — historial de versiones
acp-framework/
├── spec/
│ ├── core/ ← L1: identidad, capacidad, delegación
│ ├── security/ ← L2: confianza, riesgo, revocación
│ ├── operations/ ← L3–L4: ejecución, ledger, gobernanza
│ ├── governance/ ← conformidad, eventos, proceso
│ └── decentralized/ ← L5: ACP-D
├── openapi/
│ └── acp-api-1.0.yaml ← spec OpenAPI 3.1.0 para todos los endpoints ACP-API-1.0
├── compliance/
│ ├── ACP-TS-1.1.md ← especificación del formato de vectores de prueba
│ ├── test-vectors/ ← vectores de conformidad single-shot (CORE · DCMA · HP · LEDGER · EXEC · RISK-2.0)
│ │ └── sequence/ ← vectores de secuencia stateful (ACR-1.0, 5 escenarios)
│ ├── adversarial/ ← evaluación adversarial (Exp 1–12: evasión de cooldown, multi-agente, backend stress, token replay, deviation collapse, sensibilidad de umbrales, IPI multi-herramienta)
│ └── runner/ ← compliance runner ACR-1.0 (modo library + modo HTTP)
├── tla/
│ ├── ACP.tla ← modelo formal base — Safety · LedgerAppendOnly · RiskDeterminism (v1.17)
│ ├── ACP.cfg ← configuración TLC para ACP.tla
│ ├── ACP_Extended.tla ← modelo extendido — F_anom · cooldown · liveness · 11 invariantes + 4 temporales (v1.25)
│ ├── ACP_Extended.cfg ← config single-agent — 5,684,342 estados · 3,147,864 distintos · profundidad 15 · 0 violaciones
│ └── ACP_Extended_2agents.cfg ← config two-agent — 4,294,930,695 estados distintos · LEDGER_BOUND=11 · 11 invariantes · 0 violaciones
├── archive/
│ └── specs/ ← versiones de especificación supersedidas (referencia histórica)
├── impl/
│ └── go/ ← implementación de referencia
├── ARCHITECTURE.md ← modelo de dominio formal, grafo de dependencias
├── CHANGELOG.md
└── README.md
# Opción 1: Go reference server
cd impl/go
docker compose up
# Opción 6: ACR-1.0 sequence compliance runner — valida comportamiento stateful de ACP-RISK-3.0
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
# Opción 5: Demo multi-org — Org-A emite política+reputación firmada, Org-B valida independientemente
cd examples/multi-org-demo
docker compose up
# Org-A: http://localhost:8081 | Org-B: http://localhost:8082
# Opción 2: Python SDK — patrón central de admission control (sin servidor requerido)
cd impl/python
pip install -e .
python examples/admission_control_demo.py
# Opción 3: Python SDK — integración LangChain (decorador @acp_tool)
cd impl/python
pip install -e .
python examples/langchain_agent_demo.py
# Opción 4: LangChain + agente LLM real
pip install langchain langchain-openai
export OPENAI_API_KEY=sk-...
python examples/langchain_agent_demo.py --with-llm
# Opción 7: Demo IPI con LLM real (Ollama + DeepSeek-R1:8b) — ACP bloquea fund_transfer inducido por IPI
# Requiere: ollama serve && ollama pull deepseek-r1:8b
cd demos/ollama-agent
python agent_demo.py
# ACP deniega todo fund_transfer inducido por IPI (RS=80); cooldown activa tras 3 denegacionesHealth 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"
}
}| Ítem | Estado |
|---|---|
| ACP-CONF-1.2 | ✅ Completo — única fuente normativa de conformidad |
| ACP-LEDGER-1.3 | ✅ Completo — sig normativamente obligatorio |
OpenAPI spec (openapi/acp-api-1.0.yaml) |
✅ Completo — OpenAPI 3.1.0, todos los endpoints ACP-API-1.0 |
| Vectores de prueba de conformidad (CORE · DCMA · HP · LEDGER · EXEC · PROV · PCTX · REP · RISK-2.0) | ✅ Completo — 73 firmados + 65 RISK-2.0 sin firmar |
| Implementación de referencia — 23 paquetes Go (L1–L4) | ✅ Completo — impl/go/pkg/ cubre todos los niveles de conformidad |
pkg/psn policy snapshot |
✅ Completo — transiciones atómicas, único snapshot ACTIVE |
Python SDK — ACPAdmissionGuard + @acp_tool (LangChain) |
✅ Completo — impl/python/ |
ACP-RISK-2.0 — F_anom + Cooldown + pkg/risk |
✅ Completo — determinístico, sub-µs, 65 vectores |
ACP-RISK-3.0 — Rule 1 context-scoped (pkg/risk/engine.go) |
✅ Completo — v1.22 · CountPattern(ctxKey, 60s) reemplaza CountRequests(agentID) · state-mixing cross-context eliminado |
Demo payment-agent (examples/payment-agent/) |
✅ Completo — v1.16 |
| ACP-SIGN-2.0 — Híbrido post-cuántico (Ed25519 + ML-DSA-65) | ✅ Completo — spec v1.16; ML-DSA-65 real vía cloudflare/circl pkg/sign2/ v1.20 |
ACR-1.0 sequence compliance runner (compliance/runner/) |
✅ Completo — v1.17 · modo library + HTTP · 5/5 PASS |
Vectores de secuencia (compliance/test-vectors/sequence/) |
✅ Completo — v1.17 · 5 escenarios stateful |
Modelo TLA+ base (tla/ACP.tla) |
✅ Completo — v1.17 · 3 invariantes · 0 violaciones |
Modelo TLA+ extendido (tla/ACP_Extended.tla) |
✅ Completo — v1.28 · 11 invariantes + 4 propiedades temporales · single-agent: 5,684,342 estados · two-agent LB=11: 4,294,930,695 estados distintos · 0 violaciones |
Evaluación adversarial (compliance/adversarial/) |
✅ Completo — v1.29 · 14 experimentos · números reales de benchmark (N=5 corridas, media±std) |
Redis pipelining (compliance/adversarial/redis_pipelined.go) |
✅ Completo — v1.20 · 2 RTTs/request · ~1.8× speedup |
ML-DSA-65 benchmarks (pkg/sign2/sign2_bench_test.go) |
✅ Completo — 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) |
✅ Completo — v1.21 · baseline stateless sin estado histórico para comparación directa |
Experimento 5: stateless vs. stateful (pkg/risk/stateless_comparison_test.go) |
✅ Completo — v1.21 · 500 req · stateless 500/500 vs ACP 2/500 (0.4%) · latencia de detección 11 acciones |
Experimento 6: vulnerabilidad state-mixing (pkg/risk/statemixing_test.go) |
✅ Completo — v1.21 · contaminación cross-context Rule 1 · RS +20 · ESCALATED→DENIED tras 11 data.read |
| Análisis state-mixing (paper §State-Mixing Vulnerability) | ✅ Completo — v1.21 · caracterización formal · números Exp 6 · camino de mitigación ACP-RISK-3.0 |
Fix state-mixing (Exp 7, pkg/risk/statemixing_fix_test.go) |
✅ Completo — v1.22 · RISK-3.0 · 3 escenarios · clean RS=50 ESCALATED · contaminado RS=50 ESCALATED · burst mismo-contexto RS=85 DENIED |
Deviation collapse (Exp 9, compliance/adversarial/exp_deviation_collapse.go) |
✅ Completo — v1.23 · 3 fases: baseline BAR=0.70 → collapse BAR=0.00 → counterfactual BAR=1.00 |
| Phase D drift simulation (extensión Exp 9) | ✅ Completo — v1.25 · 5 batches × 20 casos · 0%→80% sanitización · ΔBAR early-warning dispara en batch 2 (3 batches antes del colapso) |
pkg/barmonitor — BAR-Monitor con detección de tendencia ΔBAR |
✅ Completo — v1.24 · 18 tests · AlertThreshold + AlertTrend · ring buffer thread-safe |
API EvaluateCounterfactual (impl/go/pkg/risk/counterfactual.go) |
✅ Completo — v1.24 · 14 tests · 3 factories (estructural/conductual/temporal) · fail-closed |
TLA+ FailureConditionPreservation + NoDegenerateAdmissibility (11 invariantes) |
✅ Completo — v1.27 · 0 violaciones · 4,294,930,695 estados distintos (two-agent LB=11, 10.5h) |
Endpoint HTTP POST /acp/v1/counterfactual (impl/go/cmd/acp-server/) |
✅ Completo — v1.25 · 7 tests de integración · mutaciones estructurales + conductuales vía HTTP |
| Modelo formal de adversario A=(K,S,B) + taxonomía de experimentos (Exp 1–14) | ✅ Completo — v1.29 · black-box / formula-aware / full-state · todos los experimentos mapeados |
| Análisis de sensibilidad de umbrales (Exp 11, 5 configs ±10 pts) | ✅ Completo — v1.26 · tasa de falsa denegación 0.00 en todas · BAR monótono 0.75→0.60 · T3 óptimo local |
| Garantías de detección — Proposición + P(detectar) binomial | ✅ Completo — v1.26 · W=40 τ=0.10 · P=1.00 en p₁=0.00 · P=0.95 en p₁=0.05 |
| Comparación funcional con AgentSpec (5 dimensiones) | ✅ Completo — v1.26 · composable, no competitivo · detección de governance collapse como diferenciador |
Exp 12: control de admisión IPI multi-herramienta (compliance/adversarial/exp_agent_multitool.go) |
✅ Completo — v1.27 · 4 herramientas · 3 fases · BAR A=0.30/B=1.00/C=0.30 · persistencia F_anom 24h |
Demo IPI con LLM real (demos/ollama-agent/agent_demo.py) |
✅ Completo — v1.27 · DeepSeek-R1:8b · 5 turnos · IPI bloqueada · cooldown activado |
| Análisis de tasa de falsa denegación (§False-Denial Rate Analysis) | ✅ Completo — v1.27 · 0.00 estado limpio (Exp 11) · 0.00 post-ataque bajo riesgo (Exp 12 Fase C) |
| Modelo de madurez de despliegue (Tier 1/2/3) + perfiles PolicyConfig (Low/Medium/High/Critical) | ✅ Completo — v1.27 · BAR baseline por perfil · guía de migración RISK-2.0→RISK-3.0 |
Exp 13: Ventana de coordinación acotada (compliance/adversarial/exp_coordination_window.go) |
✅ Completo — v1.28 · CW=2N linealidad exacta · semántica evaluate-then-mutate · k₀=2 por agente · cota O(N) |
| Sección LLM Agent Integration movida a §Technical Mechanisms | ✅ Completo — v1.28 · después de §Deterministic Risk Evaluation · composable con filtros IPI |
Exp 14: Comparación de capacidad OPA vs ACP (compliance/adversarial/exp_opa_benchmark.go) |
✅ Completo — v1.29 · 3 escenarios · motores stateless no pueden aplicar frecuencia/cooldown sin estado externo · ACP aplica de forma nativa · ~852 ns/op ACP vs ~16,000 ns/op OPA |
| §Related Work — Verificación Formal y Aplicación en Runtime (ampliado) | ✅ Completo — v1.29 · límite de expresividad OPA · alineación con autómata de seguridad de Schneider · referencia cruzada Exp 14 |
Integración serie de gobernanza: Papers 3–4 citados en §15; entrada bib fernandez2026comp |
✅ Completo — v1.30 |
| Modelo de confianza ITA (paper §Trust Model and Failure Modes) | ✅ Completo — v1.20 · bootstrap / compromise window / revocation authority — claims semi-formales |
TypeScript SDK (impl/typescript/) |
✅ Completo — v1.4.0 · zero-deps · 68 tests |
Rust SDK (impl/rust/) |
✅ Completo — v1.4.0 · ed25519-dalek v2 · 43 tests |
| v1.x | Protocolo core e implementación de referencia — activo |
| v2.0 | ACP Descentralizado (ACP-D) — en diseño |
| futuro | Verificación ZK, gobernanza descentralizada |
Apache 2.0