¿Qué es la inyección de prompts?

Los ataques de inyección de prompts utilizan consultas maliciosas y elaboradas para engañar a un LLM y hacer que realice alguna acción indeseable. Por ejemplo, un atacante podría convencer al sistema GenAI de ignorar las restricciones o políticas corporativas y generar tipos de contenido no aprobados.

Con la integración generalizada de GenAI y agentes de IA en los flujos de trabajo corporativos, los ataques de inyección de prompts representan un riesgo significativo para la fiabilidad y seguridad del servicio. Los atacantes pueden engañar a los agentes para que realicen acciones que conduzcan a violaciones de datos, infecciones por malware u otros incidentes de seguridad.

Aspectos Clave

• La inyección de prompts manipula las instrucciones del modelo para desencadenar salidas inseguras, exposición de datos o acciones no intencionadas.
• La inyección de prompts indirecta puede ocurrir a través de contenido no confiable, como páginas web, documentos, correos electrónicos, tickets o registros de chat.
• El riesgo aumenta cuando los modelos pueden utilizar herramientas, acceder a fuentes de datos o realizar acciones.
• Las mitigaciones son en capas. Los controles de entrada y salida ayudan, pero la «prevención perfecta» no es una suposición realista.
• El objetivo es reducir el radio de explosión utilizando el menor privilegio, fuertes límites de datos y pasos de verificación para acciones sensibles.

¿Cómo funciona la inyección de prompts en la práctica?

Los LLM comúnmente tienen instrucciones y restricciones en su lugar para controlar cómo operan. Los creadores de LLM incorporan ciertas salvaguardias, y las empresas añaden sus propias instrucciones al configurar herramientas para realizar diversas tareas dentro de sus entornos.

Los ataques de inyección de prompts utilizan entradas cuidadosamente elaboradas diseñadas para eludir estas restricciones y hacer algo que beneficie al atacante, como robar datos sensibles, producir salidas que violen políticas o desencadenar acciones en herramientas conectadas. Estas entradas podrían ser proporcionadas directamente a la herramienta o incrustadas en otro contenido que consume, como documentos recuperados por RAG o páginas web que visita un agente.

Inyección de Prompts Directa

La inyección de prompts directa implica que el atacante interactúe directamente con el agente. Por ejemplo, un atacante podría estar ingresando prompts en un chatbot de LLM. Estos mensajes maliciosos pueden seguir varios patrones, tales como:

• Ignorar instrucciones anteriores
• Juego de roles coercitivo
• Modo de desarrollador
• Lenguaje de anulación de políticas

El objetivo de estas instrucciones es hacer que el mensaje del atacante tenga prioridad sobre las restricciones del LLM, ya sea explotando una laguna o siendo percibido como más importante por el LLM. Si tiene éxito, el LLM puede generar contenido no permitido, filtrar instrucciones ocultas, proporcionar recomendaciones inseguras o desviar acciones hacia la herramienta o el usuario incorrecto.

Inyección de mensajes indirecta

Los ataques de inyección de mensajes indirecta insertan instrucciones maliciosas en el contenido que un modelo consume en lugar de instrucciones directas. Estos podrían incluir:

• Páginas web
• Documentos
• Correos electrónicos
• Tickets de TI
• Transcripciones de chat
• Bases de conocimiento

Estas amenazas son más significativas si un LLM accede a contenido externo, ya sea a través de un RAG o navegando por la web en busca de respuestas potenciales, ya que los datos recuperados se tratan como contexto por el LLM. Las instrucciones maliciosas pueden estar literalmente ocultas en el contenido, como usar texto blanco para hacer que las instrucciones sean invisibles para los lectores humanos o el uso de texto que parece benigno pero que un modelo interpreta como instrucciones.

Los principales tipos de ataques de inyección de mensajes

Los ataques de inyección de mensajes pueden realizarse para lograr varios objetivos. Dos de los principales tipos de ataques intentan acceder a información sensible sobre el mensaje del sistema o manipular el uso de herramientas de una IA para recopilar información sensible o realizar acciones dañinas.

Filtración de indicaciones y extracción de indicaciones del sistema

Algunos ataques están diseñados para acceder a la indicación del sistema, que puede incluir datos sensibles, como instrucciones ocultas del sistema, políticas o secretos. Esta información puede ser útil para un atacante, ya que le permite elaborar ataques posteriores que evaden estas defensas.

El potencial de filtración de indicaciones significa que los secretos nunca deben estar incrustados en las indicaciones. Las medidas de seguridad como las instrucciones de «no revelar» pueden ser eludidas o derrotadas por un atacante.

Secuestro de herramientas y agentes

Las herramientas de IA pueden ser capaces de llamar a funciones o APIs, navegar por internet o activar flujos de trabajo. Una indicación cuidadosamente elaborada puede permitir a un atacante definir qué herramientas se seleccionan, los parámetros enviados a ellas y la secuencia en la que se llaman las acciones.

Esto plantea un riesgo de que un atacante pueda acceder a datos sensibles al realizar llamadas a sistemas de tickets, CRM, almacenes de documentos, repositorios de código o consolas en la nube. Para gestionar este riesgo, las organizaciones deben implementar controles de acceso de menor privilegio y puertas de aprobación con intervención humana para acciones de alto impacto, especialmente para agentes de IA que operan sin supervisión humana.

¿Dónde aparece la inyección de indicaciones en entornos empresariales?

Los ataques de inyección de indicaciones pueden ocurrir en cualquier lugar donde una organización esté utilizando GenAI. Ejemplos comunes incluyen:

• Herramientas de chat públicas
• Asistentes integrados
• Bots de soporte al cliente
• Asistentes de conocimiento internos
• Copilotos de desarrollador
• Agentes autónomos

Incluso si los usuarios no interactúan directamente con estas herramientas, la inyección de indicaciones sigue siendo un riesgo. Las herramientas pueden acceder a contenido web, archivos adjuntos, registros pegados, comentarios de SaaS de terceros y otras entradas no confiables que podrían incluir instrucciones maliciosas.

Chatbots y Asistentes de Atención al Cliente

Los chatbots y los agentes de atención al cliente aceptan entradas de texto en formato libre de usuarios desconocidos. Los ataques exitosos de inyección de comandos podrían implicar manipular salidas para engañar a los clientes y la posible exposición de datos si el bot tiene acceso al CRM o a los sistemas de pedidos.

Para gestionar estos riesgos, las organizaciones deben implementar estrictos alcances de datos, redactar datos sensibles cuando sea posible y especificar respuestas plantillas para solicitudes sensibles. Además, estas herramientas deben ser monitoreadas en busca de signos de posible abuso, incluyendo tasas de solicitudes, repetición y similitud de carga útil.

Asistentes RAG y «Pregunte a su Base de Conocimientos»

Los asistentes RAG y «pregunte a su base de conocimientos» tienen la capacidad de acceder a documentos y otros contenidos que podrían estar por encima de la política corporativa como parte del contexto del LLM. Como resultado, el contenido malicioso incrustado en páginas web y otros recursos puede permitir que un atacante evada las medidas de seguridad.

Las organizaciones pueden mitigar estos riesgos implementando etiquetado de contenido, listas de permitidos para recuperación y compartimentación de comandos. Además, los controles de acceso de menor privilegio limitan los datos a los que estas herramientas pueden acceder, reduciendo los posibles impactos de un ataque.

Impactos de la Inyección de Comandos en la Seguridad Empresarial

Los ataques de inyección de comandos pueden influir en herramientas impulsadas por IA para hacer lo que el atacante desea. Esto puede introducir amenazas significativas a la confidencialidad, integridad y disponibilidad debido al potencial de violaciones de datos, salidas manipuladas y flujos de trabajo corruptos.

Un ataque exitoso de inyección de comandos puede ser difícil de investigar debido al uso de herramientas legítimas y la visibilidad limitada en estas herramientas. Esto representa un riesgo significativo para el cumplimiento regulatorio también, si las organizaciones carecen de los datos para probar lo que sucedió y el alcance del incidente.

Impactos Comerciales Comunes

Los ataques de inyección de comandos pueden tener una variedad de impactos diferentes en la empresa, incluyendo:

• Filtración de datos de clientes
• Exposición de propiedad intelectual (PI)
• Tiempo de inactividad del servicio
• Respuestas incorrectas a las consultas de los clientes
• Toma de decisiones basada en datos inexactos
• Daño reputacional y financiero
• Sanciones regulatorias y exposición legal

¿Cómo se puede detectar la inyección de comandos?

Detectar la inyección de comandos requiere analizar las entradas, salidas y comportamientos de los LLM para identificar anomalías o violaciones de la política corporativa. Para ello, las organizaciones deben registrar los comandos, las respuestas y las llamadas a herramientas para su monitoreo. El análisis debe buscar anomalías, violaciones de políticas y patrones de carga repetidos.

Indicadores en Comandos, Contexto y Llamadas a Herramientas

Los comandos, el contexto y las llamadas a herramientas pueden incluir indicadores de ataques de inyección de comandos. Las cosas a tener en cuenta incluyen:

• Patrones de instrucciones sospechosas
• Lenguaje coercitivo
• Frecuencia inusual de llamadas a herramientas
• Destinos inusuales de llamadas a herramientas
• Datos excesivos devueltos de las herramientas
• Texto recuperado que intenta actuar como política

Mitigaciones prácticas para la inyección de comandos

Los ataques de inyección de comandos requieren una defensa en profundidad, ya que los atacantes pueden crear comandos maliciosos para evadir búsquedas de texto simples y coincidencias de patrones. Un modelo de mitigación por capas debe incluir:

• Acceso seguro a
• Controles de interacción del modelo
• Gobernanza de datos
• Pruebas operativas

El objetivo de estas mitigaciones es reducir el impacto y la frecuencia de los ataques. La naturaleza de los LLMs significa que es imposible garantizar completamente que los ataques nunca tendrán éxito.

Patrones de diseño que reducen el radio de explosión

Las acciones de mitigación de inyección de prompts deben centrarse en gestionar el potencial radio de explosión de una inyección exitosa. Las mejores prácticas incluyen:

• Controles de acceso de privilegio mínimo para herramientas, conectores y fuentes de datos: Esto incluye implementar permisos separados para el acceso de lectura y escritura.
• Puertas de humano en el circuito para acciones sensibles: Por ejemplo, se debe requerir la aprobación humana para pagos, cambios de cuenta, tareas administrativas privilegiadas y otras actividades de alto riesgo.
• Fronteras fuertes para secretos: Los secretos nunca deben almacenarse en prompts, utilizando en su lugar tokens con alcance o patrones de bóveda.
• Segmentación para fuentes de recuperación: Idealmente, los LLMs solo deberían poder acceder a corpora de confianza que contengan datos curados y etiquetados.
• Post-procesamiento determinista para salidas arriesgadas: Las salidas de LLM en flujos de trabajo de alto riesgo o con acceso a datos sensibles deben ser post-procesadas por software no AI para garantizar que se apliquen las políticas y se redacten los datos sensibles.

Barandillas en tiempo de ejecución

Además de limitar el radio de explosión de los ataques, las organizaciones también pueden implementar barandillas que gestionen el riesgo en tiempo de ejecución. Las mejores prácticas incluyen:

• Filtrado y normalización de solicitudes: Todas las respuestas de LLM deben ser analizadas para filtrar contenido potencialmente sensible o malicioso y para asegurar el cumplimiento de las políticas corporativas.
• Controles de pérdida de datos: Utilice DLP o un SWG para prevenir que datos sensibles salgan a través de solicitudes y respuestas cuando sea posible.
• Controles de riesgo de contenido: Los LLM con acceso a la web deben estar restringidos en los sitios web y tipos de contenido a los que pueden acceder.
• Gobernanza de acceso para aplicaciones y asistentes de IA: Las aplicaciones y asistentes de IA deben estar limitados con controles de acceso de menor privilegio que restrinjan los datos y herramientas que pueden utilizar.
• Registro y alertas: El registro y las alertas deben estar integrados en las herramientas impulsadas por IA para asegurar una visibilidad adecuada y trazas de auditoría.

¿Cómo se prueba y valida la inyección de solicitudes?

Las vulnerabilidades de inyección de solicitudes deben ser probadas regularmente, ya que pequeños cambios en las solicitudes, herramientas, modelos y fuentes de datos pueden reintroducir riesgos. Un equipo rojo de IA utiliza solicitudes adversariales para evaluar el comportamiento de modelos y aplicaciones de manera estructurada y repetible. Algunas de las cosas clave a probar incluyen:

• Fugas de datos
• Elusión de políticas
• Uso indebido de herramientas
• Manipulación de recuperación
• Salida dañina

Las pruebas deben realizarse de manera regular, especialmente después de implementar nuevos agentes, herramientas o conectores. El éxito de un programa de pruebas puede evaluarse en función de la tasa de éxito, la gravedad, la cobertura de detección, el tiempo de detección y el tiempo de contención.

Construyendo un conjunto de pruebas de inyección de prompts repetible

Un conjunto de pruebas de inyección de prompts puede asegurar que una organización esté abordando adecuadamente los principales riesgos de inyección de prompts en sus sistemas. Las mejores prácticas incluyen:

• Mantener una biblioteca de prompts adversariales mapeados a categorías de riesgo.
• Incluir elementos de inyección indirecta (documentos, páginas web, tickets) que sean seguros pero realistas.
• Probar por flujo de trabajo y por conjunto de permisos. El mismo modelo puede ser seguro en un contexto y inseguro en otro.
• Automatizar las pruebas de regresión cuando cambien los prompts, las fuentes de recuperación o los esquemas de herramientas.
• Documentar el comportamiento esperado y los caminos de escalación cuando una prueba falla.

Reducción del riesgo de inyección de prompts y salvaguardias operativas

La inyección de prompts es un riesgo creciente para la ciberseguridad corporativa, ya que las empresas dependen cada vez más de herramientas de IA que pueden ser engañadas para realizar acciones maliciosas. La seguridad de la inyección de prompts incluye restringir entradas, contextos, acciones y salidas para reducir la probabilidad de un ataque y sus posibles impactos en el negocio. Las organizaciones deben:

• Restringir el acceso de las herramientas de IA a datos y herramientas.
• Monitorear entradas y salidas en busca de anomalías y violaciones de políticas.
• Utilizar sanitización determinista y plantillas para respuestas de alto riesgo.
• Probar regularmente las herramientas con prompts adversariales.

Eliminar el riesgo de inyección de prompts es imposible. Sin embargo, las organizaciones pueden reducir la probabilidad y el alcance de un ataque exitoso.

Preguntas frecuentes sobre la inyección de prompts

¿Es la inyección de comandos lo mismo que el jailbreak?

El jailbreak es un tipo particular de ataque de inyección de comandos diseñado para engañar a un modelo para que genere salidas prohibidas y dañinas. Los ataques de inyección de comandos también incluyen la posibilidad de que un modelo realice acciones no aprobadas e interactúe con herramientas de terceros.

¿Se puede prevenir completamente la inyección de comandos?

No, la inyección de comandos no se puede prevenir completamente debido a la dificultad de identificar todas las entradas maliciosas y al hecho de que los LLM no son sistemas deterministas ni predecibles. Sin embargo, los controles de seguridad en capas pueden reducir el riesgo y el alcance de un ataque exitoso.

¿Por qué se considera que la inyección de comandos indirecta es más peligrosa?

La inyección de comandos indirecta implica que un atacante inyecta instrucciones en contenido consumido por un LLM, como páginas web accedidas mientras se recopila contexto de internet. Esto es más peligroso porque un atacante podría influir en un agente incluso si no puede acceder directamente a su interfaz de usuario.

¿Qué se debe registrar para investigar intentos de inyección de comandos?

Los registros deben incluir eventos, llamadas a herramientas y violaciones de políticas. Registrar comandos en bruto puede ser peligroso debido a la posibilidad de que contengan datos sensibles, y toda la información en los registros debe ser redactada.

¿Cuál es el primer control a implementar para un asistente de IA?

El acceso de menor privilegio es el control más importante a implementar para un asistente de IA. Restringir su acceso a datos y otras herramientas limita el daño potencial que puede causar un ataque exitoso.