Agent Control Standard: Cómo probar controles en runtime sin llamar preview de garantía

Un agente puede recibir una política perfecta en prompt y aún ejecutar una acción indebida. Entre la intención escrita y el efecto en el mundo existen herramientas, identidades, argumentos, estado, memoria e integraciones. Es en ese camino que los controles necesitan ser observables y aplicables.

O Agent Control Standard (ACS), presentado por OWASP GenAI Security Project como preview público v0.1, propone un lenguaje común para instrumentar, rastrear, inspeccionar y controlar agentes en runtime. El proyecto es relevante porque desplaza la gobernanza del documento al punto de ejecución. Todavía no es prueba de eficacia, adopción o conformidad.

Estado: Evidence Brief técnico aprobado para publicación. El análisis fue cerrado en 02/09/2026 y describe la etapa pública observada en esa fecha. Componentes, recuentos y roadmap pueden cambiar.

El problema que ACS intenta resolver

Aplicaciones agênticas difieren de una llamada simple a modelo porque eligen caminos, usan herramientas y pueden producir efectos fuera de la interfaz de conversación. Un control útil necesita responder, como mínimo:

• cual agente intentó actuar;
• con cual identidad, alcance y objetivo;
• que herramienta y argumentos fueron solicitados;
• qué política ha sido evaluada;
• si la acción fue permitida, negada o modificada;
• que resultado material ocurrió;
• Que humano o sistema tenía autoridad para interrumpir y recuperar.

Registrar sólo prompt y respuesta no cubre esa cadena. Tampoco basta pedir al propio modelo que declare se actuó correctamente.

Lo que propone la versión pública

La página oficial del OWASP GenAI Security Project y repositorio estándar describen cuatro bloques principales:

1. hooks de runtime para observar decisiones y llamadas de herramientas;
2. un contexto de política que acompaña a la ejecución;
3. decisiones de enforcement como allow, deny y modify;
4. registros de telemetría y composición del agente.

El proyecto acerca sus eventos de convenciones como OpenTelemetry y OCSF y propone un Agent Bill of Materials, o AgBOM, para declarar componentes relevantes de la aplicación. En la documentación consultada, la integración con OpenTelemetry aparece como activa, el AgBOM como trabajo en marcha e integraciones MCP/A2A como planificadas.

Esa distinción de estado es importante. “Previsto en el roadmap” no significa “implementado”; “implementado en el proyecto” no significa “validado en su ambiente”; “evento registrado” no significa “control eficaz”.

Arquitectura mínima de integración

Una implementación responsable puede tratar el ACS como adaptador entre el runtime del agente y la capa de política:

intenção de produto
        |
        v
agente -> hook de ação -> policy decision point -> ferramenta
              |                 |                    |
              +------ trace + receipt <--------------+
                               |
                         revisão / incidente

El hook recoge contexto antes de la ejecución. El punto de decisión evalúa reglas fuera del modelo. La herramienta recibe solo la acción autorizada. El receipt registra decisión, versiones y resultado sin exponer secretos o datos personales innecesarios.

El control necesita fallar de modo seguro. Si la política no está disponible, las acciones de alto impacto no deben heredar el permiso implícito. El comportamiento de fallback debe ser decidido por clase de riesgo, documentado y probado.

El contrato que debe existir antes del código

Para cada herramienta, registre:

AgBOM puede ayudar a responder “¿qué compone este agente?”, pero no sustituye SBOM, inventario de datos, IAM, threat model o evidencia de deployment. El artefacto necesita apuntar para versiones realmente ejecutadas.

Pruebas mínimas para un piloto

Un piloto no debe comenzar por cobertura total. Debe demostrar que la frontera de autoridad funciona en los escenarios más relevantes:

1. una acción permitida llega a la herramienta con alcance reducido;
2. una acción prohibida se niega antes de producir efecto;
3. una acción modificada no permite recuperar los argumentos originales;
4. ausencia o timeout del motor de política bloquea la clase crítica;
5. intercambio de identidad o contexto invalida la decisión anterior;
6. replay no duplica una acción irreversible;
7. los logs preservan correlación sin almacenar credenciales o contenido innecesario;
8. un operador puede reconstruir la decisión, ejecución y resultado;
9. revocación interrumpe nuevas acciones y conduce el estado para recuperación;
10. Actualización de agente, herramienta o política dispara regresión.

El perfil exacto depende del producto y necesita threat modeling. Fuentes anteriores sobre sandbox, AISVS y cadena de entrega ayudan a estructurar el problema, pero no certifican una implantación ni definen un control universal. [R2-C3]

Lo que aún no se puede decir

En la fecha de corte, el ACS era un preview v0.1 en implementación activa. No localizamos benchmark independiente de reducción de incidentes, base pública de adopción en producción, comparación controlada con otros abordajes o certificación asociada al estándar.

O AI Security Standards Crosswalk del mismo ecosistema también exige cautela. Páginas públicas consultadas exhibieron diferentes recuentos de entradas, frameworks y mapeos; el propio proyecto informa que mapeos permanecen sin revisión hasta la firma de un revisor identificado. Por lo tanto, crosswalk puede apoyar la navegación y la hipótesis de cobertura, pero no debe utilizarse como sello de conformidad.

Las publicaciones del NIST sobre identidad para agentes y su síntesis de respuestas sobre seguridad de sistemas agénticos corroboran el problema general: los agentes necesitan identidad, autorización y auditabilidad fuertes. Ellas no validan una implementación específica del ACS.

Criterio de adopción

Adoptar el patrón primero como contrato de interoperabilidad y experimento controlado, no como alegación de seguridad. Una decisión de producción debe exigir:

• compatibilidad real con los runtimes y herramientas usados;
• latencia y disponibilidad medidas en el camino crítico;
• políticas externas al modelo y versionadas;
• evidencia de negación, revocación y recuperación;
• minimización y protección de la telemetría;
• operación probada cuando el componente de control falla;
• revisión de cambios del patrón antes de actualizar la integración.

La señal más importante no es cuántos eventos fueron generados. Es si la organización puede impedir un efecto prohibido, explicar una decisión y recuperar el sistema cuando el flujo escapa del esperado.

Fuentes y contexto editorial

1. OWASP GenAI Security Project — Agent Control Standard. Página del proyecto; fuente primaria y interesada en la adopción de la propuesta.
2. Agent Control Standard — documentación. Documentación oficial de la versión pública consultada en 02/09/2026.
3. Agent Control Standard — repositorio. Código y roadmap públicos; actividad de repositorio no prueba eficacia operativa.
4. OWASP AI Security Standards Crosswalk. Mapeación comunitaria en evolución; recuentos públicos divergían y ítems sin firma permanecían no revisados en el corte.
5. NIST — Why Agentic AI Needs a Strong Identity Foundation. Apoya la necesidad de una identidad fuerte, no una implementación del ACS.
6. NIST — Summary and Analysis of Responses on Security Considerations for AI Agent Systems. Síntesis de contribuciones recibidas; no es benchmark del ACS.

Nota editorial y de responsabilidad

Este texto combina hechos atribuidos a las fuentes con análisis y recomendaciones técnicas del autor. El ACS se presenta como preview público v0.1, no como garantía de seguridad, certificación o evidencia de conformidad. Puntos de vista personales y profesionales no deben ser confundidos con hechos comprobados; cuando hay datos o estados de implementación, la fuente, el corte y las limitaciones son indicados. El contenido es informativo y no sustituye a threat modeling, prueba, revisión jurídica, evaluación de privacidad o auditoría independiente. Tech Human y Trustyu actúan comercialmente en temas relacionados. Investigación, estructura y redacción tuvieron asistencia de IA; la versión publicable recibió revisión factual, revisión autoral y aprobación editorial en 02/09/2026, sin revisión humana independiente.

Corte de la investigación: 02/09/2026. Estado editorial: publicación especial adelantada por decisión explícita al 02/09/2026 a las 09h25 BRT.