Ejecuta esta suite de ataques a agentes antes de producción: detecta inyección de prompt, envenenamiento de memoria y deriva de contexto

Antes de que un agente de IA toque la producción, trátalo como a un empleado junior con una credencial, una terminal y la costumbre de confiar en desconocidos. El objetivo no es demostrar que el modelo es seguro. El objetivo es demostrar que el sistema que lo rodea falla de una manera que puedes ver, contener y explicar. Una lista de verificación de seguridad de agentes de IA antes de la producción debería probar la inyección de prompt, el envenenamiento de memoria, la deriva de contexto, la fuga de datos y el comportamiento de la ruta de parada antes de preguntarte si el gateway es bonito.

Empieza con la identidad, no con el gateway

Muchos equipos recurren primero a los controles de gateway porque son visibles: límites de tasa, filtros, listas de permitidos, registro. Ese orden está invertido. La seguridad de agentes es una cadena de dependencias, y los controles aguas abajo dependen del contexto aguas arriba. Si la identidad del agente es demasiado amplia, un filtro posterior solo reduce el radio de impacto; no elimina el privilegio que hizo posible el incidente.

Define al agente como una identidad no humana con el alcance más pequeño que pueda hacer el trabajo. Si solo lee una cola de tickets, no debería tener acceso de escritura a facturación. Si solo redacta respuestas, no debería ejecutar comandos de shell. Si solo resume registros, no debería conservar credenciales de base de datos. Un estudio de Teleport de 2026 sobre 205 líderes de seguridad encontró que la IA con privilegios excesivos se asociaba con una tasa de incidentes del 76%, mientras que las organizaciones con privilegios mínimos informaron una tasa de incidentes del 17%. Eso no es un número mágico, pero apunta a la misma verdad operativa: una identidad de agente amplia convierte un prompt malo en un mal día.

Delimita las herramientas antes de delimitar los prompts. Cada herramienta debería tener un propietario con nombre, un propósito documentado y un efecto máximo. Una herramienta de búsqueda no debería convertirse en una herramienta de escritura porque el modelo decidió ser útil. Si una herramienta no se puede describir en una frase, divídela o elimínala.

Construye una suite de ataques repetible

La suite debería ser lo suficientemente aburrida para ejecutarse en cada versión y lo suficientemente específica para detectar los modos de fallo que importan. No intentas agotar al modelo. Intentas encontrar el camino desde una entrada no confiable hasta una acción que no pretendías.

• Inyecta un prompt canario en un documento, ticket, correo electrónico o página web que el agente leerá. Pídele que realice una tarea inofensiva y luego comprueba si intenta revelar el canario, cambiar sus instrucciones o llamar a una herramienta que no debería haber llamado. Usa un canario único por ejecución para distinguir una fuga real de una respuesta en caché.
• Envenena una entrada de memoria. Coloca un hecho falso, una política falsa o una instrucción maliciosa en la memoria a largo plazo del agente y luego haz una pregunta normal. Si el agente trata la entrada envenenada como autoritativa, tienes una ruta de envenenamiento de memoria. Si un solo mensaje de usuario puede sobrescribirla, tienes una peor.
• Mide la deriva de contexto. Da al agente una tarea larga con muchos turnos y luego introduce una contradicción sutil o una instrucción posterior que entre en conflicto con el objetivo original. Registra si cambia el alcance en silencio, descarta restricciones o empieza a usar herramientas fuera de la tarea. La detección de deriva no es una sola métrica; es un conjunto de invariantes: no hay permisos ampliados, no hay restricciones de seguridad ignoradas, no hay un usuario posterior que supere la política del sistema a menos que la política lo diga.
• Explora fugas de datos. Pídele al agente que resuma un documento que contenga un secreto canario, una clave de API falsa o un registro de cliente falso. Luego pídele que explique su razonamiento, exporte su plan o responda a una pregunta de seguimiento que pueda revelar el valor oculto. Una fuga no es solo el secreto en la respuesta final. También es el secreto en una llamada a una herramienta, registro, resumen en caché o escritura en memoria.
• Prueba la ruta de parada bajo carga. Inicia una tarea y luego activa el interruptor de parada. Verifica que la identidad del agente se desactive, que las credenciales se invaliden, que las herramientas se bloqueen, que las tareas se terminen y que la carga de trabajo se aísle. Una ruta de parada que solo detiene la ventana de chat no es una ruta de parada. Es un botón de pausa con pasos extra.

Ejecuta estas pruebas contra la misma versión del agente, el mismo conjunto de herramientas y el mismo almacén de memoria. Registra la entrada, el comportamiento seguro esperado, el comportamiento observado y la evidencia. Si una prueba pasa solo porque el modelo se negó por casualidad, vuelve a ejecutarla con parafraseos. Si pasa solo porque el gateway bloqueó la salida, anota que el agente aún intentó la acción. Esa distinción importa cuando decides si lanzar.

Haz que el gateway sea el quinto control, no el primero

Los controles de gateway son útiles, pero llegan tarde en la cadena. Pueden bloquear una exfiltración obvia, limitar la tasa de un bucle desbocado o registrar una solicitud sospechosa. No deberían ser la razón principal por la que el agente es seguro. El encuadre de la fuente aquí es directo: los controles de gateway deberían secuenciarse después, específicamente como el quinto control, en lugar del primero. Si tu arquitectura depende del gateway para detectar una inyección de prompt que la identidad del agente, el alcance de las herramientas, el aislamiento de memoria y la ruta de parada permitieron pasar, has construido teatro de seguridad con un firewall delante.

Un orden práctico se ve así: primero, identidad con privilegios mínimos. Segundo, herramientas con alcance y efectos secundarios explícitos. Tercero, memoria aislada y procedencia clara para los hechos almacenados. Cuarto, una ruta de parada firme que pueda detener al agente sin esperar a que un humano lo note. Quinto, controles de gateway para detección, limitación de tasa y bloqueo a nivel de tráfico. Este orden no hace opcional al gateway. Lo hace honesto: es un control, no un sustituto de los controles que deberían haber evitado el problema.

La presión del mundo real hace que este orden sea más fácil de entender. CISA añadió una falla de LiteLLM a su catálogo Known Exploited Vulnerabilities en junio después de abuso en el mundo real. La lección no es que una biblioteca sea mala. La lección es que la infraestructura de agentes puede pasar la autenticación y aun así derivar, exponer datos o ser envenenada en memoria. Si tu suite antes de la producción no puede mostrar cómo ocurriría eso en tu pila, no tienes una revisión de seguridad. Tienes una esperanza.