La inyección de prompts no se resuelve con más prompt. La defensa y el ataque comparten canal, así que toda mitigación escrita en el prompt es una que el atacante también puede abordar.
En un chatbot esto es un problema de contenido: el peor caso es texto que no quería. En un sistema agéntico el modelo tiene herramientas, así que el mismo ataque redirige acciones — y el radio de impacto es todo lo que ese agente estaba autorizado a hacer.
Del estándar
“Manipulating LLMs via crafted inputs can lead to unauthorized access, data breaches, and compromised decision-making.”
Los canales que se olvidan
Los equipos defienden la superficie obvia — el mensaje escrito por el usuario — y dejan otras tres abiertas. Cada una es contenido que el agente procesa, y el contenido es donde se esconden las instrucciones.
Documentos recuperados. Una especificación, un ticket de soporte o un PDF de proveedor ingerido en una base de conocimiento lleva lo que su autor escribió. En un sistema donde cualquiera puede cargar archivos, ese autor no es necesariamente un empleado.
Datos devueltos por una herramienta. Un campo de texto libre en un registro — una nota de cliente, una columna de descripción — llega al modelo como contenido. Quien pueda escribir ese campo puede intentar una inyección, y en un sistema de cara al cliente eso incluye a personas fuera de la organización.
Las descripciones de herramientas. El canal más subestimado. Los conectores anuncian sus herramientas con un nombre y una descripción en lenguaje natural, y esa descripción entra al contexto del modelo como guía autorizada. Un conector malicioso o comprometido puede poner instrucciones ahí.
Cuatro ataques que vale la pena nombrar
Suplantación de herramienta
Un servidor conectado registra una herramienta cuyo nombre o descripción suplanta a una confiable, y el agente la selecciona creyendo que es la legítima. La mitigación es una resolución de nombres que falla cerrada: una colisión deniega la llamada en lugar de resolverla por orden de registro o preferencia. Fallar cerrado es incómodo y correcto — la alternativa es una sustitución silenciosa que nadie observa.
Inyección en descripciones
Instrucciones incrustadas en el texto de descripción de una herramienta, aprovechando que las descripciones suelen tratarse como configuración confiable y no como entrada de terceros. Trátelas como no confiables, igual que cualquier contenido recuperado.
Evasión estructural de consultas
Una operación restringida anidada en una subconsulta, que vence a un validador que inspecciona las consultas generadas como texto. La coincidencia textual pierde ante el anidamiento siempre. Analice la consulta en un árbol sintáctico y valide estructuralmente, para que una operación restringida se detecte donde sea que aparezca y no solo en el nivel superior.
Salida a través de la salida renderizada
El más sutil de los cuatro. Si la interfaz renderiza un enlace o carga una imagen desde una URL que produjo el modelo, un atacante que controle esa URL tiene un canal de exfiltración — los datos salen codificados en la propia petición, sin llamada a herramienta que auditar. Valide cada destino contra una lista permitida antes de renderizar.
El supuesto de diseño
Asuma que la inyección tiene éxito. Luego pregunte qué puede hacer el agente con ella. Si la respuesta honesta es "escribir en un sistema de registro" o "alcanzar un host externo arbitrario", el problema no es la inyección — es que la capacidad existía sin condiciones. La defensa en profundidad significa que el ataque exitoso igualmente aterriza en un lugar inofensivo.
Contención, no prevención
La detección en el ingreso vale la pena y no es suficiente. Escanear contenido en busca de patrones de inyección eleva el costo de un ataque; no cierra la clase, y tratarla como el control es como las organizaciones terminan con un único punto de falla que creen que es una defensa.
Las capas que realmente lo contienen son estructurales. Valide cada llamada propuesta antes de despacharla, contra una política que el modelo no puede ver ni influir. Restrinja el catálogo de herramientas a la intersección de capacidad de plataforma, derechos del inquilino y rol del usuario que actúa, para que una instrucción inyectada no pueda alcanzar algo fuera de la autoridad de ese usuario. Detenga cada escritura en una puerta humana. Deniegue la salida por defecto desde el sandbox de ejecución.
Con eso en su lugar, una inyección exitosa produce una lectura no autorizada dentro de los permisos que ese usuario ya tenía, y una traza de auditoría que muestra exactamente qué se intentó. Eso es un incidente manejable y no una brecha.
Pruébelo antes que un atacante
La resistencia a inyección es comprobable. Siembre un documento con instrucciones y confirme que el agente no las sigue. Registre una herramienta suplantadora y confirme que la llamada se deniega en lugar de resolverse. Anide una operación restringida en una subconsulta y confirme que el validador la detecta. Produzca una URL fuera de la lista permitida y confirme que no se renderiza.
Esas pruebas pertenecen a la suite automatizada, no a una evaluación anual. La resistencia a inyección es una propiedad que se degrada en silencio cada vez que se agrega un conector o se edita un prompt, y una prueba que corre en cada commit es lo único que lo nota.
Axionalytics
IA agéntica en producción para equipos empresariales de ingeniería, datos e ingresos.