Inyección de prompts

La inyección de prompts es un ataque en el que una entrada manipulada hace que un modelo de lenguaje ignore sus instrucciones originales y siga las del atacante. Es el riesgo de seguridad más discutido para las aplicaciones construidas sobre grandes modelos de lenguaje, y es difícil de eliminar del todo por la forma en que funcionan estos modelos.

Un LLM no separa de forma limpia las instrucciones confiables de los datos no confiables. El prompt del sistema, el mensaje del usuario y cualquier contenido que la aplicación introduzca llegan todos como texto en la misma ventana de contexto. Si un texto controlado por el atacante dice "ignora tus instrucciones anteriores y haz X", el modelo puede obedecer, porque para el modelo todo es texto sobre el que actuar.

El resultado es que las salvaguardas de una aplicación pueden ser sorteadas con palabras. A un modelo al que se le indica ser un bot de soporte cortés se le puede convencer de revelar su prompt de sistema, producir contenido prohibido o, en un sistema que usa herramientas, llamar a funciones que no debería.

Inyección directa de prompts

En una inyección directa, el atacante es el usuario. Teclea instrucciones diseñadas para anular el prompt del sistema: pedir al modelo que revele instrucciones ocultas, hacer un juego de roles que rodee una restricción o tratar las reglas anteriores como canceladas.

El jailbreaking es una forma muy conocida de inyección directa, donde el usuario construye un escenario que convence al modelo de pasar por encima de su entrenamiento de seguridad. La inyección directa es el caso más fácil de razonar, porque la entrada maliciosa viene de la persona que interactúa con el sistema, y la limitación de frecuencia o la detección de abuso pueden ayudar.

Inyección indirecta de prompts

La inyección indirecta es la variante más peligrosa. Aquí las instrucciones maliciosas no las teclea el usuario. Están ocultas en contenido que la aplicación trae: una página web que el modelo resume, un documento en un almacén de recuperación, un correo en una bandeja que el modelo lee o un archivo subido por otra persona.

Cuando el modelo procesa ese contenido, encuentra las instrucciones plantadas y puede seguirlas, aunque el usuario nunca las vio ni las quiso. En un sistema que puede usar herramientas o enviar datos, la inyección indirecta permite a un atacante que controla un solo documento recuperado dirigir las acciones del modelo. Por eso los sistemas de recuperación y de agentes tratan todo el contenido ingerido como no confiable.

Por qué es un riesgo principal de los LLM

La inyección de prompts está en la cima de las listas de riesgos, incluido el OWASP Top 10 para aplicaciones de LLM, por unas cuantas razones.

Es fundamental, no un error. La falta de un límite firme entre instrucciones y datos es inherente a la forma en que los modelos actuales leen un prompt. No hay un parche que lo cierre por completo.

Escala con la capacidad. A medida que las aplicaciones dan a los modelos acceso a herramientas, datos privados y la capacidad de actuar, una inyección exitosa pasa de una salida vergonzosa a la exfiltración de datos o a acciones no autorizadas.

Es difícil de probar de forma exhaustiva. Los atacantes pueden expresar la misma intención de incontables maneras, incluso en otros idiomas o en formas codificadas, así que un filtro que bloquea una redacción rara vez las bloquea todas.

Mitigaciones

No hay una solución única, así que las defensas se ponen en capas.

Separa y etiqueta los niveles de confianza. Mantén distintas las instrucciones del sistema, la entrada del usuario y el contenido recuperado, y deja claro al modelo cuál es autoritativo. Algunos frameworks usan roles de mensaje estructurados para reforzar esto.

Restringe lo que el modelo puede hacer. La mitigación más fuerte es reducir el impacto. Limita los permisos de las herramientas, exige aprobación humana para las acciones de consecuencia y nunca dejes que la salida del modelo dispare directamente una operación irreversible sin una revisión.

Valida entradas y salidas. Filtra patrones de inyección conocidos, y revisa la salida del modelo y cualquier llamada a herramienta antes de actuar sobre ellas. Trata el contenido recuperado y el del usuario como no confiable por defecto.

Aísla y usa un entorno controlado. Ejecuta las acciones de las herramientas con el mínimo privilegio, para que un modelo secuestrado aun así no pueda alcanzar sistemas sensibles. Sanea el contenido antes de que entre a la ventana de contexto donde sea práctico.

Prueba de forma adversaria. Haz red teaming de la aplicación con intentos de inyección, incluidos los indirectos plantados en documentos y páginas, y lleva registro de qué redacciones se cuelan con el tiempo.

Ninguna combinación es perfecta, así que la meta realista es hacer la inyección más difícil y limitar el daño cuando tiene éxito.

Relevancia para la gobernanza

La inyección de prompts es donde se encuentran la seguridad y la gobernanza. Bajo la Ley de IA de la UE, los sistemas de alto riesgo deben ser resilientes a los intentos de manipularlos, lo que implica directamente a la inyección. La norma ISO 42001 y el Marco de Gestión de Riesgos de IA del NIST esperan que amenazas como esta se identifiquen, prueben y mitiguen como parte de la gestión de riesgos continua.

Para los equipos de gobernanza, las solicitudes prácticas son claras. Documenta que la inyección de prompts está en tu modelo de amenazas. Muestra evidencia de pruebas adversarias. Registra los controles que limitan lo que un modelo comprometido puede hacer, y conecta los incidentes de inyección con tu proceso de respuesta a incidentes de IA. La idea no es afirmar inmunidad, que nadie puede, sino demostrar que el riesgo se entiende y se contiene.

Preguntas frecuentes

¿Cuál es la diferencia entre inyección directa e indirecta de prompts?

En la inyección directa el usuario teclea instrucciones que anulan el prompt del sistema. En la inyección indirecta las instrucciones maliciosas están ocultas en contenido que el modelo ingiere, como una página web, un documento o un correo, así que el usuario nunca las tecleó y puede no saber que están ahí. La inyección indirecta es más peligrosa porque puede secuestrar sistemas que usan herramientas y de recuperación a través de una sola fuente plantada.

¿Se puede prevenir por completo la inyección de prompts?

No. Los modelos actuales no imponen un límite firme entre instrucciones y datos, así que la inyección no puede cerrarse del todo. Las defensas reducen con qué frecuencia tiene éxito y limitan el daño cuando ocurre, sobre todo restringiendo los permisos del modelo y validando sus acciones. Trátala como un riesgo gestionado, no como uno resuelto.

¿En qué se diferencia la inyección de prompts del jailbreaking?

El jailbreaking es un tipo de inyección directa dirigida a llevar al modelo más allá de sus restricciones de seguridad, por ejemplo produciendo contenido prohibido. La inyección de prompts es la categoría más amplia, que también incluye anular las instrucciones de la aplicación y, en su forma indirecta, plantar comandos en contenido externo para secuestrar el comportamiento o el uso de herramientas.

¿Por qué la inyección indirecta de prompts es un problema para RAG y los agentes?

Estos sistemas introducen contenido externo en el modelo: documentos recuperados en RAG, resultados de herramientas y páginas obtenidas en los agentes. Si cualquiera de ese contenido lleva instrucciones ocultas, el modelo puede seguirlas y, en un agente, usar mal sus herramientas. Como el contenido llega a través de la recuperación o las herramientas en lugar del usuario, esquiva las revisiones de entrada dirigidas al usuario.

¿Cuál es la defensa más efectiva por sí sola?

Limitar las capacidades del modelo. Si un modelo comprometido no puede alcanzar datos sensibles, gastar dinero ni tomar acciones irreversibles sin aprobación humana, una inyección exitosa produce una mala salida en lugar de un daño real. El filtrado de entrada y el etiquetado de confianza ayudan, pero restringir el impacto es lo que aguanta cuando el filtrado falla.

¿Cómo se relaciona la inyección de prompts con el cumplimiento?

Marcos como la Ley de IA de la UE exigen que los sistemas de alto riesgo resistan la manipulación, y estándares como la ISO 42001 y el NIST AI RMF esperan que las amenazas se identifiquen, prueben y mitiguen. Ante un auditor, conviene mostrar que la inyección está en tu modelo de amenazas, que haces red teaming para detectarla y que los controles limitan el impacto de un ataque exitoso.

Resumen

La inyección de prompts es un ataque que hace que un modelo de lenguaje siga instrucciones suministradas por el atacante en lugar de las propias, aprovechando que los modelos no separan las instrucciones confiables de los datos no confiables. La inyección directa viene del usuario, mientras que la indirecta oculta instrucciones en contenido que el modelo ingiere y es la variante más peligrosa para los sistemas de recuperación y de agentes. No puede eliminarse del todo, así que la respuesta se pone en capas: separar los niveles de confianza, restringir los permisos del modelo, validar entradas y acciones, aislar las herramientas y probar de forma adversaria. Para la gobernanza, la expectativa es mostrar que el riesgo está en tu modelo de amenazas, que se prueba y que se contiene, no afirmar inmunidad.