Cómo una página web aparentemente normal podría hacer que Grok filtre datos privados

Adversa AI ha descrito una técnica de inyección indirecta de instrucciones que, según el investigador Rony Utevsky, afectaría al agente web de Grok. En el escenario presentado, el usuario solo tendría que pedirle a Grok que resumiera o analizara una página controlada por un atacante. La web escondería las instrucciones dentro de datos cifrados y el agente sería inducido a descifrarlas y procesarlas en su propio entorno de ejecución.

El impacto potencial es grave: la carga descifrada podría ordenar al agente recuperar información privada de la sesión e incluirla en una solicitud dirigida a un servidor externo. Sin embargo, la evidencia disponible procede principalmente de la divulgación de Adversa AI y de informaciones relacionadas. Por tanto, debe entenderse como una prueba de concepto reportada, no como un hallazgo confirmado de forma independiente por xAI.

Qué cambia con la «inyección de contexto criptográfico»

Muchas defensas contra la inyección de instrucciones buscan frases sospechosas en el texto que recibe el modelo. La técnica descrita por Adversa intenta sacar las instrucciones maliciosas de ese circuito de inspección: las coloca en una página como texto cifrado. Según la empresa, la web incluye una carga JSON cifrada con AES-256-GCM, material para derivar la clave e indicaciones para que Grok ejecute el código de descifrado en su entorno de Python o sandbox.

No se presenta como un ataque criptográfico contra AES. El cifrado funciona aquí como una técnica de evasión: un filtro puede ver una secuencia opaca de datos, mientras que el agente dispone de las herramientas necesarias para convertirla de nuevo en instrucciones más adelante en el flujo de trabajo.

La diferencia es clave. Filtrar el texto visible no equivale a controlar lo que un agente puede hacer después de interpretar, descifrar, ejecutar o recibir datos procedentes de una fuente no confiable.

Así funcionaría la cadena del ataque

A grandes rasgos, el proceso tendría cuatro etapas:

1. La página parece normal. La víctima pide a Grok que resuma o analice el contenido de la web.
2. La página proporciona datos cifrados y una guía de descifrado. Adversa afirma que la carga utiliza AES-256-GCM con una clave derivada mediante PBKDF2, de modo que las instrucciones principales permanecen ocultas durante la inspección inicial.
3. Grok ejecuta la lógica de descifrado. Las instrucciones en texto claro aparecerían a través de la ruta de ejecución de código o herramientas del modelo, en lugar de figurar como texto evidente de la página original. Adversa sostiene que Grok trata entonces el resultado como contexto fiable.
4. La carga dirige la siguiente acción del agente. Según el informe, las instrucciones indican a Grok que resuelva datos privados de la sesión y los inserte en una URL que después abre para enviar la información a un endpoint controlado por el atacante.

La prueba de concepto descrita por Adversa incluía el nombre del usuario, su ubicación aproximada, el nivel de suscripción, sus prompts y el historial de conversaciones. La empresa afirmó que, en su demostración, la transferencia se completó sin una advertencia visible ni una solicitud de confirmación.

El verdadero perímetro de seguridad es el entorno de ejecución

El fallo central no sería simplemente que Grok recibiera un prompt malicioso. El problema estaría en que los datos de una página no confiable atravesarían varios límites de confianza:

• el contenido de una web se convertiría en contexto ejecutable o accionable;
• el resultado descifrado se consideraría más fiable de lo que permite su origen;
• la información privada de la conversación o de la sesión quedaría disponible para la cadena de ataque; y
• el agente podría utilizar una solicitud externa para sacar esos datos de la sesión.

Una instrucción no se vuelve fiable solo porque haya sido producida por una rutina de descifrado, devuelta por una herramienta o colocada en un resultado intermedio del entorno de ejecución. El origen de los datos debe conservarse durante todas esas transformaciones. De lo contrario, un atacante puede aprovechar el análisis, la ejecución de código, la recuperación de información o la salida de una herramienta para convertir contenido no confiable en una autoridad aparente.

Divulgación y estado conocido

De acuerdo con el relato de Adversa, Utevsky comunicó el problema a xAI y lo reportó a través de HackerOne el 3 de junio de 2026. En su divulgación del 20 de agosto, Adversa afirmó que el problema llevaba más de dos meses sin resolverse pese a los seguimientos realizados.

La información disponible no incluía una respuesta pública de xAI, un identificador CVE, un parche ni un calendario de corrección en el momento de la divulgación. Este estado se basa en el informe del investigador y en la cobertura publicada en esas fechas; aquí no se aporta una declaración de xAI publicada de forma independiente que confirme el hallazgo o su solución.

Qué habría que corregir

Las recomendaciones de Adversa se centran en el entorno de ejecución del agente, no únicamente en añadir más filtros de palabras clave. Entre los controles más importantes están:

• Conservar el origen y las etiquetas de confianza. El contenido procedente de una página debe seguir considerándose no confiable después de ser analizado, descifrado, ejecutado o procesado por una herramienta.
• Separar los datos de la autoridad. El contenido no confiable y los valores derivados de él no deberían poder activar herramientas privilegiadas, acceder al contexto privado de la conversación ni determinar argumentos sensibles.
• Restringir el tráfico saliente. Antes de enviar información a un nuevo destino externo, los agentes deberían aplicar listas de permitidos, controles de destino y políticas de prevención de pérdida de datos.
• Exigir un consentimiento comprensible. Las acciones que impliquen contexto privado o transmisión externa deberían requerir una confirmación clara del usuario, con una explicación de qué datos saldrán de la sesión y hacia dónde.
• Aplicar el principio de mínimo privilegio. Una tarea de resumen no debería conceder automáticamente acceso al historial completo de chats, los metadatos del perfil, la ejecución de código o una conexión de red sin restricciones.

Estos controles abordan la combinación especialmente peligrosa de entrada no confiable, contexto privado, ejecución de código y herramientas capaces de actuar. El comportamiento de rechazo del modelo, por sí solo, no constituye un límite de seguridad suficiente.

Cómo encaja con otros ataques contra agentes de IA

El caso de Grok forma parte de un patrón más amplio: los atacantes manipulan el contenido que el agente debe procesar y después aprovechan los permisos legítimos que el sistema ya tiene.

EchoLeak, una vulnerabilidad de Microsoft 365 Copilot, fue descrita como un ataque de inyección indirecta sin interacción del usuario en el que un correo electrónico preparado podía permitir la extracción remota y no autenticada de datos accesibles para el asistente. Un estudio académico identifica el problema como CVE-2025-32711.

En otro caso, investigadores describieron CoSnitch, una cadena que afectaba a Copilot Personal: un enlace preparado podía activar instrucciones y facilitar la extracción de datos de aplicaciones conectadas. Los investigadores afirmaron que Microsoft publicó parches el 18 de agosto de 2026.

Los agentes de programación presentan un riesgo parecido, aunque el vehículo suele ser un repositorio en lugar de una página web. Adversa informó de que repositorios maliciosos podían aprovechar la confianza y la configuración de varios asistentes de programación —entre ellos Claude Code, Cursor CLI, Gemini CLI y Copilot CLI— para ejecutar servidores MCP controlados por un atacante con privilegios potencialmente amplios. Otro informe de Adversa describió un bypass de políticas basado en repositorios, con cadenas largas de comandos de shell y posible robo de credenciales o secretos.

El mecanismo de entrega cambia —correo electrónico, URL, documento, repositorio, página cifrada o integración de herramientas—, pero la lección arquitectónica es la misma: un agente no debe transformar contenido controlado por un atacante en permiso para leer datos confidenciales o realizar una acción externa.

La implicación de fondo

La «inyección de contexto criptográfico» muestra por qué la seguridad de los agentes no puede limitarse a revisar el texto que entra primero en la ventana de contexto. Las instrucciones pueden aparecer después de un descifrado, una recuperación de información, un análisis, una ejecución de código, un acceso a memoria o una llamada a otra herramienta. Si cada transformación borra el origen de los datos, el atacante puede explotar la distancia entre aquello que el sistema clasifica inicialmente como no confiable y aquello que el entorno de ejecución termina tratando como fiable.

Para los usuarios, la lección práctica es actuar con cautela al pedirle a un agente con acceso a conversaciones privadas o herramientas que procese páginas, documentos, enlaces o repositorios desconocidos. Para los desarrolladores, la prioridad es más exigente: reforzar los límites de confianza del entorno de ejecución, limitar el acceso al contexto sensible, restringir los parámetros de las herramientas, controlar las conexiones salientes y hacer visibles y confirmables las acciones de alto impacto.

Por eso, la técnica reportada contra Grok debe entenderse menos como una forma de «romper AES» que como una advertencia sobre el blanqueo de autoridad. El contenido cifrado puede ocultar una instrucción frente a un filtro, pero solo un entorno de ejecución demasiado permisivo puede convertir esa instrucción oculta en una acción de robo de datos.