Indirect prompt injection
En seguridad de IA, la indirect prompt injection es un ataque en el que las instrucciones maliciosas van escondidas en contenido que un LLM lee (una página web, un documento, un registro recuperado, el resultado de una herramienta) en vez de escribirlas el usuario. Cuando el modelo tiene herramientas o memoria, seguir esas instrucciones escondidas deja de ser una curiosidad y pasa a ser un incidente de seguridad.
Cómo funciona
Un modelo de lenguaje no distingue de forma fiable las instrucciones de confianza de los datos sin confianza: todo lo que hay en su ventana de contexto es texto sobre el que puede actuar. La indirect prompt injection abusa de eso. El atacante planta instrucciones en un sitio que la aplicación va a darle después al modelo sin que ninguna persona lo lea antes: un comentario en una página que el agente navega, un campo de un registro traído por retrieval-augmented generation, la salida de una herramienta que el modelo invocó. Cuando el modelo llega a ese texto puede tratar las instrucciones plantadas como si fueran su tarea, y si la aplicación ha conectado el modelo a herramientas, ya se le puede dirigir para que envíe datos, llame a una API o ejecute una acción que el usuario no pidió.
Qué sale mal
Aquí es donde un truco de juguete con el prompt se convierte en un hallazgo. La prompt injection directa necesita que el atacante hable con el modelo; la indirecta solo necesita que controle algo que el modelo va a leer después, que en un sistema conectado es una superficie mucho mayor. En las evaluaciones que hacemos, el caso explotable es un agente que resume contenido sin confianza y que además tiene una herramienta para enviar correo o consultar una base de datos: una instrucción escondida en el contenido redirige esa capacidad. El problema de fondo es arquitectónico, así que filtrar la entrada no lo resuelve. Cualquier contenido que el modelo ingiera es una fuente potencial de instrucciones, y el daño escala con lo que al modelo se le permite hacer.
Dónde aparece esto en una auditoría
Tratamos como superficie de inyección toda ruta por la que contenido sin confianza llegue al modelo, y probamos qué pasa cuando ese contenido lleva instrucciones: si el modelo actúa sobre ellas y a qué puede llegar si lo hace. La severidad la decide qué permisos tiene el modelo, no lo ingeniosa que sea la carga, y por eso evaluamos esto junto con el diseño de las herramientas y con el alcance de mínimo privilegio. Los filtros y los guardrails se anotan como mitigaciones parciales, nunca como correcciones. Esto forma parte de cómo probamos una aplicación con LLM y herramientas.