Casi todas las organizaciones que despliegan un asistente con modelos de lenguaje llegan a la misma conclusión tras el primer incidente: el filtro que habían puesto en la entrada no era un control de seguridad, era una sugerencia. La inyección de prompts no es un bug que se parchea; es una consecuencia directa de cómo funciona un modelo de lenguaje.
El problema de fondo: instrucciones y datos viajan en el mismo canal
En una aplicación tradicional separamos el código de los datos. La consulta SQL está en un lado y el valor que escribe el usuario en otro, y por eso funcionan las sentencias preparadas. Un modelo de lenguaje no tiene esa separación: el system prompt, la pregunta del usuario, el documento recuperado del repositorio y la respuesta de una herramienta llegan todos como texto en la misma ventana de contexto. El modelo decide qué es instrucción y qué es dato usando el mismo mecanismo estadístico con el que redacta.
De ahí que no exista un equivalente a la sentencia preparada. Cualquier texto que entre al contexto —incluido el que nadie escribió a mano— puede comportarse como instrucción.
Si tu modelo lee contenido que no controlas, ese contenido ya es parte de tu superficie de ataque.
Dónde falla el enfoque de "poner un guardrail"
El patrón habitual es colocar un clasificador delante del modelo que detecte intentos de manipulación, y otro detrás que revise la salida. Ayuda, y conviene tenerlo, pero se apoya en tres supuestos frágiles:
- Que el ataque venga del usuario. La inyección indirecta llega dentro de una página web, un PDF, un ticket de soporte o un correo que el agente procesa. Ahí el usuario es la víctima, no el atacante, y el filtro de entrada no ve nada anómalo.
- Que el ataque sea legible. Instrucciones en otro idioma, codificadas en base64, escondidas en texto blanco sobre fondo blanco o repartidas entre varios turnos de conversación esquivan a los clasificadores basados en patrones.
- Que detectar equivalga a contener. Un clasificador con 95 % de acierto aplicado a miles de peticiones diarias deja pasar decenas de casos. Si una sola de esas peticiones puede borrar registros o enviar un correo, la tasa de detección es la métrica equivocada.
El control real está en lo que el agente puede hacer
El cambio de mentalidad que proponemos en los proyectos es dejar de preguntar "¿cómo evito que el modelo sea engañado?" y empezar a preguntar "¿qué pasa cuando lo engañen?". Esa segunda pregunta sí tiene respuestas de ingeniería:
1. Presupuesto de permisos por tarea
El agente no debe heredar los permisos del usuario que lo invoca, sino recibir el mínimo necesario para la tarea concreta y por un tiempo acotado. Un asistente que resume tickets no necesita credenciales de escritura, aunque quien lo usa sí las tenga.
2. Frontera de confianza explícita en el contexto
Marca en el propio prompt qué bloques provienen de fuentes no confiables y trata todo lo recuperado como dato inerte. No elimina el riesgo, pero reduce mucho la probabilidad de que el modelo obedezca texto ajeno, y deja rastro de dónde entró cada cosa.
3. Aprobación humana en las acciones irreversibles
Enviar, publicar, pagar, borrar y modificar permisos son acciones que deberían requerir confirmación explícita fuera del canal del modelo. Es el control más aburrido y el que más incidentes evita.
4. Trazabilidad de la cadena completa
Registrar solo la pregunta y la respuesta final es insuficiente para investigar. Necesitas el contexto recuperado, las herramientas invocadas, los parámetros y el resultado. Sin eso, después de un incidente no puedes responder la única pregunta que importa: qué texto concreto provocó la acción.
5. Red teaming continuo, no una prueba de aceptación
Los modelos cambian bajo tus pies: una actualización del proveedor puede alterar el comportamiento sin que tú toques una línea. Las pruebas adversariales tienen que ser un proceso periódico con casos versionados, igual que las pruebas de regresión.
Cómo se ve esto en una hoja de ruta
En un programa de adecuación típico ordenamos el trabajo así: primero el inventario de agentes y de las herramientas que cada uno puede invocar; después la reducción de permisos y la separación de identidades; luego las aprobaciones humanas en las acciones críticas; y al final —no al principio— los clasificadores de entrada y salida, que ahora sí aportan, porque protegen un sistema que ya no depende de ellos.
Ese orden importa. Empezar por el guardrail da la sensación de haber hecho algo y deja intacta la parte que provoca el daño. La pregunta con la que conviene revisar cualquier despliegue de IA es simple: si el modelo hiciera exactamente lo que le pide un atacante, ¿qué es lo peor que podría ocurrir, y quién se enteraría?