Google comunicó que no emitirá un parche específico contra el ASCII smuggling en Gemini, una técnica que inserta instrucciones invisibles para el usuario mediante caracteres del bloque Unicode Tags, pero legibles por modelos de lenguaje. La posibilidad de manipular el comportamiento del asistente y de introducir datos maliciosos de forma encubierta eleva el riesgo en entornos empresariales, especialmente cuando las LLM se integran con correo y calendarios corporativos.
ASCII smuggling en LLM: qué es y por qué representa un riesgo
El ataque explota un desajuste fundamental: lo que el usuario ve en la interfaz no coincide con lo que la LLM interpreta. Los caracteres del plano de etiquetas de Unicode (Unicode Tags) permiten “empaquetar” una carga útil no visible en pantalla pero sí procesable por el modelo. Esta táctica se alinea con la familia de prompt injection y encaja con la categoría LLM01 de OWASP Top 10 for LLM, que advierte sobre instrucciones ocultas y manipulación del contexto de entrada.
Resultados de pruebas: modelos afectados y resiliencia
El investigador Victor Markopoulos (FireTail) validó la técnica en varias LLM. Según su evaluación, Gemini es susceptible a través de mensajes e invitaciones de calendario, DeepSeek a través de prompts directos y Grok mediante publicaciones en X. En contraste, Claude, ChatGPT y Microsoft Copilot mostraron mayor resistencia gracias a procesos de input sanitization que filtran o normalizan la entrada. Los resultados subrayan la importancia de la higiene de datos previa al procesamiento del modelo.
Google Workspace como vector: correo y calendario en el punto de mira
Instrucciones ocultas en asuntos e invitaciones
La integración de Gemini con Google Workspace amplifica el riesgo. Es posible insertar instrucciones invisibles en el asunto o la descripción de una reunión, así como en el cuerpo de un correo. Con ello, el asistente podría tomar como válidos metadatos falsos, incluir descripciones alteradas de eventos o priorizar enlaces sesgados al generar respuestas.
De la ingeniería social a la automatización del fraude de datos
Si la LLM tiene acceso al buzón, basta con un correo con comandos ocultos para inducir búsquedas de mensajes sensibles o la recolección de contactos. Esta evolución del phishing tradicional introduce un componente semiautomatizado que reduce la necesidad de interacción del usuario y acelera la progresión del incidente.
Ejemplo práctico: manipulación de recomendaciones
En una demostración de FireTail, una instrucción invisible llevó a Gemini a recomendar un sitio “ventajoso” para comprar un teléfono, canalizando al usuario hacia un destino potencialmente riesgoso. La pérdida de confianza en las recomendaciones del asistente impacta directamente en la toma de decisiones de los empleados y en la seguridad de la navegación corporativa.
Postura de Google y señales del mercado
El 18 de septiembre de 2025, Markopoulos notificó el hallazgo a Google. La compañía lo clasificó como un caso de ingeniería social, no como vulnerabilidad técnica. La decisión refleja un debate sectorial sobre los límites de responsabilidad entre proveedores de LLM y contextos de uso. Otros actores adoptan una visión más preventiva: Amazon ha publicado recomendaciones prácticas contra el encubrimiento mediante Unicode, enfatizando la sanitización, la normalización y la retirada de códigos de control. Esta orientación converge con la tendencia de “seguridad por defecto” en integraciones con LLM.
Medidas de mitigación para desarrolladores y organizaciones
Sanitización de entrada: eliminar caracteres del bloque Unicode Tags, símbolos de ancho cero y controles Bidi (categoría Cf); aplicar allow-lists estrictas por campo (asunto, descripción de evento, remitente).
Normalización y canonicidad: estandarizar el texto (por ejemplo, NFC) y filtrar explícitamente caracteres invisibles o de formato; registrar y alertar sobre anomalías detectadas.
Aislamiento de contexto: separar fuentes confiables de las no confiables para la LLM; limitar acciones automáticas (leer/reenviar correos, acceso a contactos) y exigir confirmación del usuario.
Visualización de lo invisible: validadores de UI que destaquen caracteres ocultos en campos críticos y verificación reforzada de URLs y dominios mediante navegación segura.
Monitoreo y pruebas continuas: incorporar escenarios de prompt injection y Unicode smuggling en CI/CD; ejercicios de red teaming; capacitación del SOC para reconocer patrones de abuso específicos de LLM.
El ASCII smuggling evidencia la brecha entre la interfaz humana y la interpretación automática del texto. Aunque Google no lo trate como vulnerabilidad, las organizaciones deben actuar con antelación: filtrar Unicode por defecto, restringir permisos de los asistentes, aislar contextos y reforzar la inspección de enlaces. Adoptar estas prácticas hoy reducirá significativamente la superficie de ataque en correo, calendarios y procesos críticos impulsados por LLM.
