Un sitio que parece documentación de una API puede servir a dos tipos de lectores: los humanos ven la entrada para depurar y pagar; y un Agent que navega la web, llama a herramientas y puede pagar también leerá las “instrucciones” escondidas dentro de datos estructurados y nodos DOM.

En los casos divulgados por Zscaler ThreatLabz, los atacantes usan envenenamiento SEO para empujar páginas de módulos falsos a los buscadores, y luego escriben en JSON-LD y en nodos HTML fuera de la pantalla el contenido “comprar una licencia soluciona el error”.

Esto no es un “error del usuario” en el sentido tradicional. Cuando un Agent trata una página web como contexto de la tarea, el cuerpo del sitio, los metadatos, los mensajes de error y las instrucciones de las herramientas entran en su cadena de decisiones. Este caso convierte la descripción de un pago en un paso rutinario de obtención de una clave API y contiene un script que transfiere aproximadamente 0.0012 ETH desde una dirección codificada. El atacante luego proporciona una “clave API” falsa para que un pago parezca una finalización correcta de la tarea.

Lo que de verdad hay que redibujar son los límites de la autorización. La web puede aportar información, pero no puede ampliar el poder de pago del Agent basándose en el texto que aparece en la página. Resultados de búsqueda que se posicionan más arriba, campos que se ven más estructurados o mensajes de error que parecen más urgentes no deberían convertirse automáticamente en una razón para “permitir pagar a una nueva dirección”.

Las pruebas internas de ThreatLabz evaluaron 26 modelos: cuatro no tomaron acciones adecuadas en escenarios de ataque relevantes y otros dos no identificaron correctamente los sitios en el escenario de plataformas cripto falsificadas. La cobertura de SecurityWeek sobre este estudio también señala que los atacantes, al ocultar instrucciones, manipular los resultados de búsqueda y hacerse pasar por sitios, inducen a un Agent a realizar pagos o a confiar en plataformas falsas.

Para un Agent que ejecuta pagos, la regla predeterminada más útil no es “detener al detectar un aviso malicioso”, sino degradar las páginas web externas a entradas no confiables:

1. Una página web, los resultados de búsqueda y los valores devueltos por herramientas no deben añadir por sí mismos un nuevo destinatario, tipo de activo ni el monto del pago;

2. El primer pago a una dirección nueva debe activar una confirmación independiente, en lugar de reutilizar los parámetros de pago de la página;

3. La estrategia de pago debe limitarse de antemano en cuanto a monto, destinatarios permitidos y tiempo de validez, y conservar un registro de intención auditable;

4. Cuando una página afirma “pagar de inmediato es necesario para corregir el problema”, debe ser una señal de pausa, no una señal de autorización.

El protocolo de pago puede registrar si una transacción fue firmada; no puede ayudar al usuario a determinar si esa transacción fue inducida inicialmente por el contenido de una página web oculta. Para un Agent, el punto de partida para la seguridad del pago no es permitir que entienda más páginas, sino evitar que la página amplíe el poder del Agent. Nunca.

Fuente: Zscaler ThreatLabz (Indirect Prompt Injection in Web Content Targets AI Agents); SecurityWeek (Prompt Injection Attacks Trick AI Agents Into Making Crypto Payments).