Modelo de Gobernanza del Protocolo
ACP es control de admisión para acciones de agentes. Su modelo de gobernanza define una condición matemáticamente precisa que debe cumplirse antes de que cualquier agente tenga permitido mutar el estado del sistema — independientemente de lo que el agente razone, planifique o sea instruido a hacer.
El Invariante Constitucional
Toda ejecución en el entorno ACP está gobernada por un invariante matemático. Si algún componente falla, no ocurre ninguna ejecución y no se permite ningún cambio de estado.
Execute(request) ⇒ ValidIdentity ∧ ValidCapability ∧ ValidDelegationChain ∧ AcceptableRisk
ValidIdentity → pkg/agent · pkg/hp
La firma de identidad Ed25519 del agente es actual, verificable y está criptográficamente vinculada a una raíz institucional. Implementado mediante ACP-AGENT-1.0 y el protocolo de handshake ACP-HP-1.0.
ValidCapability → pkg/ct
El agente posee un token de capacidad firmado que coincide exactamente con el alcance de la operación solicitada, nivel de autonomía y ventana de tiempo. Los tokens son acotados, con límite de tiempo y no transferibles. Implementado mediante ACP-CT-1.0.
ValidDelegationChain → pkg/dcma
La capacidad se rastrea hasta una raíz institucional reconocida: humano → agente → sub-agente → herramienta. Ningún agente puede re-delegar autoridad que él mismo no posee. Implementado mediante ACP-DCMA-1.1.
AcceptableRisk → pkg/risk · pkg/psn
La puntuación de riesgo evaluada de la acción está dentro de los umbrales definidos por el snapshot de política activo actual. Los snapshots de política transicionan atómicamente — cuando la política institucional cambia, todas las verificaciones de admisión posteriores usan los nuevos parámetros de inmediato. Implementado mediante ACP-RISK-1.0 y ACP-PSN-1.0.
Prueba de Ejecución
Cuando se satisfacen las cuatro condiciones, el control de admisión emite un token de ejecución firmado — la prueba criptográfica de que esta acción específica fue autorizada, por quién, bajo qué versión de política, en qué momento.
El token y la cadena completa de eventos se agregan al ledger inmutable de la institución (cadena de hash SHA-256, firmada con Ed25519). Cualquier tercero puede verificar independientemente cualquier evento en la cadena sin confiar en la institución — la matemática habla por sí sola.
Implementado mediante pkg/exec (ACP-EXEC-1.0) y pkg/ledger (ACP-LEDGER-1.3).
Responsabilidad Institucional
En sistemas de agentes distribuidos, debe ser inequívoco quién es responsable cuando algo sale mal. ACP resuelve esto mediante cadenas de delegación criptográficas.
Cuando se genera un agente, recibe una identidad restringida, acotada y con límite de tiempo firmada por su padre. Este patrón continúa hasta llegar a una clave raíz de un operador humano o KMS Empresarial. Por lo tanto, cualquier ejecución válida de ACP puede responder definitivamente: "¿Quién autorizó esta ejecución?"
La raíz institucional que firmó la delegación inicial es plenamente responsable de todos los resultados de la ejecución posterior. No hay ambigüedad — la cadena es públicamente verificable.
Confianza entre Organizaciones
ACP permite a las instituciones aceptar solicitudes de agentes a través de los límites organizacionales sin confiar en los sistemas internos de cada una. Si el Banco A recibe una solicitud de un agente generado por el Banco B, el Banco A no necesita entender la lógica de orquestación del Banco B — solo necesita verificar el invariante de admisión de ACP: que la identidad y capacidades del agente están criptográficamente vinculadas a la raíz institucional del Banco B.
La confianza proviene de la verificación, no de suposiciones conductuales ni acuerdos bilaterales sobre el diseño del agente.
Verificación Formal
El invariante de gobernanza de ACP no solo está especificado — está formalmente verificado con model checking TLC. El módulo tla/ACP_Extended.tla (v1.21) codifica el modelo de ejecución completo incluyendo estado temporal de cooldown por agente, acumulación de denegaciones e integridad de la cadena de delegación.
verificados
verificadas
0 violaciones
Invariantes clave: CooldownEnforced (cooldown activo fuerza DENIED sin importar el risk score), CooldownImpliesThreshold (el cooldown solo existe tras acumulación real de denegaciones), DelegationIntegrity (no hay auto-delegación consecutiva en la cadena), RiskDeterminism (la misma capability+resource siempre produce el mismo risk score). La propiedad de liveness CooldownExpires garantiza que el cooldown no es permanente — verificada con fairness débil sobre el avance del tiempo.
Fuente: tla/ACP_Extended.tla · tla/ACP_Extended.cfg · TLC v1.7.1
Robustez Adversarial
El invariante se valida bajo condiciones adversariales — no solo en el caso base. Cuatro experimentos en compliance/adversarial/ demuestran que el control de admisión de ACP se sostiene bajo patrones de ataque reales.
Exp 1 — Evasión de Cooldown
500 solicitudes alternando riesgo alto/bajo. El cooldown se activa tras exactamente 3 decisiones DENIED reales. 495/500 solicitudes bloqueadas (99%). El patrón de evasión no elude la acumulación.
Exp 2 — Multi-Agente Distribuido
100 agentes coordinados con bajo volumen individual. Aislamiento por agente aplicado — sin interferencia entre agentes. Cada agente es bloqueado de forma independiente tras su propio umbral de denegación.
Exp 3 — Estrés de Backend de Estado
InMemory vs Redis vs Redis pipelined (2 RTTs/solicitud). ~8,000 req/s pipelined. ACP no elimina el costo del estado distribuido — lo hace explícito y medible.
Exp 4 — Replay de Tokens
Replays secuenciales y concurrentes se acumulan vía F_anom Regla 3, escalando RS de 55 (ESCALATED) a 70 (DENIED) tras 3 patrones idénticos. Resistencia al replay acotada: tokens casi idénticos con campos de recurso variados evaden la Regla 3 — limitación documentada, no gap de diseño.