Agentic Evidence

Evidencia de seguridad y observabilidad para IA agéntica

Agentic Evidence es un proyecto de referencia de código abierto de OWASP que explora cómo recopilar, correlacionar y evaluar la evidencia de seguridad de la ejecución de IA agéntica.

La observabilidad de agentes puede mostrar que un evento quedó registrado. Una investigación de seguridad necesita establecer qué ocurrió, qué identidades y permisos estuvieron involucrados, qué entradas influyeron en la acción, qué decisiones de política se tomaron y qué conclusiones respalda realmente la evidencia disponible.

Agentic Evidence se centra en la suficiencia de la evidencia, la reconstrucción de la ejecución y la investigación de seguridad. Complementa las taxonomías y los proyectos de pruebas de seguridad de agentes en lugar de duplicarlos.

Estado del proyecto: El proyecto está en incubación y la implementación inicial está en fase de planificación. La arquitectura y los comandos descritos en este documento representan el MVP previsto y pueden cambiar a medida que se finalicen las decisiones de implementación.

Objetivos

• Reconstruir ejecuciones de agentes a partir de eventos de ejecución y de seguridad correlacionados.
• Conectar acciones con identidades, entradas, contenido recuperado, llamadas a herramientas, decisiones de autorización y resultados.
• Hacer visibles para los investigadores la procedencia de la evidencia y las lagunas de evidencia.
• Demostrar qué se puede y qué no se puede concluir a partir de la evidencia recopilada.
• Proporcionar escenarios deterministas y repetibles que los colaboradores puedan ejecutar localmente.
• Publicar una taxonomía de evidencia extensible y orientación práctica para profesionales de la seguridad.

Escenarios iniciales

1. Ejecución benigna: Establecer una línea base para un flujo de trabajo normal de un agente.
2. Envenenamiento de recuperación: Demostrar cómo el contenido recuperado puede influir en una acción del agente y si la evidencia captura esa relación.
3. Modificación del descriptor de herramienta: Evaluar si la evidencia puede establecer qué descriptor de herramienta se observó o utilizó y si las modificaciones son detectables.

Los escenarios deben ser deterministas y utilizar datos sintéticos. El proyecto no debe afirmar que un ataque es detectable a menos que la implementación y las pruebas respalden esa afirmación.

MVP previsto

La primera versión está planificada como una aplicación de referencia local que incluye:

• Un ejecutor de escenarios determinista.
• Un esquema de evidencia JSON versionado.
• Telemetría de ejecución y correlación con OpenTelemetry.
• Un registrador de evidencia y un almacén de evidencia local.
• Una interfaz de investigación de seguridad con líneas de tiempo de ejecución, detalles de eventos y lagunas de evidencia.
• Paquetes de evidencia exportables.
• Pruebas automatizadas, configuración de Docker Compose y documentación para colaboradores.

Pila tecnológica propuesta

Componente	Tecnología propuesta
Aplicación/API	Python con FastAPI, o Go cuando corresponda
Formato de evidencia	JSON versionado con JSON Schema
Telemetría	SDK de OpenTelemetry y OTLP
Almacenamiento local	SQLite y/o fixtures JSON
Interfaz de investigación	Streamlit o una interfaz ligera equivalente
Despliegue local	Docker Compose
Pruebas	pytest y validación de esquemas
Integración continua	GitHub Actions

Estas son opciones de implementación propuestas, no una garantía de que todos los componentes estén disponibles. Las decisiones de arquitectura deben documentarse en el repositorio y cambiarse solo cuando exista una justificación técnica clara.

Lo que este proyecto no es

La versión inicial no está pensada para ser:

• Un SIEM de producción ni una plataforma de observabilidad de propósito general.
• Un entorno de ejecución de agentes, un proveedor de modelos ni un motor de respuesta autónoma.
• Una garantía de que un agente sea seguro o de que la evidencia registrada sea veraz.
• Un sustituto de la aplicación de autorizaciones, los controles de seguridad en tiempo de ejecución ni la respuesta a incidentes.
• Dependiente de un LLM en vivo, Kubernetes ni infraestructura en la nube.

La telemetría no es prueba por sí misma. Los eventos pueden faltar, estar correlacionados incorrectamente o haber sido generados por un componente comprometido. La aplicación debe distinguir entre registros observados, afirmaciones de componentes, evidencia verificada de forma independiente e incógnitas.

Flujo de trabajo conceptual

1. Ejecutar un escenario determinista.
2. Generar eventos de ejecución y de seguridad.
3. Correlacionar los eventos con una ejecución de agente y el contexto de traza.
4. Validar las estructuras de eventos y registrar la procedencia.
5. Inspeccionar las líneas de tiempo de ejecución, las decisiones de autorización, los resultados y las lagunas de evidencia.
6. Exportar el paquete de evidencia y compararlo con los hallazgos esperados del escenario.

Documentación del repositorio

• Primeros pasos: Configuración local y flujo de trabajo para la primera ejecución.
• Recursos: Estándares, especificaciones y proyectos de seguridad relacionados.
• Preguntas frecuentes: Alcance del proyecto, confianza en la evidencia, limitaciones de la telemetría y preguntas sobre contribuciones.

Principios del proyecto

• Evidencia antes que afirmaciones: Los hallazgos deben estar respaldados por evidencia explícita.
• Hacer visible la incertidumbre: La falta de evidencia es un resultado, no una razón para inventar una conclusión.
• Repetibilidad: Los escenarios deben tener entradas deterministas y resultados esperados verificables.
• Mínimos datos: Utilizar entradas sintéticas por defecto y evitar la recopilación de secretos o datos personales innecesarios.
• Interoperabilidad: Preferir esquemas documentados y convenciones de telemetría establecidas cuando corresponda.
• Seguridad desde el diseño: Tratar la ingesta, el almacenamiento, las exportaciones de evidencia y la interfaz de investigación como componentes sensibles a la seguridad.

Contribuir

Las contribuciones son bienvenidas en las siguientes áreas:

• Diseño y validación de esquemas de evidencia.
• Escenarios de seguridad de agentes y casos de prueba reproducibles.
• Recopilación de telemetría y correlación de eventos.
• Procedencia, integridad y análisis de la evidencia.
• Mejoras en la interfaz de investigación.
• Pruebas automatizadas y documentación.

Antes de comenzar un trabajo sustancial:

1. Revisar los issues existentes y la hoja de ruta del proyecto.
2. Abrir o comentar un issue describiendo el cambio propuesto.
3. Mantener los pull requests enfocados e incluir pruebas o evidencia reproducible cuando corresponda.
4. Nunca enviar secretos, datos reales de clientes ni trazas de producción sensibles.

Seguir las directrices de contribución del repositorio para conocer los requisitos vigentes.

Licencia

El proyecto tiene previsto utilizar la Apache License 2.0, sujeta al archivo de licencia publicado en el repositorio. Consultar el archivo LICENSE del repositorio para conocer los términos autoritativos.

Agradecimientos

Agentic Evidence es un proyecto de OWASP. Consultar el listado oficial de proyectos de OWASP y los metadatos del repositorio para conocer el liderazgo actual, los datos de contacto y el estado del proyecto. Las referencias a herramientas y servicios de terceros no implican el respaldo de OWASP.