Contenido web que hace pagar a los agentes: inyección indirecta en el mundo real

¿Qué es esto?

El 2 de julio de 2026, Zscaler ThreatLabz publicó un análisis de dos campañas reales que ocultan instrucciones en páginas web de apariencia normal para manipular agentes de IA autónomos: los que navegan por la web y pueden actuar, por ejemplo instalar un paquete o realizar un pago. Es inyección indirecta de prompts (IPI): el atacante no habla directamente con el modelo, sino que planta instrucciones en el contenido que el agente va a leer y espera a que el agente trate ese contenido como si fuera una orden.

Lo que distingue a estas campañas es que no son una demostración de laboratorio. Están activas en el mundo real, apuntan específicamente a los agentes y una de ellas termina con fondos saliendo de una cartera. La noticia fue recogida por SecurityWeek, Crypto Briefing e Infosecurity Magazine en los días siguientes.

Cómo funciona

La primera campaña se hace pasar por un paquete de Python. El atacante publica una página de documentación de una biblioteca inexistente y luego recurre al envenenamiento SEO —HTML cargado de palabras clave ligadas al módulo falso— para que la página aparezca cuando un agente busca ayuda de instalación o de resolución de dependencias. Una vez que el agente llega a la página, la instrucción inyectada le indica que obtener una «clave de API de desarrollador» exige un pequeño pago (presentado en torno a 3 USD, codificado on-chain como una fracción de ETH) hacia una cartera fijada en el código.

Se superponen tres técnicas de entrega:

Capa             Propósito
---------------  -------------------------------------------------------
SEO envenenado   Colocar la página delante del agente en primer lugar
DOM oculto CSS   Instrucciones invisibles para humanos (p. ej. fuera de
                 pantalla) pero presentes para parseadores y agentes
Schema JSON-LD   Un objeto «offers» estructurado que presenta el pago
                 como un paso de licencia legítimo y legible por máquina

La instrucción en sí aparece aquí como [REDACTED]: lo relevante es el mecanismo, no el guion. La página también muestra opciones de pago con tarjeta y con cripto a un visitante humano, de modo que funciona además como página de estafa clásica. Zscaler vincula la operación a un conjunto de repositorios de GitHub que apuntan a sitios similares.

La segunda campaña es más discreta pero posiblemente más grave. Un dominio typosquatting imita a un conocido rastreador de carteras DeFi y luego rellena su título, metaetiquetas, datos Open Graph y tarjetas sociales con las palabras clave de la marca real. Un texto inyectado afirma a cualquier agente que lo lea que ese dominio fraudulento es el legítimo. No hay paso de pago: el objetivo es que el agente respalde el sitio falso como de confianza y deje que la víctima se comprometa después.

Para medir el impacto, Zscaler construyó un agente con navegación y capacidad de ejecución de pagos y lo enfrentó a ambos señuelos en 26 modelos. Cuatro fueron manipulados hasta enviar realmente el pago fraudulento, y otros dos respaldaron el sitio typosquatting como la plataforma auténtica. Ningún modelo era uniformemente inmune, y la susceptibilidad variaba mucho entre familias.

Por qué importa

El importe en dólares es deliberadamente trivial. La lección estructural no lo es: el contenido web recuperado es ahora una superficie de ejecución. Un agente capaz de pagar, instalar o hacer clic trata la página que lee como dato y como posible instrucción, y los modelos actuales no mantienen de forma fiable esa frontera. El mismo patrón que envía 0,0012 ETH se extiende a aprobar una transacción, exfiltrar un secreto o instalar una dependencia envenenada.

Dos propiedades lo hacen peligroso a escala. Primero, es pasivo: el atacante publica una página y espera, con el SEO haciendo la focalización. Segundo, es invisible para el humano en el bucle: el CSS oculta la carga y un agente «autónomo» o en modo «actuar sin preguntar» elimina al humano por completo. La variante de typosquatting muestra la cara más suave del mismo problema: incluso sin pago, un agente que avala un sitio malicioso lava la confianza del atacante convirtiéndola en confianza del usuario.

Defensas

Ningún parche del lado del modelo cierra esto, así que la defensa es arquitectónica.

Mantenga una frontera de confianza estricta entre las instrucciones del agente y cualquier contenido que recupere: trate páginas web, documentos y fragmentos de búsqueda como datos no confiables, nunca como órdenes. Analice todo el DOM renderizado, incluidos los nodos ocultos por CSS o fuera de pantalla y los metadatos estructurados (JSON-LD, Open Graph), y marque las páginas donde el texto oculto difiera de lo que ve un humano. Coloque toda acción de consecuencia —pagos, transferencias, instalación de paquetes, uso de credenciales— tras una autorización explícita de mínimo privilegio y una confirmación humana; un agente con una cartera con fondos y el modo «actuar sin preguntar» es un riesgo permanente. Limite los pagos con destinatarios en lista blanca y topes de gasto estrictos, en lugar de confiar en el juicio del agente página por página. Para la confianza de marca y dominio, verifique contra una lista blanca de dominios conocidos y fiables en vez de dejar que una página afirme su propia identidad. Por último, registre y revise las llamadas a herramientas y las transacciones salientes del agente para que una acción envenenada se detecte a posteriori aunque se cuele, y alimente los indicadores conocidos (abajo) en sus listas de bloqueo.

Estado

Elemento	Detalle
Divulgación	Zscaler ThreatLabz, 2 de julio de 2026
En el mundo real	Sí — dos campañas activas, más ~10 repositorios de GitHub vinculados
Modelos probados	26; 4 ejecutaron el pago, 2 avalaron el sitio falso
Corrección	Sin parche único — mitigaciones arquitectónicas (ver Defensas)
Indicadores	Paquete falso requests-secure-v2; typosquat debank[.]auction; cartera 0x691bc3793205e574fa7b4aa068e62c0e470ad267