Dos proyectos de gobernanza de agentes usan las siglas ACS: el Agent Control Standard de OWASP y la Agent Control Specification que usa el Agent Governance Toolkit (AGT) de Microsoft. Una revisión de integración debe empezar por sus versiones exactas, el host que aplica las decisiones y la evidencia que registra lo ocurrido.
Los nombres dejan abiertas cuestiones reales. Una aprobación debe llegar a un host que pueda solicitarla y resolverla. Una entrada de herramienta transformada debe aplicarse a la acción que realmente se ejecuta. Una caída del servicio de decisiones necesita un resultado definido. Esos detalles determinan lo que una integración puede afirmar. Este artículo fija ambos contratos a fecha de 26 de octubre de 2026, presenta una ejecución de las pruebas de referencia del adaptador de host de OWASP y enlaza una comparación versionada. Este artículo forma parte de una serie de investigación en tres partes sobre la autoridad de los agentes, publicada el 26 de octubre de 2026: evidencia de detención, políticas en la memoria del agente y estándares de control de agentes.
Fije los contratos reales
A 26 de octubre de 2026, el árbol publicado de OWASP identifica la versión 0.1.4, con fecha de 16 de octubre. Su espacio de nombres de protocolo y esquema sigue identificando 0.1.0. El registro de cambios recoge requisitos de Trace modificados bajo ese espacio de nombres y pide que las declaraciones de conformidad indiquen la versión o el commit. Por tanto, la versión del handshake deja sin especificar parte del contrato. Historial de versiones fijado.
La documentación actual de Microsoft refleja una estructura modificada. AGT usa un runtime de decisiones de políticas de un proyecto externo (upstream) y un contrato de intercepción independiente, Agent Hooks. El host aporta una instantánea completa, recibe la decisión del runtime y es responsable de aplicarla. Guía actual de ACS en AGT.
El puente de referencia de OWASP fija una revisión anterior de AGT y el Node SDK 0.3.1-beta.0, por lo que su correspondencia debe leerse frente a esa generación. La guía actual de AGT describe tres decisiones normalizadas, allow, deny y transform, con las advertencias y la información de aprobación transmitidas junto a ellas. Un puente que funciona con el contrato anterior necesita nueva evidencia de compatibilidad antes de poder valer para el actual. Dependencia fijada del puente.
| Elemento | OWASP Agent Control Standard | AGT / Agent Control Specification |
|---|---|---|
| Versión | 0.1.4 (16 de octubre de 2026) | Dependencia del motor 0.4.0-alpha.4 |
| Protocolo o manifiesto | Espacio de nombres de protocolo, especificación y esquema 0.1.0 | Manifiesto existente 0.4.0-alpha.1; contrato opcional 0.5.0-alpha.1 |
| Puente de referencia | Fija un commit anterior de AGT y el Node SDK 0.3.1-beta.0 | No aplicable |
Siga la aprobación y los fallos a través del host
OWASP define tipos de decisión y un comportamiento que depende de las capacidades, incluidas la aprobación, el aplazamiento y la modificación. Los requisitos obligatorios de Core conviven con perfiles opcionales. La especificación separa el fallo en la entrega de la decisión de los demás resultados y define un comportamiento negociado ante fallos. Contrato de conformidad fijado.
En el contrato actual de AGT, una denegación puede incluir información de aprobación que resuelve el host, y una transformación exige que el host la valide y la aplique. La decisión del runtime es un paso de ese flujo. Agent Hooks declara su frontera de confianza: el host es de confianza, los controles se ejecutan dentro del proceso y sus ocho puntos de intercepción no prometen una mediación completa. Agent Hooks.
Un registro de integración debe vincular la acción propuesta con la decisión, cualquier aprobación humana, la entrada finalmente enviada y el resultado. Si la entrada cambia después de la aprobación, el registro debe mostrar cómo decide la aplicación si la aprobación sigue siendo válida. Si un host no puede presentar un control obligatorio, su alternativa documentada pasa a formar parte de la evaluación.
| Aspecto | OWASP 0.1.4 | AGT actual |
|---|---|---|
| Decisiones | ALLOW, DENY, ASK y DEFER son obligatorias; MODIFY es recomendable, con un tratamiento definido para los clientes que no pueden aplicarla | allow, deny, transform; warn pasa a ser allow con advertencias; escalate pasa a ser una denegación (deny) que puede levantarse y que incluye información de aprobación |
| Aprobación humana | Los detalles de ASK, el tiempo de espera y la capacidad del aprobador tienen un comportamiento definido | El host es responsable de resolver la aprobación |
| Fallo en la entrega | on_decision_failure negociado; por defecto se continúa con auditoría obligatoria | Los errores del runtime producen deny; el comportamiento en el despliegue depende del host |
| Cobertura | Core más perfiles opcionales autodeclarados | Ocho puntos de intercepción; host de confianza; sin promesa de mediación completa |
Lo que ejecutamos
Descargamos la implementación de referencia de OWASP en el commit 4cf23d4 y ejecutamos sin cambios sus conjuntos de pruebas de validación de decisiones y de comportamiento ante fallos con Bun 1.3.14. Pasaron las 94 pruebas de esos dos archivos (236 aserciones). Cubren modificaciones mal formadas, decisiones caducadas, fallos de entrega, rechazos explícitos y fallos al registrar un evento de auditoría.
Las pruebas hacen distinciones útiles. Una solicitud de aprobación caducada puede tratarse de forma distinta a un servicio de decisiones que nunca respondió. Un rechazo explícito es distinto de un fallo de transporte. Una configuración que permite que la acción continúe sigue teniendo que cumplir su requisito de auditoría. Una sola etiqueta como «fallo cerrado» no puede describir todas esas rutas sin sus condiciones.
Dos archivos de pruebas que dependen del runtime no pudieron cargar su dependencia nativa, que requiere glibc 2.39; nuestro host tiene la 2.35. Conservamos el intento fallido junto a la ejecución correcta. No obtuvimos resultados del motor de políticas en ejecución a partir de esos archivos, y las 94 pruebas superadas no establecen la conformidad completa ni la interoperabilidad.
Los mantenedores de la referencia también declaran carencias en la cobertura de hooks, la firma, la autenticación y la protección frente a ataques de repetición (replay). Forman parte del alcance documentado de la implementación, y cualquier referencia que la use como ejemplo debe mantenerlas visibles. Alcance de la implementación de referencia.
Registre el resultado que respalda la evidencia
Los cambios de Trace en OWASP 0.1.4 añaden una regla útil: correlacionar los identificadores de solicitud y de sesión, y comprobar si existe un evento de fallo de decisión correspondiente antes de considerar aplicada una decisión. Así se separa lo que decidió el servicio de políticas de lo que completó el host.
La comparación de octubre (en inglés) separa los requisitos de las fuentes, las observaciones a nivel de funciones auxiliares y los escenarios que no ejecutamos. Use estos escenarios para un plan de pruebas de integración:
| Escenario | Observación necesaria | Esta revisión |
|---|---|---|
| Llamada a herramienta denegada | El host impide el envío | Comportamiento de las funciones auxiliares y fuentes revisados; ruta nativa en ejecución no probada |
| Aprobación seguida de un cambio en la entrada | La aprobación queda vinculada a la acción realmente enviada | No ejecutado |
| Servicio de decisiones no disponible | Postura elegida, acción resultante, evento de auditoría | Pruebas de las funciones auxiliares del host superadas; ruta en ejecución no probada |
| Decisión caducada | Límite temporal y resultado alternativo | Pruebas de las funciones auxiliares del host superadas |
| Solicitud repetida (replay) | Detección de duplicados y resolución registrada | Falta de protección declarada por el proyecto original; sin prueba en ejecución |
| La transformación no puede aplicarse | Alternativa segura y evidencia | Pruebas de las funciones auxiliares del host superadas |
| Decisión registrada que el host no consigue aplicar | Evidencia conjunta de la decisión y del fallo | Contrato de Trace revisado; escenario no ejecutado |
Cómo trata KLA estas mismas cuestiones
KLA no es una implementación de ninguno de los dos proyectos ACS. A modo de comparación: el KLA Policy Engine devuelve uno de cuatro resultados, allow, warn, require_approval o block, para cada acción gobernada. Cuando la evaluación falla, devuelve su decisión de fallo cerrado (fail-closed), require_approval por defecto, y la validación de paquetes de políticas rechaza una política cuya decisión predeterminada sea de fallo abierto (fail-open). En la ruta de herramientas gobernada, una solicitud de aprobación para una llamada a herramienta registra un hash SHA-256 de los argumentos para los que se emitió, lo que responde al escenario de «aprobación seguida de un cambio en la entrada» descrito arriba.
Las pruebas de este artículo se ejecutaron solo contra la implementación de referencia de OWASP y no contienen ningún resultado de KLA. La guía de controles agénticos de OWASP relaciona con más detalle los controles en tiempo de ejecución con la evidencia.
Preguntas frecuentes
¿Qué diferencia hay entre OWASP ACS y la Agent Control Specification de Microsoft?
Comparten siglas y difieren en el contrato. El Agent Control Standard de OWASP (versión 0.1.4, espacio de nombres de protocolo 0.1.0) define ALLOW, DENY, ASK, DEFER y MODIFY con un comportamiento negociado ante fallos. La Agent Control Specification que usa Microsoft AGT normaliza las decisiones en allow, deny y transform, y confía la gestión de las solicitudes de aprobación y la aplicación de las decisiones a un host de confianza.
¿Qué versión debe indicar una declaración de conformidad de control de agentes?
La versión o el commit. OWASP 0.1.4 cambió los requisitos de Trace sin cambiar el espacio de nombres de protocolo 0.1.0, y su registro de cambios pide que las declaraciones de conformidad indiquen la versión o el commit. En AGT, registre por separado las versiones del motor, del manifiesto y del contrato.
¿Supera sus pruebas la implementación de referencia de OWASP?
El 26 de octubre de 2026, en el commit 4cf23d4, los dos conjuntos de pruebas del adaptador de host que ejecutamos superaron 94 de 94 pruebas. Dos archivos que dependen del runtime no pudieron cargar su dependencia nativa en un host con glibc 2.35. Estos resultados cubren solo el comportamiento de las funciones auxiliares y no establecen la conformidad.
¿Qué significa «fallo cerrado» (fail closed) en un control de agentes?
Depende del fallo. Una aprobación caducada, una solicitud de decisión sin respuesta, un rechazo explícito y un error de transporte pueden exigir comportamientos distintos. Indique para cada uno la clase de fallo, la acción resultante y el evento de auditoría.
Conclusiones clave
Los nombres de los proyectos no establecen la interoperabilidad. Fije las versiones de publicación y de protocolo, siga la aprobación y la transformación a través del host, pruebe cada clase de fallo y compruebe la traza antes de afirmar que se aplica un control. La comparación de octubre ofrece un punto de partida fechado; actualícela cuando cualquiera de los dos proyectos avance.
Las versiones se fijaron el 26 de octubre de 2026. Nuestra ejecución cubrió 94 pruebas de funciones auxiliares del host; no se ejecutó ningún escenario con un host, una aprobación o una traza reales.