Tu agente de IA puede enviar dinero al destinatario equivocado; no es un fallo, sino una característica del protocolo.

Cuando la inteligencia artificial obtiene el derecho a elegir servicios y transferir dinero por sí misma, el punto débil puede no estar en el modelo sino en las reglas con las que los agentes se comunican entre sí. Un especialista de la Universidad Ariel encontró 33 vulnerabilidades en tres plataformas para comercio automatizado con participación de IA y mostró que muchos ataques funcionan independientemente de la calidad del modelo.

La comprobación abarcó CoralOS, Fetch.ai uAgents y el protocolo de pagos AP2 de Google. El autor del informe dividió las amenazas en semánticas y estructurales. Las primeras intentan engañar al modelo de lenguaje con instrucciones maliciosas; por eso el resultado depende de su configuración y robustez. Los ataques estructurales aprovechan errores en los protocolos, en los mecanismos de autorización, en el procesamiento de pagos y en el almacenamiento de credenciales. Un modelo más avanzado no corrige esos problemas.

En CoralOS se encontraron 11 vulnerabilidades, incluida una cadena de tres fallos que permitía interceptar la sesión de un agente y redirigir un pago. La plataforma aceptaba la descripción de un servicio de un catálogo externo sin verificar la firma digital, registraba el secreto del agente en la dirección de la solicitud y confiaba en la dirección de pago que devolvía el servidor remoto. En conjunto, los errores daban al atacante acceso a la interacción entre agentes y permitían suplantar la cartera del destinatario.

En Fetch.ai uAgents se detectaron ocho problemas. La plataforma obtenía las direcciones de red de los agentes desde un catálogo centralizado, pero no verificaba si la dirección encontrada pertenecía realmente al participante correcto. Un catálogo falso podía redirigir los mensajes al servidor del atacante. Además, las claves privadas se almacenaban en un archivo sin cifrar, y un error en el primer arranque podía crear una clave para la operación actual y otra para el almacenamiento posterior. Tras reiniciar, se perdía el acceso a los fondos en la cartera original.

En la implementación de referencia de AP2 versión 0.2.0, el autor contabilizó 14 vulnerabilidades. Entre ellas se encontraban condiciones de carrera al canjear tokens de pago, falta de verificación de autenticidad en algunas herramientas del vendedor, errores en la verificación de certificados, control débil del destinatario del pago y filtraciones de tokens en los registros de diagnóstico. Parte de los problemas afectaba solo a la implementación en Python; sin embargo, 11 vulnerabilidades se mantenían en otras variantes o derivaban del propio protocolo.

Para probar las plataformas, el autor creó un conjunto de pruebas AIP-Bench con criterios de resultado automáticos. A diferencia de las pruebas en las que la respuesta la evalúa otro modelo de lenguaje, la nueva metodología comprueba los códigos de respuesta, la dirección de la cartera, las entradas en los registros y el número de eventos. En las pruebas realizadas, los ataques estructurales funcionaron en el 100% de los casos, salvo las condiciones de carrera, donde el resultado dependía de la coincidencia exacta de las solicitudes.

Una serie separada de 1440 pruebas mostró hasta qué punto distintos modelos sucumbían a instrucciones maliciosas en la descripción del servicio de pago. GPT-4o-mini y Gemini 2.5 Flash ejecutaron la orden suplantada en todos los casos, Mistral Large casi en todos, y GPT-4o en el 68% de los intentos. Claude 3 Haiku, Claude Sonnet 4.6 y Gemini 2.5 Pro no ejecutaron la instrucción maliciosa ni una sola vez. Los resultados muestran que la resistencia depende no solo del tamaño del modelo, sino también de los métodos de su entrenamiento.

El autor también propuso una capa de protección PCAT que se instala entre los agentes y los servicios de comercio. Comprueba las firmas de los catálogos, vincula las direcciones de pago con participantes verificados, bloquea solicitudes peligrosas, vigila que los pagos se realicen una sola vez y exige permiso separado para operaciones sensibles. En las pruebas, PCAT redujo la efectividad de cuatro de los cinco tipos de ataques estructurales a 0%, pero no pudo eliminar por completo las filtraciones de secretos a través de las direcciones de las solicitudes.

El informe publicado como trabajo científico preliminar y aún no ha pasado una revisión independiente. El autor notificó a CoralOS, Fetch.ai y Google el 6 de julio de 2026. Las secciones detalladas de código y las herramientas de explotación listas se prevé que se publiquen el 4 de octubre de 2026, cuando finalice el periodo de 90 días para corregir los errores.