Tu agente supera todas las pruebas de la demo y llega a producción. Una semana después, una tool responde con timeout y el agente completa los espacios con información inventada, como si nada hubiera ocurrido.
O quizá el problema no es una falla. Alguien empieza con solicitudes aparentemente legítimas y, mensaje tras mensaje, consigue que el agente haga algo que nunca debió hacer: revelar información, exceder sus permisos o intentar acceder a archivos fuera de su alcance.
En ambos casos, te enteras por el usuario y no por tus pruebas.
Strands Evals 1.0 incorpora dos capacidades para encontrar esos problemas antes de producción. Con chaos testing podemos inyectar timeouts, errores de red y respuestas truncadas directamente en las llamadas a las tools, y comprobar si el agente se recupera, degrada su respuesta de forma segura o simplemente inventa un resultado.
Con red teaming atacamos desde el otro frente. AdversarialCaseGenerator analiza las tools y el system prompt para construir casos dirigidos al agente que realmente estamos ejecutando. Si encuentra acceso a un shell, intentará aprovecharlo. Con estrategias como Crescendo, el ataque escala durante varios turnos: cada mensaje puede parecer razonable, pero la conversación completa termina empujando al agente fuera de sus límites.
En esta sesión construimos un agente real, lo rompemos con chaos testing y lo ponemos bajo ataque con red teaming. Luego revisamos qué señales deja, qué tan fácil es interpretar mal el incidente y cómo convertir esas evaluaciones en un gate de CI antes de desplegar.
Porque soportar una falla no significa resistir un ataque. Resiliencia y seguridad son problemas distintos, y un agente en producción necesita demostrar ambas.