Seguridad de aplicaciones LLM: inyección y abuso de herramientas

La pregunta que abre cualquier revisión de seguridad de una aplicación de IA es distinta de la tradicional. No es "dónde entra el dato del usuario", es "qué puede hacer el modelo si cree en algo equivocado". La respuesta define el tamaño del daño posible.

La superficie de ataque cambia de lugar

En una aplicación web tradicional los límites son razonablemente nítidos: entrada, validación, consulta, respuesta. En una aplicación de LLM, instrucción y dato viajan por el mismo canal, y el modelo no tiene una separación fuerte entre "esto es una orden" y "esto es contenido para leer".

El Top 10 de OWASP para aplicaciones de IA generativa organiza ese territorio, y leerlo debería ser el primer paso de cualquier equipo que pone un LLM en producción. El punto que encabeza la lista es el más difícil: la inyección de prompt.

La inyección de prompt no tiene corrección definitiva

Este es el punto que más frustración genera. La inyección de SQL tiene solución: una consulta parametrizada separa código de dato de forma estructural. La inyección de prompt no tiene equivalente, porque no existe una capa que separe instrucción de contenido en el mismo canal.

Simon Willison sigue el problema desde hace años e insiste en una conclusión incómoda: filtrar por una lista de patrones prohibidos falla, porque el espacio de formulaciones es infinito. Cada filtro nuevo se sortea con otra redacción, otro idioma, una codificación.

La consecuencia práctica es que la defensa no puede ser "impedir la inyección". Tiene que ser "limitar lo que la inyección alcanza".

La indirecta es la que asusta

La inyección directa, tecleada por el usuario en el chat, es la variante más conocida y la menos peligrosa, porque el usuario suele estar atacando su propia sesión.

La indirecta es otra historia. Llega dentro del contenido que el sistema lee: una página consultada, un documento enviado, un correo procesado, un comentario en un ticket. El texto malicioso entra en el contexto sin que nadie lo haya escrito ahí, y el objetivo no es el atacante, es otro usuario o la propia empresa.

Cualquier aplicación que combine lectura de contenido externo con acceso a herramientas necesita tratar ese escenario explícitamente, en el diseño.

El daño ocurre en las herramientas

Un modelo que solo escribe texto tiene alcance limitado. Un modelo que puede consultar una base, llamar a una API, enviar un mensaje o borrar un registro tiene el alcance de la herramienta más poderosa que le entregaste.

Tres controles cubren la mayor parte de esto:

• Menor privilegio por herramienta. Consultas con credencial de solo lectura; escrituras restringidas al alcance mínimo; nada de credencial compartida y amplia.
• Autorización fuera del modelo. El permiso del usuario se verifica en el código antes de ejecutar la acción, nunca con una instrucción que pide al modelo respetar límites.
• Confirmación humana para acciones irreversibles. Enviar dinero, borrar datos, escribir a un cliente externo. El costo de un clic es bajo comparado con el de una acción equivocada.

El informe de Microsoft con lecciones de ejercicios de red team en más de cien productos de IA generativa refuerza ese recorte: los ataques exitosos suelen explotar integraciones y permisos, no fragilidades sofisticadas del modelo.

El camino de salida también filtra

Dos rutas de fuga aparecen con frecuencia y son fáciles de olvidar.

La primera es la recuperación sin control de permisos. Si el índice contiene documentos de varios niveles de acceso y la búsqueda no filtra por el usuario que preguntó, el sistema se convierte en una fuga con buena interfaz. El filtro tiene que estar en la consulta, no en la instrucción.

La segunda es la salida renderizada sin escape. Si la respuesta del modelo va a HTML sin tratamiento, puede devolver marcado ejecutable, y ganas un problema clásico de inyección en el navegador con un origen nuevo. Trata la salida del modelo exactamente como tratas la entrada de un usuario no confiable.

El red teaming debe ser rutina, no evento

El perfil de riesgo de un sistema de IA cambia cuando cambia el prompt, cuando se agrega una herramienta nueva y cuando el proveedor actualiza el modelo. Una prueba de seguridad hecha una vez en el lanzamiento envejece en semanas.

Lo que funciona es mantener un conjunto de casos adversariales en el mismo pipeline de las evaluaciones de calidad: intentos de inyección directa e indirecta, pedidos de escalada de privilegios, extracción de la instrucción de sistema, abuso de herramientas. Corre en cada cambio, junto con el resto.

El perfil de riesgo publicado por NIST para IA generativa, complementario a su marco de gestión de riesgo, ayuda a armar esa lista de escenarios sin empezar desde cero.

Qué significa esto para tu equipo

Empieza por la pregunta del primer párrafo: lista toda herramienta que el modelo puede accionar y, para cada una, escribe el peor resultado posible si se acciona con mala intención. La lista suele ser más corta y más aterradora de lo que se imagina.

Después mueve la autorización y el filtro de permisos al código, si todavía están en el prompt. Es el cambio que más reduce el riesgo por hora de trabajo.

Y agrega cinco casos adversariales a tu CI esta semana. Cinco ya cambian la conversación, porque convierten la seguridad de IA en algo que el equipo mide, y no en algo que el equipo espera que esté bien.