Antes de confiar en los agentes de seguridad de IA, ponlos a prueba y gobiérnalos

La IA agéntica se convierte en una nueva superficie de ataque

Un artículo reciente, "Penetration Testing of Agentic AI", hace explícito este cambio. Los autores probaron cinco modelos (Claude 3.5 Sonnet, Gemini 2.5 Flash, GPT-4o, Grok 2 y Nova Pro) en dos marcos de agentes: AutoGen y CrewAI. Su entorno de pruebas fue un sistema de gestión de información universitaria con siete agentes para asesoramiento, finanzas, registro, servicios profesionales, apoyo estudiantil e información del campus. Los ataques incluyeron inyección de prompts, SSRF, mal uso de herramientas, ejecución de código, inyección SQL y escalada de privilegios. En otras palabras, el estudio no solo probaba si un modelo podía responder de manera segura en un chat; estaba probando cómo se comportaba un agente que utilizaba herramientas cuando instrucciones maliciosas intentaban dirigir sus acciones.

Una métrica útil en el artículo es la tasa de rechazo: la proporción de solicitudes maliciosas que el agente rechazó o bloqueó en lugar de ejecutarlas. AutoGen mostró una tasa de rechazo del 52,3 %, mientras que CrewAI mostró un 30,8 %; el rango de rechazo a nivel de modelo fue más estrecho, desde el 46,2 % de Nova Pro hasta el 38,5 % de Claude y Grok 2. Esa comparación apunta a una lección práctica: el marco de trabajo (framework) puede cambiar la forma en que el mismo tipo de agente responde al riesgo. En la IA agéntica, el comportamiento de seguridad significa más que la respuesta final. Incluye si el sistema delega una tarea, invoca una herramienta, expone datos, rechaza la solicitud, inventa resultados, registra el intento o permite que la solicitud continúe.

Los autores también identifican el "cumplimiento alucinado": casos en los que un agente parece seguir una solicitud pero fabrica el resultado en lugar de rechazarla claramente o ejecutar realmente la acción solicitada. Ese comportamiento es riesgoso porque puede crear un rastro de auditoría falso. Un panel de control puede registrar "tarea completada" aunque ninguna herramienta haya producido realmente el resultado afirmado, y una respuesta en lenguaje natural puede sonar plausible aunque no refleje lo que sucedió en el entorno. Los registros del agente, por lo tanto, necesitan mostrar más que la respuesta final. Deben preservar los prompts, las llamadas a herramientas, los permisos, los errores, los resultados y la evidencia detrás de la conclusión.

Otro ejemplo involucró a un agente que escribía código e intentaba ejecutarlo contra un endpoint de metadatos en la nube. El intento falló debido al entorno de prueba controlado, no porque el modelo se negara. La lección no requiere detalles operativos: en los sistemas agénticos, el contexto de implementación puede determinar si un comportamiento inseguro permanece contenido o escala a un incidente. El acceso a herramientas, los permisos de red, las protecciones de la nube, los límites de identidad y el aislamiento del tiempo de ejecución forman parte de la postura de seguridad del agente.

El paralelismo con el pentesting con IA es directo. El armazón define cómo el modelo planifica, recuerda y utiliza herramientas. En la seguridad de la IA agéntica, el mismo sistema circundante también define qué herramientas se exponen, cómo se comunican los agentes entre sí, dónde se trazan los límites de los datos y cómo se bloquea o registra el comportamiento inseguro. Los controles tradicionales de AppSec siguen aplicándose: el principio de mínimo privilegio, la validación de parámetros, las restricciones de red, la contenedorización, las puertas de aprobación y el registro rastreable se vuelven más valiosos cuando un modelo puede actuar a través de ellos.

El red teaming de IA también se está volviendo agéntico

En otro artículo, "Redefining AI Red Teaming in the Agentic Era", los autores se enfocan en cómo los equipos prueban los sistemas de IA para detectar comportamientos inseguros, violaciones de políticas u otros resultados perjudiciales. Argumentan que muchos flujos de trabajo actuales de red teaming siguen centrados en librerías: los operadores seleccionan ataques, aplican transformaciones de prompts, configuran evaluadores, inspeccionan trazas y arman informes manualmente. El flujo de trabajo agéntico que proponen permite a los operadores describir el objetivo de la prueba en lenguaje natural y el agente selecciona los ataques, compone las transformaciones, ejecuta el flujo de trabajo y reporta los hallazgos.

El framework integra más de 45 ataques adversariales, 450 transformaciones de prompts y 130 evaluadores. En un estudio de caso de Llama Scout, los autores probaron 68 objetivos adversariales a través de la interfaz de terminal de Dreadnode, sin que el operador escribiera código alguno. Informaron 674 ataques, 7.727 pruebas, 573 hallazgos y una tasa de éxito de ataque del 85%, incluidos 401 jailbreaks completos y 232 hallazgos críticos.

Estos resultados deben leerse con cautela. Un solo estudio de caso no debe generalizarse a todos los modelos, implementaciones u objetivos de red teaming, y los prompts adversariales específicos utilizados en el estudio no necesitan reproducirse aquí. El punto útil es operativo: el red teaming de IA se está convirtiendo en un problema de flujo de trabajo, no solo en un asunto de diseño de prompts.

El artículo también muestra cómo los resultados del red teaming pueden organizarse para el trabajo de seguimiento. Los hallazgos se mapean con marcos conocidos de IA y seguridad, incluidos OWASP LLM Top 10, MITRE ATLAS, NIST AI RMF y Google SAIF, y el sistema puede exportar tanto informes ejecutivos como datos estructurados para revisión técnica. La lección más amplia es que las pruebas de seguridad agénticas necesitan artefactos que las personas puedan inspeccionar, comparar, priorizar y abordar. Esto se aplica al red teaming de IA, a las pruebas de penetración con IA, a la revisión de código y a los flujos de trabajo de remediación.

La investigación de IA ofensiva necesita gobernanza, no silencio

Zhuo y sus colegas plantean un argumento estratégico: los agentes de IA podrían cambiar la economía de los atacantes al hacer que el descubrimiento y la explotación de vulnerabilidades resulten más baratos de repetir en múltiples objetivos. Si un atacante puede automatizar el reconocimiento, las pruebas y el desarrollo de exploits, cada objetivo adicional puede requerir menos esfuerzo humano que el actual.

Los autores argumentan que las salvaguardas a nivel de modelo no son suficientes por sí solas. El filtrado de datos, la alineación y los guardrails de salida pueden dar forma a cómo se comportan los modelos comerciales, pero no impiden que los adversarios ejecuten modelos de peso abierto (open-weight), los modifiquen o construyan sistemas ofensivos fuera de las plataformas administradas. La respuesta que proponen es un desarrollo defensivo controlado: evaluaciones comparativas (benchmarks) que cubran todo el ciclo de vida del ataque, agentes más fuertes para descubrir vulnerabilidades en el mundo real y una gobernanza que mantenga a los agentes ofensivos dentro de entornos de prueba ciberseguros (cyber ranges) auditados mientras se extraen capacidades defensivas para un uso más amplio.

El argumento es difícil, pero merece atención. Evitar la investigación de IA ofensiva no impedirá que los atacantes experimenten con la IA, mientras que publicar capacidades sin salvaguardas puede aumentar el riesgo. El trabajo responsable en esta área requiere entornos delimitados, registros de auditoría, controles de acceso, aprobaciones humanas, lanzamientos escalonados, divulgación responsable y límites claros sobre lo que se comparte.

ExploitGym ilustra la misma tensión desde un ángulo de medición. El benchmark evalúa si los agentes pueden convertir detonadores de vulnerabilidad en exploits funcionales a lo largo de 898 instancias, incluyendo software de usuario (userspace), el motor JavaScript V8 de Google y tareas del kernel de Linux. Sus resultados muestran que los agentes de frontera pueden demostrar una capacidad significativa de generación de exploits bajo condiciones de investigación de acceso confiable, donde las salvaguardas se relajan para estudiar los límites de la capacidad, pero también que las salvaguardas en el momento de la implementación pueden bloquear los intentos bajo un prompting predeterminado.

Ese contraste es central para la gobernanza. El comportamiento de un agente de seguridad con IA depende del modelo, de las herramientas circundantes, de la política de acceso y de los controles de seguridad activos en tiempo de ejecución. Por lo tanto, una discusión seria sobre la capacidad cibernética con IA debe especificar tanto lo que el sistema puede hacer en condiciones de investigación como lo que se le permite hacer en despliegue.

La ética debe escalar con la capacidad

Happe y Cito revisan 16 artículos que abordan 15 prototipos de seguridad ofensiva basados en LLMs. Su investigación encuentra que 13 de los 15 prototipos revisados, es decir, el 86,6 %, mencionan consideraciones éticas. También informa que 10 de los 15 artículos publicaron código fuente o artefactos, mientras que tres de los cinco que no publicaron artefactos de igual manera incluyeron prompts de ejemplo.

Esos números revelan una tensión no resuelta en el campo. La investigación necesita suficiente transparencia para que otros puedan inspeccionar las afirmaciones, reproducir los resultados y aprender de las fallas. Pero los artefactos ofensivos (código, prompts, conjuntos de datos, integraciones de herramientas o trazas de ejecución) también pueden reducir la barrera al uso indebido, especialmente cuando el sistema puede planificar, invocar herramientas o generar pasos de explotación. Por lo tanto, los autores argumentan que las declaraciones de ética deben abordar la motivación, el impacto potencial, la coherencia con la capacidad demostrada, las mitigaciones, la guía de monitoreo y las expectativas de divulgación responsable.

Un descargo de responsabilidad genérico no es suficiente. El enfoque ético debe coincidir con la capacidad descrita. Un agente acotado para CTF, un sistema de auditoría de código fuente, un generador de payloads y un benchmark de desarrollo de exploits no conllevan el mismo riesgo. Sus opciones de publicación, los lanzamientos de los artefactos y los controles de acceso también deberían diferir.

Una revisión práctica puede comenzar con unas pocas preguntas:

La misma lógica de revisión se aplica a la investigación, a las afirmaciones de los proveedores y a los equipos de seguridad internos que desarrollan herramientas agénticas. La ética no debe tratarse como un párrafo añadido al trabajo técnico; debe dar forma a lo que se prueba, a lo que se registra, a lo que se publica y a quién se le permite usar el sistema.

Las afirmaciones del mercado plantean preguntas de gobernanza

La actividad del mercado sitúa ahora estas preguntas de gobernanza en un contexto práctico. Anuncios y proyectos recientes describen pentesting autónomo, pruebas ofensivas continuas, agentes conscientes del código fuente, validación orientada a pruebas, guía de remediación y pruebas reejecutables: vea ejemplos de un proveedor de la nube, un mercado de AppSec, un repositorio de pentesting de IA de código abierto y un producto de pentesting de IA.

El punto aquí no es validar esas afirmaciones. Es que los flujos de trabajo de seguridad agéntica están pasando de los artículos de investigación a los productos, repositorios y hojas de ruta de los proveedores. Cuando eso ocurre, la gobernanza se convierte en parte de la adopción: quién puede ejecutar el agente, qué sistemas puede tocar, qué acciones requieren aprobación, cómo se registran las evidencias y cómo se trasladan los hallazgos a la remediación.

Los modelos de acceso requieren la misma disciplina. Los equipos internos de AppSec, los pentesters externos, los encargados de responder a incidentes, los investigadores y los desarrolladores no necesitan permisos idénticos. Algunos agentes solo pueden leer código; otros pueden ejecutar escáneres; otros pueden ejecutar ataques de prueba de concepto en entornos de prueba; y un subconjunto más pequeño puede acceder a entornos similares a los de producción con un alcance explícitamente definido. Cada nivel necesita registro, aprobaciones y una regla clara de detención.

Un modelo de acceso razonable podría verse así:

Este nivelamiento ayuda a los equipos a emparejar agentes con trabajos. Un asistente de revisión de código, un agente de pentesting en staging y un benchmark de generación de exploits no deberían compartir los mismos permisos porque no representan el mismo nivel de riesgo operativo o legal.

Qué deberían preguntar los equipos antes de la adopción

Antes de adoptar un agente de seguridad de IA, los equipos de ingeniería deberían comprender su entorno operativo. Las preguntas básicas son prácticas: qué datos puede leer, qué herramientas puede invocar, si puede cambiar el estado del sistema, si puede enviar solicitudes externas y si la ejecución está aislada (sandboxed). Los equipos también deberían saber si los prompts, las autocorreciones, los comandos, los resultados de las herramientas y los hallazgos finales se registran de manera que faciliten su revisión.

La siguiente capa es la validación. Los hallazgos no deberían depender únicamente de la narrativa del modelo. Los equipos necesitan saber cómo el sistema confirma la explotabilidad, cómo maneja los falsos positivos, cómo elimina los duplicados y cómo responde cuando el agente falla, entra en un bucle, inventa resultados o se ve influenciado por contenido malicioso en un repositorio, un ticket, una página web o un documento. Esas preguntas definen el diseño de seguridad del agente.

Los ejecutivos no necesitan inspeccionar cada prompt o bucle, pero deberían saber si la organización puede gobernar el flujo de trabajo. Las preguntas útiles son si la herramienta detecta vulnerabilidades válidas o produce alertas plausibles; si las acciones de alto impacto requieren aprobación; si los resultados se auditan; si se mide la confiabilidad de las ejecuciones repetidas; si la herramienta reduce el tiempo de remediación; y si existe un proceso de divulgación para los problemas encontrados en software de terceros o de código abierto.

La prueba operativa es si la organización puede absorber los resultados del agente. Un descubrimiento más rápido ayuda solo cuando la validación, la priorización y la remediación pueden mantener el ritmo. De lo contrario, la IA simplemente convierte un cuello de botella en otro.

Un modelo de adopción responsable

Un modelo de adopción realista debería ser gradual. La primera etapa es la asistencia de solo lectura: resumen, modelado de amenazas, soporte para la revisión de código, generación de casos de prueba y redacción de informes. En este nivel, las principales preocupaciones son la exposición de datos, la calidad de los resultados y la revisión humana.

La siguiente etapa es la ejecución controlada en entornos locales o de pruebas. Aquí, los agentes pueden ejecutar herramientas, inspeccionar hallazgos conocidos o proponer pruebas, pero deberían operar con sandboxing, datos de prueba, listas de herramientas permitidas y registros rastreables. Antes de que los equipos comparen herramientas o amplíen el acceso, deberían realizar pruebas repetidas y validaciones a nivel de hallazgos para entender la confiabilidad, los falsos positivos y el costo.

La prueba por explotación debería llegar más tarde y solo con autorización explícita. El entorno debería usar datos desechables siempre que sea posible, así como mecanismos de rollback, monitoreo y puertas de aprobación para acciones que puedan afectar la disponibilidad, la integridad de los datos, los sistemas de terceros o los activos de producción. En este nivel, la organización ya no está probando únicamente si el agente es útil; está probando si el flujo de trabajo se puede gobernar.

Para el red teaming con IA, se aplica la misma lógica por etapas. Prueba modelos y agentes bajo objetivos definidos. Mantén rastreables los prompts adversariales y sus respuestas. Mapea los hallazgos con marcos de trabajo cuando eso ayude a la comunicación, pero no permitas que las etiquetas de cumplimiento reemplacen la revisión técnica. Almacena trazas estructuradas para que las fallas puedan estudiarse, no solo contarse.

Para la investigación de IA ofensiva, los controles deberían escalar con la capacidad demostrada. Un artículo de capacidad debería explicar el entorno, los límites, las salvaguardas, el plan de divulgación responsable y la justificación de la publicación de artefactos. Si un sistema demuestra una capacidad de explotación más fuerte, su sección de ética debería volverse más específica.

La lección conectada

El primer post de esta pareja argumentaba que los agentes de pentesting de IA se están volviendo técnicamente significativos cuando los modelos se envuelven en planificación, memoria, herramientas y validadores. Esta publicación añade la otra mitad: esos envoltorios crean sistemas que deben ser asegurados, probados y gobernados.

El futuro de la IA en las pruebas de penetración dependerá de algo más que de la capacidad del modelo. Los sistemas más fuertes producirán evidencia válida, respetarán el alcance, preservarán la auditabilidad, conectarán los hallazgos con la remediación y mantendrán a los humanos como responsables de las decisiones de alto impacto.

Ese estándar es más difícil de cumplir que una demo convincente o una respuesta llena de confianza, pero es el criterio que los equipos de seguridad necesitan. Los sistemas agénticos deberían ganarse la confianza mediante un trabajo que pueda ser inspeccionado, reproducido y gobernado.