El OWASP GenAI Security Project ha incorporado el Agent Control Standard (ACS) a su cartera de proyectos abiertos. Conviene aclarar lo primero, porque el anuncio se está leyendo mal: ACS no es una herramienta, ni una librería, ni un motor de políticas. Es una especificación de protocolo. Define el formato de cable, los puntos de control y el vocabulario de decisiones con los que un proceso externo puede intervenir la ejecución de un agente. Lo que ese proceso decida, y con qué lógica, no lo resuelve el estándar.
Dicho de otra forma: ACS te da el contrato, no el producto.
El hueco que viene a tapar
En los últimos dos años se ha estandarizado bastante alrededor de los agentes. MCP y A2A fijaron cómo hablan con herramientas y entre ellos. El OWASP Top 10 para aplicaciones agénticas catalogó qué puede salir mal. Lo que nadie había estandarizado es cómo se controla un agente mientras se ejecuta.
Hoy eso se resuelve dentro de cada framework. LangChain tiene sus callbacks, CrewAI los suyos, cada SDK propietario los que le parecen. El resultado es que la política de seguridad vive pegada al framework: si cambias de stack, reescribes los controles; si tienes tres plataformas de agentes, tienes tres implementaciones de la misma regla y ninguna garantía de que digan lo mismo.
ACS propone sacar esa lógica fuera del agente y ponerla detrás de un protocolo común.
Las dos partes
El modelo tiene exactamente dos actores:
- Observed Agent — el sistema con LLM que se monitoriza. Emite tráfico de hooks y obedece las decisiones que recibe.
- Guardian Agent — el punto de decisión. Recibe cada paso antes de que se ejecute y devuelve un veredicto.
El Guardian se define con dos capas internas, y el orden importa: una capa determinista (OPA/Rego, Cedar) que siempre corre primero, y una capa agéntica con LLM que solo se invoca si la determinista delega explícitamente. La capa con LLM es opcional: un despliegue solo-determinista es plenamente conforme.
Es una decisión de diseño que se agradece. Poner un LLM a vigilar a otro LLM como control primario traslada el problema en lugar de resolverlo, y el estándar no te obliga a ello.
Dieciséis hooks, y disparan antes
La v0.1.0 define 16 hooks de ciclo de vida: sessionStart / sessionEnd, agentTrigger, userMessage, agentResponse, turnStart / turnEnd, toolCallRequest / toolCallResult, knowledgeRetrieval, memoryContextRetrieval, memoryStore, preCompact / postCompact y subagentStart / subagentStop.
La propiedad que los hace útiles está escrita en el propio esquema de toolCallRequest:
Fires before tool execution. Primary enforcement gate.
No es telemetría que revisas al día siguiente. El paso se detiene, se consulta y solo entonces se ejecuta. Y la cobertura de hooks dice mucho de la madurez del modelo de amenazas: que existan memoryStore y memoryContextRetrieval significa que contemplan el envenenamiento de memoria persistente, que es de los vectores más incómodos en agentes de larga duración. Que existan preCompact y postCompact significa que contemplan lo que pasa cuando el contexto se comprime y algo se cuela en el resumen.
Cinco veredictos, no dos
Aquí está la diferencia con un guardrail clásico. El Guardian no responde sí o no:
| Veredicto | Qué significa |
|---|---|
allow | El paso sigue. |
deny | El paso se bloquea. |
modify | El paso se ejecuta con los argumentos alterados por el Guardian. |
ask | Se escala a una persona aprobadora antes de continuar. |
defer | La decisión se pospone. |
modify y ask son los que cambian el juego. modify permite sanear una llamada en vez de tumbarla, que en producción es la diferencia entre un control que se queda puesto y uno que el equipo desactiva a la semana por falsos positivos. Y ask convierte la aprobación humana en parte del protocolo, con estado, en lugar de en un parche por encima.
El esquema exige además que el campo reasoning venga relleno en deny, modify, ask y defer. Toda decisión que interrumpa al agente tiene que llegar explicada.
Los tres pilares
| Pilar | Qué aporta |
|---|---|
| Instrument | Los hooks y los veredictos. Es el único obligatorio (ACS-Core). |
| Trace | Mapeo de cada hook a spans de OpenTelemetry y clases de evento OCSF. El veredicto se emite como span event sobre el span del paso que controla, así que la decisión y la acción comparten padre. |
| Inspect | AgBOM: un bill-of-materials dinámico del agente (modelos, servidores MCP, peers A2A, herramientas, fuentes de conocimiento, almacenes de memoria), derivable a CycloneDX, SPDX o SWID. |
Sobre esto se apilan perfiles opcionales que se declaran en el handshake: ACS-Provenance, ACS-Crypto (HMAC-SHA256 de base, ML-DSA-65 y SLH-DSA-128s para post-cuántico, compuestos híbridos para la transición) y ACS-Audit (request_hash en cada entrada, para que la cadena SHA-256 se comprometa con el contenido de la petición y no solo con los metadatos del paso).
El AgBOM merece atención aparte. Un SBOM te dice qué librerías tiene tu software. Un AgBOM te dice qué puede hacer tu agente ahora mismo: qué modelo hay detrás, qué servidores MCP tiene conectados, a qué fuentes llega. Y reporta mutaciones, que es lo relevante cuando alguien añade una herramienta un martes por la tarde. Es, en formato máquina, lo que el checklist de gobernanza de LLM de OWASP pide como inventario de activos de IA.
Las dos piezas que de verdad importan
Si solo vas a leer dos secciones de la especificación, que sean estas.
Procedencia a nivel de campo. Cada campo con datos puede llevar un objeto Provenance con origin, source_id y derived_from (el linaje). La regla clave es quién lo rellena: código determinista del framework en los límites del canal, nunca el LLM. Tiene todo el sentido. Un modelo que clasifica la fiabilidad de su propia entrada es el mismo modelo al que intentas proteger de esa entrada; si el atacante controla el texto, controla también la etiqueta. Sacar la procedencia del alcance del LLM es lo que sostiene enfoques como FIDES o CaMeL.
Intent inmutable. El Guardian mantiene el estado de la sesión, y opcionalmente un Intent: la autorización estructurada de lo que esa sesión puede hacer. Una vez establecida, Intent.parsed es inmutable frente al LLM en runtime y frente a datos no confiables, y solo crece por acción de una persona aprobadora a través del flujo ask.
Esa regla es la respuesta directa a la inyección indirecta de prompts, el LLM01 del OWASP LLM Top 10. El ataque consiste en que un documento recuperado amplíe lo que el agente cree que está autorizado a hacer. Si el alcance solo se puede ampliar por vía humana, el texto envenenado deja de tener a dónde escalar. La versión de red de esa misma idea la contamos en un agente ofensivo no respeta un alcance que no está en la red: una frontera que se da por supuesta en lugar de imponerse no es una frontera.
La letra pequeña
Es una v0.1.0 en public preview, y hay que leerla como tal:
- No hay implementación de referencia. Lo que existe hoy es la especificación y los esquemas JSON. El Guardian de ejemplo y la instrumentación de FastMCP y A2A están planificados para la v1.
- El enforcement real sobre MCP y A2A llega en la v3. Extender esos protocolos para soportar
denyymodifyes trabajo pendiente. El namespaceprotocols/A2A/*está reservado en la v0.1 y su especificación de envoltura llega en la v0.2. Si alguien te vende "compatible con ACS" este año, lo que estás comprando es trazabilidad y vocabulario común, no un control que pare nada. - No trae políticas. El estándar define el canal y el formato de las decisiones. Qué se bloquea y con qué criterio sigue siendo tuyo, y es la parte difícil.
- Lo dice la propia especificación: ACS-Core autentica el canal y ata al agente a las decisiones del Guardian, pero por sí solo no hace que un despliegue sea seguro ni que sus políticas sean estrictas. La resistencia a la manipulación frente a un Guardian comprometido son los perfiles Crypto y Audit, no el núcleo.
- Hay coste de latencia. Cada paso pasa por un proceso externo antes de ejecutarse. Es asumible en un agente que llama a herramientas, pero es una variable de diseño real.
Qué hacer con esto si operas agentes hoy
- Léelo como modelo de amenazas antes que como estándar. La lista de 16 hooks es, en la práctica, el inventario de puntos donde tu agente puede ser manipulado. Si tu arquitectura no tiene control en la escritura de memoria o en el arranque de subagentes, ahí tienes dos huecos identificados sin adoptar nada.
- Empieza por el AgBOM. Es lo más barato de producir y lo que más rápido te devuelve valor: saber qué herramientas y qué fuentes tiene tu agente en este momento.
- Separa la política del framework. Aunque no implementes el protocolo, mover tus reglas a una capa determinista externa (Cedar, Rego) es la decisión que te deja alineado el día que quieras adoptarlo. Cómo encaja esa capa en el resto del sistema lo desarrollamos en cómo se construye un sistema agéntico seguro.
- No firmes conformidad con nadie todavía. Los perfiles son declarativos y verificables. Pregunta cuál se implementa, no si "soporta ACS". Y para lo que sí se implemente, la pregunta siguiente es cómo se demuestra que sirve de algo, que es de lo que va el bucle red team / blue team.
El puente con el cumplimiento normativo
Un AgBOM versionado más una cadena de auditoría verificable cubren buena parte de lo que el Reglamento (UE) 2024/1689 pide como documentación técnica (Art. 11) y registro de eventos (Art. 12) a los sistemas de alto riesgo, y encajan con lo que un auditor de ISO 42001 te va a pedir sobre control operativo. No hay mapeo oficial entre ACS y ninguno de los dos, así que no lo presentes como tal, pero la evidencia que genera el protocolo es exactamente del tipo que hay que producir. Qué exige el Reglamento y desde cuándo lo desglosamos en qué exige el Reglamento de IA en agosto de 2026; si te toca, puedes comprobar en qué categoría cae tu sistema con la calculadora de riesgo del EU AI Act.
Dónde encaja lo que estamos construyendo
Trabajamos en el rol que ACS llama Guardian Agent. DELIA es nuestra capa de detección y respuesta para pipelines de LLM, RAG y agentes, la categoría que se conoce como AIDR: intercepta inline por hop, devuelve un veredicto en milisegundos y exporta la evidencia a SIEM y SOAR en OCSF, sobre OpenTelemetry.
Los principios coinciden con los de la especificación, y no por casualidad: son las conclusiones a las que llega cualquiera que intente parar inyección indirecta en producción. La confianza de un fragmento recuperado se deriva de su fuente y la fija código determinista, no el modelo. La decisión se toma antes de que la acción llegue al sistema de destino. Y la traza sale en un formato que tu SOC ya sabe leer.
El paralelo más literal está en el veredicto que ACS llama ask. En la consola es una cola de aprobación: la llamada a herramienta queda retenida, con la regla que la ha gatillado a la vista, y no avanza hasta que una persona decide.
Lo que no vamos a decir es que DELIA sea conforme con ACS. La especificación tiene perfiles concretos, con handshake declarado y esquemas contra los que validar, y a día de hoy no los implementamos. Lo que sí estamos evaluando es alinear la capa de trazas con ACS-Trace, que es la parte más barata de hacer real precisamente porque ya emitimos OCSF y OpenTelemetry, y seguir el trabajo del proyecto desde dentro.
Que un estándar abierto y con gobernanza OWASP describa esta arquitectura tiene un valor concreto para cualquiera que la esté construyendo: deja de haber que inventarse el vocabulario para explicarle a un CISO por qué el control tiene que estar fuera del agente y por delante de la acción.
DELIA está en fase de I+D en el lab, es soberana y auto-hospedable. Si operas LLM, RAG o agentes en producción y quieres ver qué intercepta sobre tu propio pipeline, reserva una demo.