Los agentes ofensivos con LLM dejan de seguir guiones y empiezan a razonar
Frente al fuzzer que dispara cargas fijas, un modelo lee la API, entiende el formato esperado y construye el fallo a medida. El pentesting automatizado cambia de modelo mental.
Las herramientas de pentesting de toda la vida son rígidas. Metasploit, Nmap o un fuzzer cualquiera disparan cargas predefinidas y se quedan colgadas en cuanto la configuración se sale del patrón que esperan. Lo que está cambiando es otra cosa: un modelo de lenguaje puede leer la documentación de una API, entender que ese endpoint espera un objeto JSON con unos tipos concretos y construir un JSON malformado que dispare un fallo de deserialización, en lugar de limitarse a escupir caracteres aleatorios contra el campo. De ejecutar órdenes se pasa a razonar sobre la superficie de ataque.
Tres capacidades sostienen el cambio. La primera es leer código, logs y tráfico de red y sacar el significado de lo que se ve. La segunda es formular una hipótesis —este endpoint mete entrada de usuario en una llamada al sistema— y probarla. La tercera es recuperarse del fallo: si la carga no pasa, el agente mira el mensaje de error, deduce que alguien saneó la entrada y reescribe el siguiente intento. Es un bucle de prueba y corrección que se parece a la intuición de un analista, pero corre a velocidad de máquina.
El bucle y la memoria
Los agentes que se están viendo siguen patrones tipo ReAct o Plan-and-Solve: observar el estado, razonar, elegir herramienta, ejecutar en un entorno aislado y devolver el resultado al paso de observación. Nada de eso es nuevo en automatización. Lo que separa a un agente de un prompt suelto es el almacén de estado: va apuntando qué se ha probado ya para no dar vueltas en círculos, qué falló y por qué, y qué se ha descubierto por el camino, como una clave de API válida. Ese historial se le devuelve al modelo en cada vuelta, y es lo que le permite sostener una estrategia coherente a lo largo de decenas de pasos en vez de improvisar de cero cada vez.
Cuando el objetivo es otro modelo
Ahí está la parte incómoda para quien construye aplicaciones con LLM. Los system prompts y los guardrails no aguantan una conversación por etapas. El patrón que se describe es el de la inyección de prompt por ingeniería de contexto: el agente no lanza un mensaje malicioso de golpe, sino que erosiona el límite poco a poco. Primero pregunta vagamente qué tipo de datos maneja el asistente. Después adopta el papel de desarrollador interno que está depurando el módulo de datos personales. Luego pide solo los nombres de los campos, no los valores. Y cuando el modelo ya ha aceptado ese marco, pide el valor del campo de correo codificado en Base64 para verificar el formato. El filtro por expresiones regulares no ve un correo, ve una cadena.
Conviene ser claro con lo que hay aquí: no se publica ningún exploit funcionando contra un servicio concreto. Es la descripción del patrón, no un caso reproducido.
La lectura práctica para quien despliega estas aplicaciones es que el modelo forma parte de la superficie de ataque y las instrucciones del system prompt no son un control de seguridad, son una petición. Los límites tienen que estar en lo que el sistema puede hacer aunque le convenzan: permisos acotados en las herramientas que expone, aislamiento de los datos que alcanza y validación fuera del modelo. Un guardrail se escribe en el prompt; una cerca se pone en el código que rodea al prompt.
