Ataques de homoglifos a agentes autónomos de IA: un carácter conduce al phishing y la ejecución remota

Technical Context

Los ataques de homoglifos (homoglyph / homograph) son una clase de vulnerabilidades donde un atacante reemplaza caracteres en el texto con caracteres Unicode visualmente similares de otro alfabeto o rango. Un humano, y (lo que es peor) un agente autónomo basado en LLM, a menudo perciben la cadena "como la misma", aunque a nivel de bytes y semántica son tokens, dominios o comandos diferentes. Un ejemplo clásico: microsoft.com vs miсrosoft.com, donde la "c" puede ser la "с" cirílica (U+0441).

¿Por qué es esto especialmente peligroso para los sistemas agénticos (agentes autónomos, uso de herramientas, RPA+LLM)? Porque tienen "manos": acceso al navegador, terminal, Git, CRM, pagos y APIs internas. Si un agente reconoce incorrectamente una URL o comando, puede navegar a un enlace, descargar un binario, ejecutar un script o enviar secretos a un endpoint falso por sí mismo.

La Causa Técnica: Divergencia entre Representación Visual y de Máquina

• Unicode confusables: Diferentes puntos de código parecen idénticos (cirílico/latino, símbolos matemáticos, formas de ancho completo).
• Falta de normalización estricta antes de la tokenización: El LLM ve un conjunto diferente de tokens, mientras que el entorno (bash/navegador/parser de URL) interpreta la cadena de manera diferente a lo que el desarrollador esperaba.
• Fusión con RAG/Memoria del Agente: Un "hilo comprometido" o una nota en la base de conocimientos puede contener enlaces/comandos sustituidos que el agente luego reproduce como "verificados".
• Fallo de filtros ingenuos: Las expresiones regulares simples para "prohibir cirílico" no detectan variantes de ancho completo o matemáticas; permitir Unicode sin reglas abre la puerta a la mezcla de scripts.

Dónde se Manifiesta la Vulnerabilidad en la Arquitectura del Agente

• Manejo de URLs: El LLM genera o selecciona un enlace; el navegador/cliente HTTP va a un dominio diferente (IDN/punycode).
• CLI / bash: El agente copia un comando "seguro" del texto, pero algunos caracteres no son ASCII; resultado: un comando/parámetros/ruta diferente.
• Llamada a herramientas (Tool calling): Los parámetros para una herramienta (por ejemplo, URL de webhook, git remote, bucket S3) parecen correctos visualmente pero apuntan a un recurso atacante.
• Ingestión RAG: Los documentos con homoglifos envenenan el índice; al recuperar la información, el agente recibe una acción "autorizada" que conduce a una suplantación.

Signos Prácticos en Datos y Logs

• En los logs de acciones del agente, el dominio/cadena parece correcto, pero al copiarlo en una vista hex/Unicode, se revelan diferentes puntos de código.
• Activaciones de DLP/antivirus "de la nada" porque el agente descargó una carga útil (payload) de un dominio duplicado.
• Anomalías de DNS: Solicitudes a dominios punycode (xn--...), especialmente si se esperaban zonas estrictamente corporativas.

Un matiz aparte: "el análisis de bytecode es mejor mediante búsqueda de firmas"; esto es cierto para la protección. Si su agente ejecuta artefactos (scripts, binarios, WASM, contenedores), las firmas de bytes y los hashes de lista blanca son más resistentes a la suplantación visual que las comprobaciones de texto. Pero esto no elimina la necesidad de sanitizar las cadenas de entrada, ya que la mayoría de los ataques comienzan precisamente con texto (URL/comando/ruta).

Business & Automation Impact

Para el negocio, esto no es "otra vulnerabilidad Unicode rara", sino un riesgo directo para la automatización con IA y los procesos donde un agente realiza acciones sin supervisión humana constante. Los homoglifos convierten el texto "verificado" en un canal de entrega para phishing y ejecución de comandos, de una manera que ni un empleado ni un modelo pueden notar.

Qué Escenarios son Más Peligrosos

• Finanzas y Compras: El agente procesa facturas/correos electrónicos, extrae enlaces de pago/portales de proveedores y se dirige a un dominio duplicado.
• Procesos Legales y firma electrónica: Enlaces falsos a documentos y firmas donde el dominio coincide visualmente.
• Agentes de IT/DevOps: Herramientas que "arreglan producción", ejecutan comandos en la terminal, cambian configuraciones, conectan repositorios: una superficie de ataque ideal.
• Soporte al Cliente: El agente ofrece al usuario un "enlace oficial", pero lo extrae de una base de conocimientos envenenada.

Qué Cambia en la Arquitectura si va en Serio con la IA Agéntica

Si antes la seguridad de LLM a menudo se reducía a la inyección de prompt y políticas de acceso a herramientas, los ataques de homoglifos requieren otra capa: procesamiento estricto de cadenas en la entrada y salida antes de pasar al navegador/CLI/API.

• Compuerta antes del LLM: Normalización Unicode, detección de mezcla de scripts, filtrado de caracteres invisibles, reglas de umbral.
• Compuerta antes de Herramientas: Validación separada para URLs/rutas/comandos, no un "sanitizador universal".
• Política de Dominios: Lista blanca de dominios corporativos y de socios, bloqueo de navegación IDN sin confirmación manual.
• Observabilidad: Registro en forma canónica (por ejemplo, punycode + lista de puntos de código para cadenas sospechosas) para investigaciones.

Quién gana con la protección adecuada: Empresas que ya han lanzado la implementación de IA en procesos de negocio y quieren escalar sin aumentar el riesgo. Quién está en riesgo: Equipos que dieron al agente "acceso a todo" esperando que el LLM "se las arregle como un humano", limitando la seguridad solo al prompt del sistema.

En la práctica, las empresas tropiezan aquí precisamente porque este problema se encuentra entre capas: los desarrolladores piensan en el LLM, los equipos de seguridad en la red y los endpoints, mientras que los homoglifos explotan la brecha en el procesamiento de texto. Hasta que no surja una disciplina separada —Arquitectura de Soluciones de IA— donde las cadenas (URL/CLI/identificadores) se traten como datos críticos y pasen por una tubería estricta.

Expert Opinion Vadym Nahornyi

El principal error en proyectos agénticos: asumir que el texto es "seguro por defecto" si parece seguro. Los ataques de homoglifos no tratan sobre la inteligencia del modelo; tratan sobre la higiene de ingeniería: normalización, reglas estrictas de URL/CLI y contornos de confianza separados para la UI humana y la ejecución de la máquina.

En Nahornyi AI Lab, vemos un patrón recurrente: las empresas arman rápidamente una PoC de agente, le dan un navegador y terminal, conectan RAG, y solo entonces comienzan a pensar en la validación de cadenas. Como resultado, un solo "hilo comprometido" en un chat corporativo o una página infectada en la base de conocimientos es suficiente para que el agente comience a reproducir enlaces maliciosos como "recomendados".

Qué Funciona Realmente (y Qué No)

• Funciona: Normalización Unicode (NFC/NFKC según corresponda), detección de mezcla de scripts (Latino+Cirílico), bloqueo de caracteres invisibles, política IDNA/punycode y una lista blanca estricta de URLs para herramientas críticas.
• Funciona: Validadores separados para tipos de datos: URL, email, nombre de host, ruta, argumentos CLI. La "limpieza de texto" universal casi siempre da una falsa sensación de seguridad.
• Funciona: Verificación de doble canal para acciones de alto riesgo; por ejemplo, el agente muestra al usuario la forma canónica del dominio (pinyin/punycode) y pide confirmación.
• No Funciona: "Prohibir cirílico en todas partes". Romperá procesos legítimos (nombres, direcciones, documentos) pero aún así se perderá análogos de ancho completo/matemáticos y algunas evasiones.
• No Funciona: Esperar un "modelo más inteligente". Incluso si los modelos individuales son más robustos, los ataques a menudo golpean el preprocesamiento y las herramientas alrededor del LLM.

Mínimo Práctico para Agentes Autónomos en Producción

• Normalización de Entrada antes del LLM y normalización de salida antes de la ejecución de herramientas.
• Mapeo de Confusables (tablas de confusables Unicode) + reglas sobre mezcla de scripts en identificadores.
• Políticas de URL: Prohibición de IDN por defecto o permiso solo para dominios aprobados; registro en punycode.
• Modo Seguro de CLI: Plantillas de comandos, prohibición de shell arbitrario, escape de argumentos, ejecución a través de envoltorios de API en lugar de bash crudo.
• Higiene RAG: Sanitización durante la ingestión, marcado de fuentes, cuarentena para documentos externos.

Mi pronóstico: esto no será una "vulnerabilidad de moda por una semana", sino una clase permanente de problemas durante años, porque los sistemas de agentes inevitablemente trabajan con texto de fuentes no confiables. Los ganadores serán aquellos que integren la protección en la tubería y la conviertan en un estándar de componente, tal como WAF y SAST se convirtieron en la norma.

La teoría es útil, pero los resultados requieren práctica. Si está construyendo agentes autónomos, RAG o automatizando con IA en finanzas, soporte o DevOps, discutamos su proyecto en Nahornyi AI Lab. Diseñaremos contornos de confianza, sanitización y reglas de ejecución de herramientas para que la IA acelere el negocio en lugar de crear un nuevo canal de compromiso. Respondo personalmente por la calidad de la implementación — Vadym Nahornyi.