Agentic AI Security Testing: La evidencia que hace verificables a los agentes de IA

En el Model Context Protocol (MCP), un host crea un cliente por cada servidor. El host debe hacer cumplir la autorización, el consentimiento y los límites de seguridad. Las herramientas se descubren e invocan mediante operaciones de protocolo estructuradas. Sus descripciones y anotaciones pueden influir en el comportamiento del modelo y no son fiables per se. Por ello, un incidente se extiende desde la ingesta de contenidos, pasando por la planificación, la aprobación y la llamada a la herramienta, hasta el efecto remoto. No se queda en una única llamada al modelo.

De esta arquitectura se derivan tres transiciones observables: host→cliente, cliente→servidor y servidor→efecto. Un trace que termina con una respuesta correcta de la herramienta puede aun así pasar por alto si se produjo una escritura externa, si se ejecutó dos veces o si alcanzó otro destino. Los logs habituales de los componentes o un identificador de trace compartido rara vez registran si la aprobación coincidía, en el momento de la ejecución, con el principal, los argumentos, el destino y la autoridad delegada.

Tres preguntas de investigación

• RQ1: ¿Qué perfiles de evidencia reconstruyen un efecto bajo fallos de telemetría controlados y lo atribuyen de forma unívoca?
• RQ2: ¿Mejoran las vinculaciones semánticas derivadas de amenazas la detección de seguridad más allá de la mera correlación?
• RQ3: ¿Qué cuesta la evidencia y qué modos de fallo persisten?

La contribución tiene tres partes: un Evidence Contract de cuatro etapas que traslada los hallazgos de MAESTRO y STRIDE a campos de runtime; un corpus determinista de fault injection con seis familias de ataque, variantes benignas muy próximas y un ledger de ground truth que el reconstructor nunca ve; y una comparación de perfiles fragmentados, correlacionados, causales y threat-guided sobre 3024 celdas.

MAESTRO organiza las amenazas en siete capas que interactúan de un sistema agéntico y subraya los efectos entre capas. Las capas van desde los Foundation Models, pasando por las operaciones de datos, los frameworks de agentes, la infraestructura de despliegue, la evaluación y la observabilidad, y la seguridad y el cumplimiento, hasta el ecosistema de agentes. STRIDE aporta seis categorías de propiedades: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service y Elevation of Privilege.

El artículo utiliza ambos frameworks para seleccionar escenarios relevantes para los límites. No pretende una validación empírica de los frameworks. El OWASP Top 10 for Agentic Applications 2026 sirve como contraste del vocabulario. Sus riesgos, entre ellos ASI01 Agent Goal Hijack, ASI02 Tool Misuse and Exploitation, ASI03 Identity and Privilege Abuse, ASI06 Memory & Context Poisoning y ASI08 Cascading Failures, se consideran allí problemas a nivel de sistema.

Cada evento lleva un ID de evento inmutable, componente, etapa, versión de esquema y marca de tiempo. Los campos de correlación añaden IDs de trace, span, parent y acción. Los campos threat-guided vinculan hechos cuya igualdad u orden aplica un oráculo de prueba. Lo decisivo es que el evento de la herramienta repita los valores ejecutados, en lugar de limitarse a apuntar a la decisión. Solo la comparación de etapas contiguas hace visibles las sustituciones que permanecen invisibles en traces de mera correlación.

Lo que el contract deliberadamente no registra

Ningún perfil registra chain-of-thought oculta. La evidencia de decisión se limita a resultados de política explícitos, reason codes concisos, atributos aprobados y hashes adecuados para pruebas controladas. No es necesario almacenar contenidos sensibles de prompts ni el reasoning del modelo. Las etiquetas de provenance, los identificadores estables y los keyed digests bastan para las pruebas y reducen la exposición.

Desde septiembre de 2026, ACS es un proyecto del OWASP GenAI Security Project, en el nivel 2 (Incubator) según sus propios metadatos; la especificación v0.1.0 es del 5 de junio de 2026 y el tag de release actual es 0.1.2. Surgió del Agent Observability Standard (AOS). Según ACS, un agente se considera fiable si es inspectable, traceable e instrumentable. Es decir, los operadores deben poder determinar a posteriori qué hizo un agente y por qué, y limitar de antemano lo que puede hacer.

Los tres pilares

Wire, provenance y audit chain

• Wire format JSON-RPC 2.0. Namespaces de métodos: steps/* (hooks), protocols/* (MCP encapsulado; A2A está reservado para v0.2), agbom/*, system/* y handshake/*. En caso de conflicto de versión, el handshake termina con UNSUPPORTED_VERSION. La prosa de la especificación aún presupone mecanismos de MCP anteriores a la revisión 2026-07-28, y si el wrapping de MCP forma parte de ACS-Core es contradictorio en el texto; las llamadas a herramientas MCP también pueden pasar por steps/toolCallRequest/-Result.
• Provenance es una etiqueta factual de procedencia en los campos que transportan datos. La asigna código determinista del framework, nunca el LLM: origin (user_input, system, tool_output, retrieved, agent_generated, a2a_inbound, external), source_id y derived_from como aristas de linaje.
• En el perfil acs-provenance, la provenance a nivel de campo es obligatoria para todo campo con datos de la sesión, incluido cada argumento de steps/toolCallRequest. La clasificación de confianza la realiza el Guardian según su política local; no es un campo del esquema v0.1.
• Cada respuesta para un paso que transporta contenido lleva un chain_hash: la cabeza SHA-256 rodante de la audit chain. policy_references (incluida la policy_version opcional) y cited_provenance_ids hacen que la decisión sea reproducible.
• Las firmas son criptoágiles y obligatorias en ACS-Core: cada solicitud y cada respuesta se firma sobre el envelope canónico; HMAC-SHA256 con una clave de sesión derivada mediante HKDF es la base que lo cumple. Hace evidente la manipulación en la red, pero no un Guardian comprometido. El no repudio solo llega con el perfil acs-crypto: ML-DSA-65 (obligatorio) y SLH-DSA-128s (recomendado como respaldo).

Por qué la laguna de efectos es estructural

Los hooks de ACS se disparan en el runtime del agente. steps/toolCallResult informa de lo que la herramienta devuelve al agente. No informa de lo que ocurrió realmente en el sistema de destino. El artículo muestra por qué importa esta diferencia: un trace que termina en la respuesta correcta de la herramienta puede pasar por alto escrituras duplicadas o destinos redirigidos. Por ello, la evidencia de efectos debe proceder de una segunda fuente, independiente del agente. Se vincula al trace de ACS mediante Action-IDs y Request-IDs.

Por qué fail-open es el problema F1

Si el Guardian no está accesible con la failure posture proceed, la acción continúa. ACS exige registrar como audit event todo proceed en fail-open, pero no se genera ningún comprobante de decisión con vinculaciones de aprobación. Operativamente, esto corresponde al fallo F1 del experimento (interpretación de VamiSec). Si faltan los eventos de decisión, la reconstrucción exacta y la atribución caen al 0 %, y el recall del perfil threat-guided al 50 %. Por ello, un despliegue de ACS que se tome en serio las pruebas de seguridad negocia on_decision_failure: deny (en la implementación de referencia: ACS_ON_DECISION_FAILURE=deny), establece la startup posture refuse en el Observed Agent y trata un receipt ausente como un fallo de prueba, no como una laguna en el log.

El corpus contiene seis familias de workflows, cada una con cuatro variantes inseguras y dos variantes benignas muy próximas: 36 plantillas, de las cuales 24 son inseguras y 12 benignas. Tres repeticiones deterministas dan 108 instancias de workflow. Las repeticiones varían los identificadores y el jitter de los eventos. Son una comprobación de reproducibilidad, no muestras estadísticas independientes.

Un generador de confianza produce eventos JSON canónicos de tipo MCP. Por separado se crea un ledger de ground truth con las identidades de evento esperadas, las aristas de parent, las etiquetas de unsafe, la regla vulnerada y la primera etapa de la violación. Antes de la reconstrucción se eliminan de los eventos observables los IDs privados de caso. Los workflows de la misma familia comparten una ventana temporal deliberadamente solapada. Es un caso difícil para la atribución por proximidad temporal.

Reconstrucción y métricas

• P0 agrupa un efecto con la herramienta más cercana en el tiempo, P1 por trace ID. P2 y P3 siguen las aristas de parent y recurren a los Action-IDs cuando falta el parent de un efecto.
• La reconstrucción exacta exige prompt, decisión, herramienta, todos los efectos y, en P2/P3, las aristas de parent esperadas.
• La atribución unívoca exige que todos los efectos esperados se asignen exactamente al prompt, la decisión y la herramienta correctos, incluso cuando falta una arista de parent.
• Recall y precisión usan la etiqueta de unsafe; la tasa de falsos positivos benignos, las 12 plantillas benignas. Las tasas de Correct-Rule y First-Stage ponen a prueba el diagnóstico.

La implementación utiliza exclusivamente la biblioteca estándar de Python. Dos ejecuciones limpias produjeron hashes byte-idénticos de configuración, casos, agregados y summary. Tres pruebas unitarias comprueban el tamaño y el equilibrio de la matriz, las salidas deterministas y la comparación de recall de P3 frente a P2.

P0 nunca alcanzó una atribución unívoca, porque los workflows solapados en el tiempo se fusionaron. Su recall aparente del 84,5 % no es un rendimiento de seguridad utilizable: las cadenas fusionadas erróneamente dispararon la alarma en el 85,7 % de los casos benignos. P1 solo detectó efectos duplicados. P2 elevó la atribución unívoca al 85,7 %, pero el recall de seguridad se mantuvo en el 16,7 %. P3 conservó la atribución de P2 y elevó el recall, la Correct-Rule-Rate y la localización First-Stage al 92,9 %.

Sensibilidad a los fallos

1. 1
   F0Evidencia sin modificar

   P1 a P3 reconstruyen y atribuyen cada workflow. P3 alcanza un 100 % de recall y de precisión sin falsos positivos.

2. 2
   F2Trace split en el límite de la herramienta

   P1 pierde por completo la reconstrucción y la atribución. P2 y P3 se mantienen en el 100 %, porque los IDs de parent y de acción salvan el límite de trace modificado.

3. 3
   F3Parents de efecto perdidos

   La reconstrucción exacta de P2/P3 cae al 0 %; la atribución unívoca se mantiene en el 100 % gracias al action fallback.

4. 4
   F4–F6Desfase temporal, duplicados, intercambio de Action-IDs

   Sin pérdidas en P2/P3: la evidencia restante proporciona una ruta unívoca y las comprobaciones de corrupción detectan la inconsistencia inyectada.

5. 5
   F1Eventos de decisión ausentes

   La debilidad residual dominante: la reconstrucción y la atribución caen al 0 % en P1 a P3, y el recall de P3 al 50 %. La autoridad de la fuente, la memoria y los duplicados siguen siendo detectables. La vinculación de la aprobación, del scope y del destino pierde su punto de comparación.

P3 añade 1682 bytes (aproximadamente 1,64 KiB) respecto a P0 y 1096 bytes respecto a P2. Un collector con la misma representación de eventos conservaría, para un workflow de tamaño medio, aproximadamente 3,55 veces los bytes canónicos de P0, o 1,88 veces los de P2. Estos valores responden a RQ3 como comparación del volumen de serialización. No miden latencia, CPU, volumen de transmisión, compresión, indexación ni costes monetarios.

Reglas de operación del artículo, traducidas a ACS

• Receipts de Decision, Invocation y Effect completos primero para las operaciones privilegiadas: en términos de ACS, para capabilities como filesystem.delete, network.egress o process.execute.
• Fijar límites de conservación explícitos. La deduplicación, la compresión y los keyed digests pueden reducir el volumen, pero deben medirse por separado.
• Quien omite un campo relevante para las invariantes o elimina Decision Receipts mediante sampling modifica el Evidence Contract y debe volver a evaluar. F1 muestra lo que entonces se pierde.
• Modelar por separado integridad, relojes, conservación y control de acceso. ACS ofrece para ello la base HMAC (acs-core), firmas asimétricas o PQC (acs-crypto), request_hash (acs-audit) y el chain_hash de la cadena de auditoría.

1. 1
   Paso 1Traducir las amenazas en hipótesis

   Recorrer las capas de MAESTRO y las propiedades de STRIDE para cada workflow de agentes. Para cada transición peligrosa, formular una tupla H = (boundary, precondition, invariant, evidence, oracle).

2. 2
   Paso 2Definir los hooks y perfiles de ACS

   ACS-Core como base, más los perfiles acs-trace y acs-provenance. Además de los seis hooks obligatorios de ACS-Core (sessionStart, userMessage o agentTrigger, toolCallRequest, toolCallResult, agentResponse, sessionEnd), instrumentar steps/knowledgeRetrieval, steps/memoryContextRetrieval y steps/subagentStart, y comprobar que el Guardian los incluye en methods_evaluated (si no, rige ALLOW-by-default).

3. 3
   Paso 3Definir el Decision Receipt

   Principal, versión de la política, reason code, operación, destino normalizado, digest de argumentos, capabilities, profundidad de delegación, expiración e idempotencia en policy_data. Persistido y vinculado a request_id y chain_hash.

4. 4
   Paso 4Endurecer la failure posture

   Establecer la failure posture en fail-closed: on_decision_failure: deny en el ServerHello (implementación de referencia: ACS_ON_DECISION_FAILURE=deny) y, en el Observed Agent, la startup posture refuse por si ya falla el handshake. Firmar los envelopes. Un receipt ausente es un fallo de prueba.

5. 5
   Paso 5Conectar un sumidero de efectos (effect sink) independiente

   La auditoría de gateway, de base de datos o de sink aporta el destino observado, el digest de la operación y la clave de idempotencia, correlacionados mediante el Action-ID.

6. 6
   Paso 6Pruebas negativas con gemelos benignos

   Por cada familia, casos inseguros y casos benignos muy próximos, como la resolución de alias permitida o los accesos de lectura repetidos. Congelar los predicates antes de probar.

7. 7
   Paso 7Dos gates de CI

   Gate 1, reconstrucción: etapas obligatorias y aristas de parent completas; de lo contrario, cuarentena. Gate 2, corrección: invariantes cumplidas; de lo contrario, interrupción indicando la regla vulnerada y la primera etapa.

8. 8
   Paso 8Inyectar fallos de telemetría

   Ejecutar F1 a F6 con regularidad contra la propia pipeline. Una prueba que sigue en verde bajo F1 no comprueba aprobaciones.

El estudio utiliza fixtures deterministas sintéticos, invariantes escritas a mano y calendarios de eventos fijos. No ejecuta ningún LLM, ninguna implementación de MCP, ningún OAuth, ningún motor de políticas ni ningún servicio externo. No mide el éxito de la prompt injection ni demuestra que un control impida un efecto. Precision y recall solo son válidos para las seis familias codificadas. Dado que el evaluador se diseñó a partir de las mismas hipótesis de amenaza, el experimento prueba la fuerza probatoria y la coherencia de la implementación, no el descubrimiento de nuevas amenazas.

• El ledger de ground truth está separado lógicamente, pero procede de la misma base de código. Implementaciones independientes, mutación property-based y capturas reales de protocolo reducirían los errores de modo común.
• Se da por supuesto que la telemetría es auténtica. Siguen abiertos los productores falsificados, el truncamiento de logs más allá de los fallos inyectados, los collectors comprometidos y la verificación criptográfica.
• Las nuevas clases de amenaza necesitan su propia hipótesis, campos, oráculos y pruebas escritas de forma independiente. Resource Exhaustion, por ejemplo, requiere evidencia de presupuesto y de consumo; la telemetría falsificada requiere identidad del productor y comprobación de integridad.

Divulgación del artículo: OpenAI Codex se utilizó para la organización de la literatura, el andamiaje de la implementación y la revisión del código de evaluación sintético, los primeros borradores y la revisión lingüística, así como el formateo. La formulación de la pregunta, el modelo de amenazas, la ejecución, la comprobación de los resultados y las fuentes, y todas las decisiones finales corresponden al autor.