Asegurando el modelo de lenguaje extenso antes de la próxima brecha de inyección de prompts

El mes pasado, revisé un informe forense donde una empresa de servicios financieros perdió el control de un bot interno de atención al cliente. La firma contaba con una infraestructura de seguridad de vanguardia; sin embargo, una sola frase ingeniosamente redactada en un ticket de soporte logró evadir todas las protecciones. Este es el paradoja arquitectónica de la IA moderna. Envolvemos estos modelos en capas de seguridad tradicional, pero no logramos abordar la vulnerabilidad principal: el modelo es incapaz de separar los datos no confiables de las instrucciones confiables. CrowdStrike codificó recientemente este problema en cinco nuevos vectores de ataque distintos que todo arquitecto de seguridad debe comprender.

Pasé la mañana de ayer en mi laboratorio intentando replicar una de estas técnicas en una versión localizada de Llama 3. La simplicidad del exploit es lo que lo hace peligroso. Desde una perspectiva de riesgo, nos encontramos actualmente en el Salvaje Oeste de la IA generativa. Las cinco nuevas amenazas de inyección de prompts identificadas por CrowdStrike demuestran que los atacantes están yendo más allá de los simples comandos de "ignora todas las instrucciones anteriores". Ahora utilizan manipulación lingüística y entrega en múltiples etapas para comprometer los sistemas.

El colapso del límite entre datos e instrucciones

La inyección de prompts existe debido a la forma en que los modelos de lenguaje extensos procesan la información. En el software tradicional, el código y los datos suelen mantenerse en espacios de memoria separados. Una base de datos SQL no ejecuta accidentalmente el apellido de un usuario como un comando, a menos que exista una vulnerabilidad específica como la inyección SQL. En un LLM, las instrucciones del desarrollador y los datos del usuario residen en la misma ventana de contexto. El modelo trata cada token con un peso similar.

Esta falta de separación convierte el perímetro de red en un foso de castillo obsoleto. Si permites que un LLM lea un correo electrónico, esencialmente le estás dando a ese correo un asiento frente al teclado. Los atacantes explotan este diseño incrustando instrucciones dentro de los datos que el modelo eventualmente procesa como una directiva. La nueva taxonomía de CrowdStrike proporciona un mapa de cómo estos atacantes están evolucionando sus métodos para mantenerse por delante del filtrado básico de palabras clave.

Amenazas latentes mediante reglas activadas por disparadores

La primera técnica nueva es la adición de reglas activadas por disparadores (trigger-activated rule addition). En este escenario, un atacante no intenta romper el modelo de inmediato. En su lugar, introduce una nueva regla que parece inofensiva. Por ejemplo, el atacante podría decirle al modelo que siempre resuma el texto en un formato específico si ve la palabra "pájaro azul". Por sí solo, esto no es una brecha; parece una personalización menor.

Sin embargo, el atacante puede activar esta regla más tarde para causar un comportamiento extraño o malicioso. La regla actúa como un agente durmiente. Una vez que se activa el disparador, el modelo podría redirigir su salida a una API no autorizada o comenzar a filtrar prompts del sistema sensibles. Debido a que la adición de la regla inicial es inocua, pasa a través de la mayoría de los sistemas de detección básicos. La amenaza permanece latente hasta que se cumplen las condiciones específicas. Evaluar la superficie de ataque requiere buscar estas sentencias ocultas de "si-entonces" enterradas en historiales de conversación a largo plazo o en las instrucciones del sistema.

Rompiendo el filtro con la supresión cognitiva de tokens

La supresión cognitiva de tokens (cognitive token suppression) es un enfoque más técnico para eludir las medidas de seguridad. La mayoría de los LLM tienen patrones de rechazo integrados. Si le pides a un modelo que te ayude a escribir malware, está entrenado para decir algo como "No puedo ayudar con esa solicitud". Los equipos de seguridad a menudo confían en estos patrones de rechazo establecidos para mantener el modelo seguro.

Un atacante que utiliza la supresión cognitiva de tokens aleja las opciones lingüísticas del modelo de estos patrones. Podrían usar restricciones complejas que prohíban al modelo usar las palabras "no puedo", "rechazo" o "política". Al despojar al modelo de su capacidad para decir no de la manera habitual, el atacante obliga al LLM a entrar en un estado en el que es más probable que cumpla con una solicitud maliciosa. Es una forma de esposas lingüísticas. El modelo se ve obligado a encontrar un camino a través de la solicitud que evite su entrenamiento de seguridad. En consecuencia, el filtro de seguridad falla porque el modelo ya no tiene acceso al vocabulario que necesita para expresar un rechazo.

Ocultando la carga útil mediante descomposición algorítmica

La descomposición algorítmica de la carga útil (algorithmic payload decomposition) es un ataque que se basa en la capacidad del modelo para ensamblar ideas complejas a partir de partes simples. Un atacante entrega un mensaje en múltiples etapas. Cada etapa es inocente cuando se ve de forma aislada. Un prompt puede pedirle al modelo que almacene una cadena específica de caracteres. Un segundo prompt puede pedirle que defina una función determinada.

Cuando se combinan, estas piezas se ensamblan en un solo comando que resulta amenazante. Este es el caballo de Troya digital de la inyección de prompts. Las herramientas de seguridad que escanean prompts individuales en busca de intenciones maliciosas no verán nada malo. La amenaza solo surge a nivel arquitectónico cuando el modelo integra todas las piezas. He visto esto funcionar eficazmente en entornos donde la ventana de contexto es lo suficientemente grande como para contener varias interacciones aparentemente no relacionadas que eventualmente forman una cadena de explotación completa.

El riesgo de la inyección de tokens especiales

La inyección de tokens especiales es una técnica que apunta a los interruptores de control del LLM. Los modelos utilizan tokens especiales para marcar el final de un pensamiento o el inicio de una instrucción del sistema. Estos tokens son como los botones en el panel de control de un piloto. Si un atacante puede inyectar estos tokens en su propia entrada, puede engañar al modelo para que piense que el contenido del usuario es en realidad una directiva del sistema de alta prioridad.

Este ataque introduce una confusión que engaña al modelo para elevar el contenido no confiable del usuario. Es un asalto directo a la lógica interna del modelo. Al falsificar estos interruptores de control, el atacante gana la capacidad de sobrescribir las instrucciones originales del desarrollador. El modelo comienza a tratar al atacante como el administrador. Esto es especialmente peligroso para los modelos que están conectados a herramientas o bases de datos externas. Una vez que el modelo cree que el atacante es una voz del sistema confiable, ejecutará acciones con privilegios elevados.

Engañando al usuario con la inyección de datos de contexto

La inyección involuntaria de datos de contexto por parte del usuario es quizás la amenaza más generalizada en esta nueva lista. Este exploit aprovecha el límite entre los datos confiables y las instrucciones ejecutables. El usuario es quien introduce la instrucción maliciosa, pero lo hace sin saberlo. Esto sucede cuando un usuario carga un documento, reenvía un correo electrónico o agrega contenido web que la IA procesa posteriormente.

Detrás de escena, la instrucción maliciosa está oculta dentro del documento o correo electrónico. El prompt que escribe el usuario puede ser inofensivo, como "resume este PDF". El PDF en sí contiene una línea de texto oculta que le dice al modelo que ignore el resumen y, en su lugar, envíe el token de sesión del usuario a un servidor externo. El usuario es el vehículo de entrega del ataque. En términos de integridad de datos, esto es una pesadilla. Significa que cada pieza de información que toca un LLM es un vector potencial de compromiso.

Construyendo una arquitectura de defensa resiliente

Los equipos de seguridad pueden protegerse contra tales ataques de varias maneras. Hablando proactivamente, el primer paso es el modelado de amenazas en cada lugar donde pueda originarse el contexto del modelo. Debe tratar cada entrada como un activo tóxico. Esto incluye archivos cargados por usuarios, correos electrónicos recuperados de una bandeja de entrada y datos extraídos de bases de datos internas.

CrowdStrike recomienda ampliar las pruebas para incluir estos cinco vectores específicos. El red teaming debe centrarse en ataques compuestos en lugar de fallos de un solo prompt. Es necesario ver si su modelo puede ser engañado por descomposición o supresión. Dejando a un lado los parches, la solución real es la ingeniería de detección granular. Necesitamos sistemas que puedan monitorear el estado interno del modelo y alertar cuando comience a ignorar sus instrucciones principales.

Se debe aplicar el Zero Trust a los datos que fluyen hacia el LLM. Piense en ello como un portero de un club VIP en cada puerta interna. Nunca confíe en los datos, incluso si provienen de un usuario autenticado. El portero debe verificar que el contenido no contenga instrucciones ocultas antes de que se le permita entrar en la ventana de contexto del modelo. Esta es la única forma de construir un sistema resiliente que pueda resistir la próxima generación de inyecciones de prompts.

Desde una perspectiva forense, también debe mantener registros detallados de la ventana de contexto completa para cada interacción. En caso de una brecha, estos registros son de misión crítica para comprender cómo un atacante eludió sus filtros. Si solo registra la salida final, se está perdiendo la parte más importante de la cadena de ataque.

Conclusiones clave para los líderes de seguridad

• Auditar las fuentes de contexto: Identifique todas las entradas de datos que llegan a sus LLM y trátelas como instrucciones no confiables.
• Probar derivaciones lingüísticas: Utilice el red teaming para ver si su modelo es vulnerable a la supresión cognitiva de tokens o a la descomposición algorítmica.
• Monitorear tokens especiales: Implemente filtros que detecten y eliminen los tokens de control de los datos proporcionados por el usuario.
• Educar a los usuarios sobre los riesgos del contexto: Informe a los empleados que resumir documentos no confiables puede llevar a un compromiso del sistema.
• Implementar ingeniería de detección: Vaya más allá de la simple coincidencia de palabras clave y comience a buscar anomalías de comportamiento en las respuestas del modelo.

La IA es una herramienta poderosa, pero también es un nuevo tipo de superficie de ataque. Al comprender estas cinco nuevas amenazas, puede comenzar a construir una defensa que sea tan inteligente como los modelos que intenta proteger.

Fuentes: CrowdStrike Falcon Intelligence, NIST AI Risk Management Framework, MITRE ATLAS.

Descargo de responsabilidad: Este artículo es solo para fines informativos y educativos y no reemplaza una auditoría de ciberseguridad profesional o un servicio de respuesta a incidentes.