OWASP Agent Control Standard (ACS): control de agentes de IA en tiempo de ejecución

Del generador de respuestas al actor

Las aplicaciones LLM clásicas generan texto que una persona lee antes de que ocurra nada. Los agentes de IA, en cambio, planifican de forma autónoma, invocan herramientas, escriben en una memoria a largo plazo y lanzan subagentes. Cada uno de estos pasos puede modificar datos o sacarlos al exterior. Por eso, la pregunta de control es: «¿Puede producirse ahora exactamente esta acción, con exactamente estos argumentos, en esta sesión?». Solo puede responderse en tiempo de ejecución, entre la decisión del modelo y su ejecución por parte del framework.

Los prompts de sistema no son controles

Muchos despliegues confían en instrucciones del prompt de sistema como «no borrar datos de producción». Esas frases son peticiones a un sistema probabilístico, no reglas que se hagan cumplir. La página del proyecto ACS arranca precisamente así su argumentación: los prompts de sistema no son controles, los mejores modelos no cubren los casos límite ni las entradas adversariales y los guardrails propietarios crean dependencia del proveedor.

Fabricantes e investigadores lo confirman. OpenAI escribió el 22 de diciembre de 2025 que la inyección de prompts (prompt injection) es «unlikely to ever be fully 'solved'». En el estudio «The Attacker Moves Second» (arXiv, 10 de octubre de 2025), ataques adaptativos superaron doce defensas recientes, en la mayoría de los casos con tasas de éxito superiores al 90 %, aunque, en su mayoría, habían comunicado inicialmente valores cercanos a cero. La robustez del modelo reduce el riesgo, pero no lo elimina. Hace falta una instancia de control independiente, fuera del modelo.

Lethal trifecta y Agents Rule of Two

Simon Willison describió el 16 de junio de 2025 la «lethal trifecta»: un agente que tiene acceso a datos privados, está expuesto a contenido no fiable y puede comunicarse con el exterior puede ser inducido, mediante prompt injection, a exfiltrar datos. Meta lo amplió el 31 de octubre de 2025 con la «Agents Rule of Two»: dentro de una sesión, un agente debe combinar como máximo dos de tres propiedades: procesar entradas no fiables; acceder a sistemas sensibles o datos privados; cambiar el estado o comunicarse con el exterior. Si necesita las tres, se requiere como mínimo supervisión, por ejemplo mediante aprobación humana. Meta subraya que la regla complementa el principio de mínimo privilegio y no lo sustituye.

Valoración de VamiSec: ambos modelos describen propiedades de una sesión, no de un modelo. Solo pueden hacerse cumplir si una instancia ve cada acción y el historial previo de la sesión. Ese punto de control es el que estandariza el OWASP Agent Control Standard (ACS). Para reconocer entradas no fiables se necesita el perfil opcional acs-provenance; ACS-Core por sí solo no aporta datos de procedencia.

Incidentes documentados y qué habría limitado el control en tiempo de ejecución

Por qué el control debe situarse en tiempo de ejecución

La selección del modelo, el endurecimiento de prompts y el red teaming antes de la puesta en producción siguen siendo necesarios, pero no dicen qué hace un agente en una sesión concreta. El control en tiempo de ejecución los complementa: actúa antes de la acción, evalúa el contexto de toda la sesión y deja una pista de auditoría reconstruible. El OWASP Top 10 for Agentic Applications 2026 recomienda para ASI02 (Tool Misuse and Exploitation) un middleware previo de aplicación de políticas, un «Intent Gate» que revisa la intención y los argumentos antes de la ejecución. ACS no se menciona ahí, pero aporta (valoración de VamiSec) un contrato de protocolo abierto precisamente para este punto de control. Las políticas siguen siendo responsabilidad suya.

Con más precisión: el Agent Control Standard (ACS) es una especificación del OWASP GenAI Security Project que define en qué puntos de control (hooks) un agente de IA somete sus pasos a una instancia de políticas externa y cómo responde esta con una decisión (disposition). El formato es JSON-RPC 2.0 con un campo propio acs_version, transportado por HTTP(S) o stdio. La versión actual es la especificación v0.1.0, publicada como release 0.1.2 (tag del 21 de septiembre de 2026). ACS define el contrato entre agente y Guardian, no las políticas: qué está permitido lo sigue decidiendo su organización.

Las partes

Un principio de diseño sostiene la arquitectura: el modelo de lenguaje no debe saber nada de los hooks. Es el framework quien los dispara, y los datos de procedencia (provenance) se establecen fuera de la ruta de salida del modelo. Según nuestra lectura, así un modelo manipulado no debería poder ver ni influir en el punto de control.

Tres pilares: Instrument, Trace, Inspect

ACS-Core y siete perfiles

La conformidad tiene una estructura modular. ACS-Core es la base obligatoria; sobre ella se apoyan seis perfiles opcionales que un despliegue declara en el handshake. No hay niveles numerados, solo nombres de perfil que se combinan de forma independiente. La única dependencia: acs-inspect-dynamic amplía acs-inspect.

Lo que garantiza ACS-Core lo formula la especificación con sobriedad: el canal está autenticado y el Observed Agent cumple las decisiones. No se garantiza que las políticas sean estrictas: un Guardian permisivo es conforme, solo que permisivo. La evidencia de manipulación de la cadena de auditoría, también frente a un Guardian comprometido, solo la aportan acs-crypto y acs-audit, porque la base HMAC es un procedimiento simétrico. Las combinaciones de ejemplo de la especificación van desde una integración mínima en un IDE solo con acs-core hasta un despliegue de alta garantía (high assurance) con los siete perfiles.

El modelo de tiers de la página del proyecto: capas de arquitectura, no niveles

1. 1
   Tier 1 · Platform layer

   Los frameworks de agentes proporcionan hooks de middleware estandarizados: aquí nace el punto de control.

2. 2
   Tier 2 · Enforcement layer

   Un componente de código abierto lee políticas declarativas y devuelve decisiones a través de esos hooks.

3. 3
   Tier 3 · Enterprise layer

   Clasificadores propios y lógica específica del dominio se acoplan tras la misma interfaz.

Esta imagen describe quién aporta cada parte, no lo conforme que es un despliegue. Para las afirmaciones de conformidad solo cuentan los perfiles. Aun así, resulta útil para su planificación de arquitectura: separa la cuestión de qué plataforma proporciona los hooks de la de quién opera y mantiene las políticas.

De la observación al control

El trabajo comenzó el 11 de mayo de 2025 como «Agent Observability Standard» (AOS) en el entorno de GitHub de Zenity y pasó en junio de 2025 a la organización OWASP, donde AOS figuraba como «OWASP other project». En mayo y junio de 2025, la capa de protocolo se denominó temporalmente «ASOP» (Agent Security & Observability Protocol), antes de volver a llamarse AOS. Tras una fase con solo commits aislados a partir de mediados de 2025, el 10 de abril de 2026 llegó el cambio de nombre a Agent Control Standard. El nuevo nombre marca el paso de contenido: de la mera observación a la aplicación de políticas (enforcement). Después, ACS funcionó brevemente como proyecto independiente fuera de OWASP y regresó en septiembre de 2026, esta vez al OWASP GenAI Security Project.

Estado: Incubator y public preview

ACS es un proyecto del OWASP GenAI Security Project y está adscrito allí a la Agentic Security Initiative. En sus propios metadatos de OWASP Nest declara el nivel 2, que en el esquema de Nest corresponde a la fase «Incubator»; con ello no queda acreditada una clasificación por parte de un órgano de OWASP. El Project Lead califica públicamente el estado como «public preview» y recomienda expresamente cautela a los implementadores. ACS no es un estándar ISO, IETF ni W3C, ni tampoco una norma armonizada. La fase temprana se aprecia también en lo formal: no hay GitHub Releases, solo tags; la prosa de la especificación y los esquemas cambiaron entre v0.1.1 y v0.1.2 sin que se incrementara la versión de la especificación v0.1.0.

¿Quién dirige el proyecto?

Según GOVERNANCE.md, Michael Bargury y Ory Segal crearon ACS; ambos siguen siendo líderes del proyecto. El Project Lead es Rock Lambros. En aras de la transparencia: Bargury es CTO y cofundador de Zenity, Zenity presenta a Lambros como «Director of AI Standards and Governance» y los primeros commits de AOS proceden mayoritariamente del entorno de Zenity. Los workstreams (Coding Agents, Development (SDK), Identity, Outreach y Spec) están dirigidos por personas de varias organizaciones. La página del proyecto describe ACS como neutral respecto a los fabricantes y gobernado por la comunidad; se trata de una autodescripción. Nuestra valoración: un proyecto OWASP con una fuerte impronta de Zenity en su fundación y su dirección.

Las decisiones pasan por un filtro de aceptación. Solo los issues con la etiqueta status:accepted entran en el backlog; los cambios de comportamiento, de texto normativo o de código requieren un issue aceptado, los cambios en la especificación empiezan como GitHub Discussion y los commits exigen un DCO sign-off. El desarrollo se realiza en la rama integration. Solo cuando el Project Lead promueve los cambios a main se vuelven a publicar el sitio web y las URI de los esquemas. A 3 de octubre de 2026, main no se ha vuelto a promover desde el 10 de septiembre de 2026, por lo que los cambios en integration aún no están publicados.

Licencia: qué puede reutilizar

Hoja de ruta: lo que está documentado

El próximo release de la especificación, v0.2.0, apunta a marzo de 2027; no hay fecha fijada para la v1.0. Para v0.2 están previstos, entre otros, streaming e interrupción, ASK recursivo y quórum, aislamiento multi-tenant, el binding de Cedar, la federación de AgBOM a través de peers A2A y el wrapping de A2A. El objetivo en curso desde el kick-off del 10 de septiembre de 2026: en un plazo de 90 días, una implementación de referencia del Guardian operativa, con un benchmark de interoperabilidad frente al Agent Governance Toolkit de Microsoft, en manos de evaluadores externos. Está por ver si se logra antes de principios de diciembre de 2026. También sigue abierto el PR #21, que pretende redefinir el alcance obligatorio de ACS-Core. Los esbozos de versiones divergentes publicados en blogs no constituyen una hoja de ruta oficial.

En el protocolo, los hooks llevan el prefijo steps/, por ejemplo steps/toolCallRequest. Además existen métodos que no son hooks nativos steps/*: agbom/snapshot y agbom/changed para el inventario, la sonda de disponibilidad (liveness probe) system/ping, el handshake handshake/hello y el namespace protocols/MCP/* para mensajes MCP encapsulados (wrapped). La página de hooks de la especificación cuenta 19 hooks más dos métodos AgBOM más ping como 22 métodos; el paquete de esquemas comprende en total 44 esquemas JSON. Algunos textos del proyecto (README, docs/acs.md) siguen mencionando 16 hooks de ciclo de vida: es el recuento sin los tres hooks de skills.

El mínimo de ACS-Core: seis hooks

ACS-Core exige al menos seis hooks: sessionStart, userMessage o agentTrigger, toolCallRequest, toolCallResult, agentResponse y sessionEnd. Todos los demás debería implementarlos un framework siempre que pueda observar el evento correspondiente; se negocian en el handshake. Para su evaluación de productos, esto significa que la afirmación «compatible con ACS» no revela todavía si las escrituras en memoria, los subagentes o los skills llegan siquiera al Guardian.

La trampa de methods_evaluated

En el handshake, el Observed Agent comunica qué métodos implementa (methods_implemented). El Guardian responde con la lista de métodos que realmente evalúa (methods_evaluated). Si el agente envía un hook que no figura en ella, debe tratarlo como ALLOW-by-default: en el mejor de los casos, el paso se registra, pero no se revisa. La única implementación de referencia, por ejemplo, solo evalúa steps/toolCallRequest y steps/toolCallResult, es decir, dos de 19 hooks.

toolCallRequest: el punto central de aplicación

steps/toolCallRequest es el único hook para el que la especificación prevé expresamente las cinco dispositions; aquí es también donde actúan los paradigmas de control. Hay una regla MUST central: los frameworks deben disparar toolCallRequest para cada acción que abandone el contexto de razonamiento del agente, aunque el framework no la gestione internamente como herramienta (tool). Esto abarca los accesos de lectura y escritura al sistema de archivos, las peticiones de red, los inicios de procesos y los comandos de shell. Lo que eluda este hook no lo ve ninguna política.

Son obligatorios en el payload tool.name y arguments, y cada valor de argumento puede llevar su propia provenance. Opcionalmente se añaden una capability abstracta, como filesystem.delete o network.egress, el raw_command y un intent. Así, las políticas pueden evaluar qué provoca una acción en lugar de qué programa la ejecuta.

Hooks con un efecto protector especial

• memoryStore es el sumidero estándar para la influencia entre sesiones y, según la especificación, el punto de actuación frente al envenenamiento de memoria (cf. ASI06: Memory & Context Poisoning).
• preCompact y postCompact protegen la compactación: el resumen debe llevar origin agent_generated y heredar la procedencia de todas las entradas compactadas, para que el contenido no fiable no quede blanqueado.
• subagentStart permite al Guardian denegar el inicio de un subagente; cada subagente recibe su propio session_id y su propia cadena de auditoría.
• skillRegister y skillLoad vinculan los skills a un digest: solo puede cargarse lo que se haya aprobado previamente con idéntico skill_id e idéntico digest; las cargas que no puedan asignarse deberían rechazarse.

En el protocolo, las dispositions figuran en minúsculas en el campo decision; la prosa de la especificación las escribe en mayúsculas (ALLOW, DENY…). En v0.1, toda respuesta es de tipo final: los estados intermedios (progress) y las interrupciones (interruption) no están previstos hasta v0.2. Son obligatorios en toda respuesta type, acs_version, request_id y decision; el request_id replica el de la solicitud.

MODIFY: dos formas que se excluyen mutuamente

El objeto modifications admite dos formas. O bien modified_content sustituye todo el payload, y entonces no se permiten más ediciones. O bien el Guardian envía ediciones estructuradas: redactions (ruta JSON Pointer más texto de sustitución, por defecto «[REDACTED]») y/o parameter_overrides (nombre del argumento más valor nuevo). Ambas pueden aparecer juntas, pero sus destinos deben ser disjuntos: ninguna ruta de enmascaramiento puede afectar al mismo campo que un override, ni tampoco a uno superior o subordinado. La especificación lo justifica así: un orden de aplicación fijo resolvería los conflictos de forma silenciosa y, según el orden, volvería a exponer valores enmascarados o sobrescribiría valores saneados. Si un Guardian infringe estas reglas, el Observed Agent debe tratar la respuesta como un deny.

Un ejemplo: un agente quiere consultar por completo una tabla de clientes. El Guardian responde con modify y una entrada en parameter_overrides que limita la consulta a 500 filas, como en el escenario del simulador «Consulta ilimitada a la base de datos». Los valores de override figuran como valor bruto en el objeto, no dentro de un envoltorio value.

ASK: aprobación con reglas claras

• ask_details exige un approver (el aprobador) con type (human, agent o service) e id, una question y timeout_seconds (como mínimo 1).
• Si vence el plazo, se aplica timeout_disposition; el valor por defecto es deny.
• El Guardian debe verificar la identidad del aprobador frente a la política: la autenticación del aprobador es obligatoria.
• Un solo salto: los aprobadores no pueden devolver a su vez un ask. El quórum y las aprobaciones recursivas se aplazan a v0.2.
• Si un cliente no puede resolver ASK, el Guardian no puede enviar un ask. Recurre a defer con timeout_decision deny o a deny con el reason code approver_unavailable; un allow silencioso queda excluido.
• Mediante intent_extension, una aprobación puede ampliar las capabilities permitidas para this_request o para toda la session. Según la especificación, es la única vía conforme para modificar a posteriori el intent fijado.

Importante desde el punto de vista regulatorio: ASK no equivale automáticamente a supervisión humana. El aprobador puede ser un agente o un servicio, y timeout_disposition puede configurarse en allow. La supervisión humana conforme al artículo 14 del Reglamento de IA de la UE (AI Act) es aplicable a los sistemas de alto riesgo a partir del 2 de diciembre de 2027 (anexo III) o del 2 de agosto de 2028 (anexo I); los agentes de IA no son de alto riesgo per se. Quien utilice ASK como componente para ello necesita, según la valoración de VamiSec, una política con approver.type human y timeout_disposition deny, así como un proceso de aprobación que evite la fatiga de decisión. En ese caso, ASK respalda la generación de evidencias, pero no cumple por sí solo el art. 14: v0.1 no contempla un botón de parada, solo el deny paso a paso.

DEFER: aplazar la decisión, pero con límites

defer_details exige un reason (insufficient_context, conflicting_policies, low_confidence o pending_dependency), un resolution_method (additional_context, human_approval o timeout) y resolution_timeout_ms. Para el vencimiento del plazo, timeout_decision solo admite deny o ask, nunca allow, y por defecto vale deny. La prosa exige el campo, pero el esquema no lo marca como obligatorio; por eso, establézcalo siempre de forma explícita. Los aplazamientos en cascada deben estar limitados por sesión. Preste atención a las unidades: ASK cuenta en segundos (timeout_seconds) y DEFER en milisegundos (resolution_timeout_ms).

Cada sesión empieza con handshake/hello. El ClientHello va en el payload de un request envelope normal y el ServerHello vuelve como result, sin decision. La versión negociada debe coincidir con la del cliente en la versión principal (major); los campos desconocidos deben ignorarse.

Failure posture: fail-open es el valor por defecto

El Observed Agent debe esperar la decisión para cada paso notificado, hasta el timeout negociado, y aplicarla. Un framework que envía hooks pero ignora el veredicto no es conforme. Si no llega ninguna decisión utilizable, la especificación habla de un decision failure: el Guardian guarda silencio, el transporte se interrumpe (conexión rechazada, error de TLS, respuesta defectuosa) o el Guardian devuelve un error en lugar de una decisión. En los tres casos se aplica on_decision_failure, cuyo valor por defecto es proceed: la acción continúa sin revisar. Un despliegue debe configurar expresamente fail-closed (deny).

La especificación reconoce abiertamente el precio: quien pueda perturbar el canal convierte el control en un mero registro. Como contrapeso rige una obligación estricta: todo paso que continúe sin decisión debe registrarse como evento de auditoría. Si, aun así, llega una decisión dentro del plazo, el agente debe cumplirla, con independencia de la posture.

Startup posture: cuando ya falla el handshake

Si el Guardian no está accesible al inicio de la sesión o responde sin ServerHello, se aplica una startup posture configurada fuera del protocolo: proceed (la sesión arranca sin protección) o refuse. También aquí proceed es el valor por defecto, para que una caída del Guardian no bloquee nuevas sesiones. Una sesión iniciada sin protección debe constar en el log de auditoría propio del despliegue. En cambio, un rechazo expreso por parte del Guardian, como SESSION_REFUSED, cuenta como decisión y no como fallo.

Timeouts: sin valor por defecto en la especificación

La especificación no fija un timeout numérico por defecto. timeout_config.default_ms es obligatorio en el ServerHello, pero su valor corresponde al despliegue; per_method_ms permite valores distintos por método. El esquema del handshake recuerda que cada milisegundo de timeout supone, en el peor de los casos, latencia para el paso, y recomienda ajustar los plazos por método a la tolerancia de latencia en lugar de a un valor global generoso. La implementación de referencia usa 5000 ms: un valor de implementación, no una exigencia. Para v0.2 está previsto un modelo de timeouts basado en la sensibilidad. Para aclarar términos: ACS_ON_DECISION_FAILURE es una variable de entorno del Guardian de referencia que establece el valor de on_decision_failure, no un campo de la especificación.

Un ping no demuestra que se apliquen las decisiones

system/ping es una mera sonda de disponibilidad (liveness probe): el Guardian debe responder siempre allow, el ping no necesita firma y no se escribe en la cadena de auditoría. Así, un Guardian puede responder a los pings y, al mismo tiempo, rechazar todos los hooks firmados. Por eso, la especificación recomienda supervisar directamente los decision failures en la ruta de los hooks.

Dos capas, orden fijo

La capa determinista evalúa primero cada hook. Decide por sí misma o delega en la capa de agente, según la especificación mediante una configuración de cadena (chain) con los modos «*», on_ask o basado en patrones. Sin embargo, v0.1 no define un formato para esa configuración. La capa de agente recibe las mismas entradas más el resultado intermedio de la capa determinista, pero nunca el código de las políticas. Su respuesta debe volver a pasar por la capa determinista en el camino de vuelta.

1. 1
   Llega un hook

   El request envelope, el SessionContext, el intent y, si existe, la provenance se envían al motor de políticas.

2. 2
   Evaluación determinista

   Policy as Code (en v0.1, con OPA/Rego como referencia inicial) devuelve allow, deny, modify, ask o defer, o delega.

3. 3
   Capa LLM opcional

   Evalúa los casos que no pueden decidirse de forma determinista; trata los campos no fiables como datos y no ve código de políticas.

4. 4
   Comprobación de retorno y respuesta

   El resultado vuelve a pasar por la capa determinista; metadata.evaluator indica deterministic, agent o composite.

5. 5
   Registro

   Cada decisión se registra con su justificación, el identificador del modelo y, si está disponible, el nivel de confianza.

Motor de políticas: una interfaz, no un producto

ACS define la interfaz con el motor determinista, no el motor en sí. La entrada consta de request envelope, SessionContext, intent y provenance; la salida, de un decision envelope, opcionalmente con una delegación a la capa de agente (delegate_to). Además, ACS establece convenciones, entre ellas: ninguna llamada HTTP externa en las políticas canónicas. Esto favorece el determinismo y la latencia.

Obligaciones de la capa LLM

• Los datos no fiables son datos, no instrucciones; los campos correspondientes deben envolverse o entrecomillarse en el prompt.
• Sin acceso al código de políticas de la capa determinista.
• Registrar cada decisión con justificación, identificador del modelo y nivel de confianza (si está disponible); con evaluator agent o composite debe indicarse model_id.
• Los plazos siguen el timeout_config negociado en el handshake.
• Toda la capa es opcional en v0.1.0: los despliegues puramente deterministas son plenamente conformes.

Paradigmas de control sin extensión propia del protocolo

La especificación cita cuatro paradigmas como objetivos para v0.1. Un Guardian los expresa mediante los mismos campos: reason_codes, policy_references, policy_data y cited_provenance_ids. Si un despliegue combina varios paradigmas, una sola decisión puede citarlos todos.

FIDES, CaMeL y las reglas de tipo AARM necesitan datos de procedencia y, por tanto, requieren el perfil acs-provenance; IBAC puro, no. ACS no implementa ninguno de estos procedimientos: aporta los campos con los que un Guardian los aplica y los justifica. Por tanto, ACS no impide la prompt injection: crea el punto de control en el que las políticas actúan contra sus consecuencias.

Operación: latencia y disponibilidad (valoración de VamiSec)

• Latencia: cada revisión está en la ruta crítica del agente. Mantenga la capa determinista en local y sin llamadas externas, reserve la capa LLM para unos pocos casos dudosos y mida evaluation_duration_ms por método.
• Disponibilidad: con fail-closed, el Guardian pasa a ser crítico para la operación. Opérelo cerca del agente y de forma redundante. La propia implementación de referencia documenta el riesgo: escribe los logs de forma síncrona en la ruta de decisión, de modo que un disco lento bloquea todas las decisiones en curso.
• Ciclo de vida de las políticas: versione las políticas y devuelva policy_version en cada decisión; la especificación lo prevé para reconstruir estados históricos de las políticas.
• Delimitación: el Guardian no sustituye al sandbox, al IAM, a la gestión de secretos ni al firewall de egress. Las acciones que eluden toolCallRequest siguen siendo invisibles para él.

La única implementación de referencia ejecuta sin modificaciones el Agent Governance Toolkit de Microsoft tras el protocolo ACS. Es expresamente una prueba de concepto: dos de 19 hooks activos, sin firma HMAC, fail-open por defecto. Demuestra el patrón para dos clientes (Claude Code y OpenCode), pero no está pensada para la operación en producción.

Entre el Observed Agent y el Guardian Agent circulan decisiones que autorizan o bloquean acciones. Quien pueda manipular este canal convierte un deny en un allow o reintroduce una autorización antigua. Por ello, el OWASP Agent Control Standard (ACS) trata la seguridad del canal como parte de la línea base obligatoria ACS-Core y no como un perfil opcional.

Firma base: HMAC-SHA256 con clave de sesión

ACS-Core exige en cada solicitud y cada respuesta una firma sobre el envelope canónico. La línea base que cumple esta obligación es HMAC-SHA256. La clave se deriva por sesión mediante HKDF a partir de material de claves del despliegue (un secreto precompartido o una vinculación de canal, como un TLS exporter) junto con el session_id. La v0.1 no define ningún intercambio de claves en el protocolo. Se firma la canonicalización RFC 8785 (JCS) del envelope sin el campo signature; el receptor recalcula esta forma y rechaza cualquier firma que no coincida. TLS por sí solo no basta, de forma expresa, porque no vincula cada mensaje individual para la auditoría. Solo queda exento de la obligación de firma el método de liveness system/ping.

Hay dos detalles relevantes para la arquitectura. En el esquema JSON, signature es opcional, pero en ACS-Core es normativamente obligatoria: una mera validación contra el esquema no detecta, por tanto, la ausencia de firmas. Además, la especificación no fija para HKDF la sal, la cadena info, la función hash ni la longitud de la clave, por lo que dos implementaciones pueden derivar claves distintas. Según nuestra valoración, estos parámetros deben recogerse en el acuerdo de interfaz entre la operación de la plataforma y la del Guardian.

Protección contra replay

Cada solicitud lleva un request_id (UUID), un timestamp y, opcionalmente, un nonce. El Guardian debe rechazar las solicitudes cuya marca de tiempo quede fuera de la ventana negociada skew_window_ms (valor por defecto recomendado: 300 000 ms, es decir, cinco minutos) y rechazar los valores de request_id duplicados dentro de una sesión; los nonces duplicados debería rechazarlos. De ello se deriva un requisito operativo que se pasa por alto con facilidad: relojes sincronizados en ambos extremos.

Cadena de auditoría: cadena de hashes con cabeza publicada

El Guardian mantiene por sesión un SessionContext, una cadena append-only de ContextEntries. Cada entrada recibe un entry_hash: SHA-256 sobre la entrada canonicalizada con JCS sin los campos de hash, encadenado con el hash de la entrada anterior; la primera entrada tiene previous_hash null. En la v0.1 no se admiten otras canonicalizaciones. Lo decisivo es la publicación: para cada paso con contenido (content-bearing step), el Guardian debe incluir el chain_hash actual en su respuesta, cubierto por la firma de la respuesta. La especificación expone abiertamente el motivo: si el Guardian mantuviera privada la cabeza de la cadena, podría, por ejemplo, eliminar un deny, recalcular la cadena a partir de ese punto y presentar más tarde un historial depurado. Quien registre el tráfico detecta una cadena reescrita a posteriori.

Qué acredita la cadena y qué no

• Los campos obligatorios de un ContextEntry son solo entry_id, step_id, step_type y entry_hash. El request_hash sobre el contenido de la solicitud solo se recomienda en ACS-Core (SHOULD) y únicamente es obligatorio en el perfil acs-audit. Sin él, la cadena acredita que un paso tuvo lugar, pero no qué se solicitó.
• El esquema de ContextEntry no contempla ningún campo para la disposition, la justificación ni el aprobador. ACS registra normativamente las decisiones como eventos de Trace (perfil acs-trace, capítulo 9); solo una extensión de intent escribe una entrada propia con la identidad del aprobador (capítulo 11).
• HMAC es simétrico: el Guardian posee la clave y podría volver a firmar una cabeza de cadena reescrita. El canal está protegido frente a la manipulación en la red, no frente a un Guardian comprometido.
• El no repudio frente a terceros solo se obtiene con acs-crypto: como mínimo ML-DSA-65 (MUST), SLH-DSA-128s (SHOULD) y, de forma opcional, esquemas híbridos.
• En la v0.1 no existe una conciliación entre varios Guardians (issue #18, aplazado).

La aportación normativa de Trace es el vocabulario: nombres de span, claves de atributo, clases de eventos y la correspondencia entre dispositions y niveles de severidad. La transmisión se realiza mediante OTLP (gRPC o HTTP) hacia los backends existentes; el espacio de nombres de wire trace/* solo está reservado en v0.1.0. El objetivo declarado es que los eventos de ACS encajen en las pipelines del SIEM sin parsers especiales. Las extensiones de OTel y OCSF figuran en el repositorio con el estado «Working draft». Trace es el perfil opcional acs-trace. Quien lo declare debe emitir, para cada paso admitido, al menos uno de los dos formatos con los atributos obligatorios, registrar cada decisión con su disposition, su evaluador y, si existe, su justificación, y trasladar al evento los hechos de provenance del hook.

OpenTelemetry: un span por hook y las decisiones como span event

La jerarquía de spans es determinista: un span raíz acs.session por sesión, por debajo un acs.turn por turno y un span de step por hook. Las decisiones no son spans propios, sino un span event acs.decision en el span del step; así, el veredicto y la acción controlada comparten el mismo contexto padre. Los atributos obligatorios del evento son acs.decision y acs.evaluator (deterministic, agent o composite). Para las llamadas a herramientas, ACS utiliza los nombres de span gen_ai.tool.call y gen_ai.tool.result. Atención: en las convenciones GenAI de OpenTelemetry (en estado «Development» a octubre de 2026), gen_ai.tool.call es solo un prefijo de atributo y el nombre de span recomendado es execute_tool {gen_ai.tool.name}. Por tanto, los dashboards y las consultas alineados con estas convenciones no encajan con los spans de herramientas de ACS sin adaptarlos.

Casos de uso SIEM para agentes

Límites que debería tener en cuenta

• Best effort: Trace nunca debe bloquear la aplicación de las decisiones. Si el receptor (sink) falla, la decisión llega igualmente al Observed Agent, por lo que la telemetría puede presentar lagunas.
• Autodeclaración: los eventos de Trace se generan en el entorno observado y solo se convierten en evidencia mediante la atestación de una parte externa.
• Laguna de skills: los mapeos cubren 16 de los 19 hooks nativos más los dos métodos agbom. skillRegister, skillLoad y skillUnload no tienen mapeo ni de OTel ni de OCSF.
• Desfase documental: la ubicación de la provenance en OCSF es contradictoria (enrichments en el mapeo normativo, unmapped.acs.provenance en la guía). La página de ejemplos con consultas de Splunk y Elastic sigue utilizando el nombre antiguo ASOP y OCSF 1.0.
• Protección de datos: los spans pueden contener prompts y argumentos de herramientas. La especificación recomienda aplicar el enmascaramiento (redaction) ya en el momento de la emisión; según nuestra valoración, esto debe figurar de forma vinculante en el plan de logging.

Según la especificación, la AgBOM es un inventario dinámico y consultable de los componentes que utiliza un Observed Agent. La justificación es precisa: cualquier política que dependa de lo que es un agente (qué modelo, qué herramientas) resulta inverificable sin inventario. Si una política del Guardian depende del inventario, por ejemplo para prohibir un modelo o una herramienta, el despliegue debe implementar el perfil acs-inspect. La AgBOM canónica es un grafo de componentes almacenado como lista plana con referencias por ID, de modo que los distintos estados puedan compararse mediante diff.

Ocho tipos de componentes

snapshot y changed: dos métodos de wire

El Observed Agent envía agbom/snapshot una vez por sesión, después de sessionStart y antes del primer hook con contenido (content-bearing); el mensaje contiene la AgBOM completa. agbom/changed notifica mutaciones (componentes añadidos, eliminados o modificados, como diff o como snapshot completo) y puede indicar una causa, por ejemplo component_upgraded, discovery o user_action. Ambos eventos se incorporan a la cadena de auditoría. El Guardian puede rechazar mediante deny una sesión con un componente prohibido o bloquear un hot swap.

Importante para la elección de perfil: quien solo declare acs-inspect entrega exactamente un snapshot por sesión y no hace seguimiento de los cambios. Los cambios en tiempo de ejecución solo se vuelven visibles con acs-inspect-dynamic. Los desencadenantes de snapshot renegotiation y policy_request remiten a mecanismos cuya especificación está prevista para la v0.2; en la v0.1, en la práctica, solo session_start es fiable. Además, cada componente debería llevar una registration_provenance (obligatoria con acs-provenance). Así se puede distinguir si un componente procede de la configuración o se añadió en tiempo de ejecución.

Serializaciones: CycloneDX, SPDX, SWID

En el wire siempre se transmite la forma canónica; el Guardian genera serializaciones bajo demanda para las herramientas de procesamiento posterior. Un despliegue acs-inspect debe ofrecer al menos una de ellas: CycloneDX 1.6, SPDX 3.0 o SWID (ISO/IEC 19770-2). Los tres mapeos tienen el estado «Working draft»; las correspondencias con CycloneDX y SPDX no son en parte válidas según el esquema. El mapeo de CycloneDX utiliza como tipo de componente nombres como ai-model o service, que CycloneDX 1.6 no contempla en esa forma; el mapeo de SPDX emplea clases y relaciones que no existen en SPDX 3.0.1. Por ello, planifique las exportaciones con validación propia. CycloneDX, por su parte, está disponible en la versión 1.7 desde octubre de 2025.

Delimitación: AgBOM, AI-SBOM y SBOM del CRA

Provenance por campo: hechos en lugar de etiquetas de confianza

Provenance responde a la pregunta de dónde procede un elemento de datos y cómo llegó hasta su ubicación. Un objeto de provenance lleva un provenance_id, un origin con uno de siete valores (user_input, system, tool_output, retrieved, agent_generated, a2a_inbound, external) y, opcionalmente, source_id (por ejemplo, el nombre de la herramienta, una URL o una ruta) y derived_from como lista de predecesores. Estos datos se asocian a los campos portadores de datos; en toolCallRequest, incluso a cada argumento individual. De este modo, una política puede actuar sobre un flujo de datos concreto en lugar de sobre toda la llamada.

• Establecido por el framework: origin, source_id y derived_from los asigna código determinista fuera de la ruta de salida del LLM. Indicar al LLM que genere la provenance no es conforme.
• Linaje transitivo: los datos derivados heredan la procedencia de sus entradas, también a través de resúmenes y de la compactación. Así, un resumen de salidas de herramientas ajenas sigue siendo reconocible como tal.
• Sin campo trust: en la v0.1, un valor trust solo está reservado, no esquematizado. El Guardian deriva la confianza de origin y source_id conforme a su política; el material no fiable nunca se vuelve fiable por el procesamiento del LLM (regla de monotonía).
• Todo o nada: con provenance_producer: deterministic, cada campo portador de datos debe llevar provenance; un relleno parcial no es conforme. Si el cliente declara provenance_producer: none aunque la política exija provenance, el Guardian rechaza la sesión ya en el handshake con PROVENANCE_REQUIRED.

Provenance no forma parte de ACS-Core, sino del perfil acs-provenance. Es un requisito previo para paradigmas de aplicación de políticas como FIDES, CaMeL y AARM, pero no para la mera autorización basada en intent (IBAC). ACS no impide la prompt injection. Crea el punto de control en el que una política puede limitar sus consecuencias, por ejemplo bloqueando un correo electrónico cuyo destinatario y contenido procedan de un resultado de recuperación (retrieval) no fiable. Las etiquetas de sensibilidad o de IFC no forman parte del estándar; corresponden al Guardian o al despliegue.

Session Intent: el propósito fijado

En ACS, Intent no es un formato de wire, sino un concepto de gobernanza: vincula las acciones a un propósito autorizado, y lo hace antes de que los datos no fiables puedan ejercer influencia. Intent.parsed, el conjunto de capabilities autorizado para la sesión, se fija en sessionStart o en el primer agentTrigger. A partir de ese momento, ni el LLM ni las salidas de herramientas ni los datos procedentes de canales no fiables pueden modificarlo; si el intent se fija en sessionStart, debe rechazarse cualquier agentTrigger posterior con un intent divergente.

La única vía conforme para ampliarlo es una intent_extension que un aprobador devuelve a través del flujo ask, con datos obligatorios sobre capabilities y scope. Con scope this_request, la extensión solo se aplica a la solicitud en curso. Con scope session, el Guardian añade las capabilities, escribe un ContextEntry del tipo intent_extension con la identidad del aprobador y mantiene la provenance de la extensión separada de la del intent original. Con scope_mode strict, no debe aceptar ninguna extensión que la política prohíba en modo estricto. Para los CISOs, según nuestra valoración, esta es la palanca contra la escalada progresiva de privilegios: cada ampliación requiere una aprobación autenticada.

Identity: normativamente escueta, mucho aún en desarrollo

La firma de ACS-Core autentica de forma simétrica el canal entre el Observed Agent y el Guardian. No es ni una autenticación del principal ni no repudio; no debería mezclar ambas cosas en la arquitectura ni en las evidencias.

Wrapping de MCP: especificado, con una cuestión de obligatoriedad abierta

El espacio de nombres protocols/MCP/* es la vía canónica para transportar mensajes MCP hasta el Guardian, por ejemplo protocols/MCP/tools/call. El mensaje MCP permanece inalterado; ACS superpone el envelope, el contrato de decisión y las reglas de la cadena de auditoría. El flujo tiene dos etapas: el agente presenta la solicitud encapsulada al Guardian, aplica su decisión, reenvía el mensaje al servidor MCP tras un allow, según la descripción del flujo, y somete también la respuesta de este a evaluación antes de procesarla.

Un despliegue puede agrupar las llamadas a herramientas MCP (tools/call) en los hooks genéricos steps/toolCallRequest y steps/toolCallResult si bastan políticas a nivel de herramienta. El wrapping debería utilizarse cuando la política necesita distinciones específicas de MCP: negociación de capabilities en initialize, plantillas de prompts del lado del servidor (prompts/get), accesos a recursos (resources/read) y notificaciones (notifications/*). Con independencia de ello, los frameworks deben disparar toolCallRequest para cada acción que abandone el contexto de razonamiento, también para las operaciones integradas de archivos, red o shell.

MCP 2026-07-28: la prosa de la especificación va por detrás

Desde el 28 de julio de 2026, la revisión vigente de MCP es la 2026-07-28 (a octubre de 2026). Hace que el núcleo del protocolo sea sin estado, suprime el handshake initialize y declara obsoletos, entre otros, Sampling y Roots. El espacio de nombres de ACS protocols/MCP/* es neutral respecto a la versión; la revisión 2025-06-18 solo aparece en la especificación como ejemplo. Sin embargo, la prosa sigue presuponiendo la semántica anterior y menciona expresamente la negociación de initialize como punto que debe controlarse. La especificación deja abierto si esto afecta en la práctica a los wrappers; no disponemos de un análisis sólido al respecto. Según nuestra valoración, las arquitecturas con un uso intensivo de MCP deberían prever los hooks genéricos de herramientas como punto de control principal.

A2A: reservado para la v0.2

En la v0.1, el espacio de nombres protocols/A2A/* solo está reservado; la semántica normativa de wrapping está prevista para la v0.2 (fecha objetivo para la v0.2.0: marzo de 2027). Las páginas de A2A del repositorio proceden de la época AOS de 2025 y no son compatibles con el esquema. Hoy, las relaciones A2A solo se hacen visibles de forma indirecta: a través de agentTrigger con trigger_type a2a_inbound y de los componentes a2a_peer de la AgBOM. En cambio, ACS cubre los subagentes in-process con subagentStart y subagentStop; cada subagente recibe una sesión propia con su propia cadena de auditoría, que el agente padre referencia mediante el final_chain_hash sin fusionar las cadenas.

Ciclo de vida de los skills: register, load, unload

El digest cubre el artefacto cargable completo, incluidos los pesos de modelo o los adaptadores empaquetados; en la AgBOM solo se persisten la referencia y el digest, no el contenido. El Guardian no debería fiarse de un digest_verified notificado por el framework, sino compararlo él mismo con su aprobación. La propuesta de diseño (design proposal) sobre el ciclo de vida de los skills del repositorio señala abiertamente el límite: el digest vincula el artefacto registrado, no el código que un skill cargue posteriormente; esa carga posterior se canaliza como network.egress o process.execute a través de los hooks de herramientas habituales. El escaneo de marketplaces antes de la publicación no forma parte de ACS, y para los tres hooks de skills todavía falta un mapeo de Trace (capítulo 9).

ACS es un proyecto del OWASP GenAI Security Project y, según los propios metadatos de OWASP Nest, está clasificado en el nivel 2 (Incubator); el Project Lead califica su estado de «public preview». ACS no es un estándar ISO, IETF ni W3C, ni tampoco una norma armonizada.

Lo que ya aporta la v0.1

Pese a la fase temprana, la v0.1 aporta sustancia: un vocabulario común de 19 hooks y cinco dispositions, 44 esquemas JSON publicados, una failure posture claramente descrita con obligación de auditoría para cada bypass y una especificación que señala abiertamente sus propias lagunas. Según nuestra valoración, esto basta para medir a los proveedores con un criterio abierto y común y para diseñar los propios puntos de control de modo que sigan siendo compatibles con versiones posteriores, pero no para fiarse de etiquetas de conformidad.

La conformidad es una autodeclaración

En el handshake, el Observed Agent declara qué perfiles admite (profiles_supported) y el Guardian, cuáles acepta (profiles_accepted). Existen exactamente siete perfiles: acs-core como obligatorio, además de acs-trace, acs-inspect, acs-inspect-dynamic, acs-provenance, acs-crypto y acs-audit. No existen grados ni niveles. Quién verifica las afirmaciones de conformidad lo responde la propia especificación: en la v0.1.0, nadie. No hay suite de pruebas, ni registro de implementaciones conformes, ni ningún organismo que resuelva las afirmaciones controvertidas (issue #19, abierto, prioridad P1). Además, ACS-Core solo garantiza dos cosas: un canal autenticado y que el Observed Agent acate las decisiones del Guardian. No garantiza políticas estrictas: también un Guardian permisivo es conforme.

Implementación de referencia: el estado real, sin adornos

La única implementación de referencia es expresamente una prueba de concepto. Utiliza el Agent Governance Toolkit (AGT) de Microsoft sin modificaciones como motor de políticas detrás del wire de ACS, con integraciones de host para Claude Code y OpenCode. Declara acs-core solo con reservas («qualified») y ninguno de los seis perfiles opcionales. No existe un benchmark de interoperabilidad con AGT; es el objetivo de la ventana de 90 días abierta con el kick-off del 10 de septiembre de 2026. De ello no puede deducirse un respaldo de ACS por parte de Microsoft. Atención a la coincidencia de nombres: en la documentación de AGT, «ACS» designa la «Agent Control Specification» propia de Microsoft (2 de junio de 2026), el lenguaje de políticas de AGT, y no el estándar de OWASP.

Lagunas abiertas de la especificación con relevancia práctica

• Fail-open por defecto: on_decision_failure y la startup posture están en proceed; fail-closed (deny o refuse, respectivamente) debe configurarlo usted de forma deliberada.
• Sin mecanismo de parada: la v0.1 no incluye ningún kill switch; la interrupción (interruption) y el streaming están previstos para la v0.2. En la v0.1, un agente solo se detiene paso a paso mediante deny.
• Alcance obligatorio en evolución: una propuesta abierta (PR #21) rebajaría modify y system/ping a SHOULD.
• Lagunas de interoperabilidad (análisis propio): los parámetros de HKDF, la firma del handshake y la entrada para request_hash están insuficientemente especificados.
• Desfase documental: algunas páginas siguen mencionando 16 en lugar de 19 hooks o solo tres dispositions. Lo normativo son la especificación y los esquemas.

Antes de nada, tres precisiones. Primero, ACS no genera presunción de conformidad; el texto de la especificación no contiene ninguna correspondencia con el AI Act, NIS2, DORA, el CRA o ISO/IEC 42001: todas las correspondencias que figuran a continuación son interpretaciones de VamiSec. Segundo, los agentes de IA no son per se sistemas de alto riesgo. Las obligaciones para sistemas de alto riesgo del capítulo III, secciones 1 a 3, del Reglamento (UE) 2024/1689 se aplican, según el Digital Omnibus (Reglamento (UE) 2026/1744), a partir del 2 de diciembre de 2027 para el anexo III y a partir del 2 de agosto de 2028 para el anexo I; el art. 50 se aplica desde el 2 de agosto de 2026. Tercero, toda argumentación depende de los perfiles: ACS-Core por sí solo no incluye ni Trace ni AgBOM ni request_hash.

Puesta en marcha en cinco pasos

1. 1
   InventarioRegistrar y clasificar los agentes

   Registre los agentes, modelos, herramientas, servidores MCP y skills, y aclare para cada caso de uso su clasificación según el AI Act. Resultado: un registro de agentes con clase de riesgo, responsables y accesos a datos.

2. 2
   ArquitecturaDefinir puntos de control y perfiles

   Compruebe qué hooks dispara realmente su plataforma y cuáles confirma el Guardian en el handshake en methods_evaluated: todo lo demás se considera allow-by-default y queda sin protección. Elija los perfiles según sus necesidades de evidencia, por ejemplo acs-core más acs-trace y acs-audit para las obligaciones de registro.

3. 3
   PolíticaFormular las políticas como código

   La capa determinista se ejecuta primero (referencia en v0.1: OPA/Rego). Formule reglas para comandos destructivos, egress y pagos, exija para las acciones con consecuencias relevantes ask con aprobador humano y timeout_disposition deny, y referencie las versiones de las políticas en policy_references.

4. 4
   OperaciónDecidir y probar la failure posture

   Para los agentes con alto potencial de daño, establezca on_decision_failure deny y la startup posture refuse. Pruebe la caída del Guardian, el replay y los errores de firma, y supervise directamente los fallos de decisión, porque un ping correcto no demuestra que la aplicación de las decisiones funcione correctamente.

5. 5
   EvidenciaConectar Trace y documentar las evidencias

   Exporte OCSF u OpenTelemetry al SIEM, implemente los casos de uso del capítulo 9 y fije plazos de conservación. Proteja la cabeza de la cadena de forma externa y verifique las afirmaciones de conformidad de los proveedores mediante pruebas propias.

El whitepaper para CISOs «Agent Control para CISOs» (en alemán), que puede solicitar más abajo en esta página, ofrece una profundización con un programa de 100 días, un modelo de roles, métricas y preguntas de evaluación para plataformas de agentes. VamiSec acompaña la evaluación, la arquitectura, el diseño de políticas y las pruebas como consultora independiente; VamiSec no forma parte del proyecto ACS.