Pentest tradicional vs sistemas agénticos: qué cambia con IA

Un pentest tradicional asume algo que casi nunca decimos en voz alta: que el sistema es determinista. La misma entrada produce la misma salida, el flujo de ejecución es predecible y la superficie de ataque se puede enumerar —endpoints, parámetros, formularios, mecanismos de autenticación—. Sobre esa base se construyó toda una metodología reproducible. Un sistema agéntico rompe ese supuesto de raíz, y entender por qué es el primer paso para evaluarlo bien.

El riesgo empieza antes de las herramientas

Hay una idea tentadora: que un chatbot que solo conversa, sin acceso a nada, es inofensivo. No lo es. Aunque el modelo no pueda ejecutar ninguna acción, sus palabras comprometen a la empresa igual que las diría un empleado. Si alucina una política, promete un descuento que no existe o entrega información equivocada a un cliente, el daño es real: reputacional primero, legal después. El caso de Air Canada lo dejó claro. Su asistente le dio a un pasajero información incorrecta sobre un reembolso, la aerolínea se negó a honrarla alegando que el chatbot era una entidad aparte, y un tribunal rechazó ese argumento y la declaró responsable de lo que había dicho su propio bot. La lección es incómoda y directa: no puedes externalizar la responsabilidad a un modelo. Lo que dice tu IA, lo dice tu empresa.

Por eso una parte del trabajo no apunta a robar datos ni a escalar privilegios, sino a medir qué tan fácil es sacar al modelo de su rol: hacerlo afirmar cosas falsas, contradecir políticas, adoptar un tono inaceptable o revelar partes de sus instrucciones internas. Son fallas sin exploit técnico detrás, pero con consecuencias de negocio tan concretas como cualquier vulnerabilidad clásica.

Qué cambia cuando el modelo decide y actúa

Si un bot que solo conversa ya compromete a la empresa, darle herramientas eleva la apuesta: capacidad de consultar una base de datos, llamar a una API interna, enviar correos o ejecutar pasos de un workflow sin intervención humana. Ahí deja de ser un generador de texto y pasa a ser un actor con permisos dentro de tu infraestructura.

Un caso real de 2026 lo ilustra. El asistente de soporte con IA de Meta podía ejecutar acciones sobre cuentas de Instagram, y varios atacantes lograron manipularlo para que agregara un correo bajo su control a la cuenta de la víctima y disparara un restablecimiento de contraseña. El bot enviaba el código de verificación al correo del atacante, que se lo devolvía para completar el cambio, sin necesitar jamás el correo real de la víctima; el resultado fue el secuestro de miles de cuentas de Instagram. La falla no estuvo en lo que el modelo dijo, sino en lo que podía hacer: tenía manos conectadas a un flujo crítico y bastó convencerlo para usarlas. Las cuentas con doble factor resistieron, señal de que el control determinista detrás del agente marcó la diferencia entre un incidente y una brecha masiva.

El cambio de fondo es sutil y peligroso. En una aplicación clásica, los datos y las instrucciones viven en canales separados: el código es código y la entrada del usuario es, como mucho, un dato que hay que validar. En un modelo de lenguaje esa frontera se borra, porque todo —la instrucción del sistema, la pregunta del usuario y el documento que el agente leyó por su cuenta— llega como lenguaje natural en el mismo contexto. El modelo no tiene forma nativa de saber qué parte debe obedecer y qué parte solo debe leer. Esa confusión entre dato e instrucción es el corazón de casi todos los riesgos nuevos.

Los riesgos propios del componente agéntico

El más conocido es la inyección de prompt. En su versión directa, el usuario escribe algo que convence al modelo de ignorar sus reglas. La versión indirecta es la que subestima más gente: el agente procesa una fuente externa —un correo, un PDF, una página web, un ticket— y esa fuente contiene instrucciones ocultas que el modelo termina ejecutando. El atacante no habla con el chatbot; le deja la trampa en un dato que el agente va a leer solo.

A eso se suma la agencia excesiva: darle al modelo más permisos de los que necesita. Si el agente puede borrar registros cuando su tarea era solo consultarlos, una inyección exitosa deja de ser un problema de texto y se convierte en una acción destructiva real. La misma lógica aplica a la memoria persistente y a las fuentes de un sistema RAG: si un atacante envenena lo que el agente recuerda o los documentos de los que se nutre, condiciona todas sus respuestas futuras sin volver a tocar el sistema. Y como la salida del modelo muchas veces se renderiza en una web o se pasa a otro componente, vuelven a aparecer clásicos como el XSS, solo que ahora la carga la genera la propia IA.

Por qué el método tradicional no alcanza

Un pentest tradicional busca una vulnerabilidad y la confirma: el pago funciona o no, el acceso se escala o no. Con un sistema agéntico eso no basta, porque la misma entrada no produce la misma salida. Un ataque que falla nueve veces y funciona a la décima sigue siendo una vulnerabilidad explotable, así que la evaluación deja de ser binaria y pasa a ser estadística: se repite el intento muchas veces y se mide con qué frecuencia el modelo cede y qué tan consistentes son sus barreras.

El modelo de amenazas también cambia de foco. En vez de empezar por los parámetros de un formulario, se empieza por el inventario de herramientas del agente y sus permisos: qué puede hacer, con qué credenciales, y qué pasaría si alguien lograra dirigir esa capacidad. Se prueban las fuentes externas que el agente consume, porque son el vector de inyección indirecta, y se evalúa si las barreras de contención resisten o son teatro. Nada de esto reemplaza lo anterior. Debajo del agente sigue habiendo una aplicación, APIs e infraestructura que necesitan el pentest de siempre; el componente agéntico agrega una capa, no borra las otras.

Dónde se gana la seguridad de verdad

La mejor defensa de un sistema agéntico no se agrega al final, se diseña desde el principio. Tratar cada salida del modelo como entrada no confiable, limitar los permisos de cada herramienta al mínimo indispensable y mantener validación determinista en los puntos donde el agente toca datos o acciones críticas son decisiones de arquitectura, no parches posteriores; es el terreno del desarrollo seguro. Cuando ese agente vive dentro de una aplicación expuesta a Internet, la higiene clásica de seguridad web sigue siendo la base sobre la que todo lo demás se sostiene.

La pregunta útil no es si conviene probar el chatbot o la aplicación tradicional, sino entender que son dos capas del mismo sistema y ambas se pueden romper. Si estás por desplegar un asistente con acceso a tus datos o un workflow que ejecuta acciones solo, vale la pena definir el alcance con criterio antes de abrirlo; ahí ayuda una consultoría que mire el conjunto. La IA no inventó la inseguridad: le dio manos. Y a algo con manos conviene probarlo antes de dejarlo trabajar solo.