La firma no protege lo que parece
AP2 es un protocolo de pagos que Google propuso para que los agentes LLM puedan pagar en nombre de una persona: recibir una tarea, negociar las condiciones con el vendedor, realizar el pedido y transferir el dinero. El entramado de confianza aquí se sostiene sobre dos documentos firmados: Checkout Mandate y Payment Mandate. Estos fijan las condiciones de la transacción y, una vez firmados, ya no es posible sustituirlos sin que se note.
El escollo está en la expresión «una vez firmados». La firma garantiza que los datos no han cambiado desde el momento en que se certificaron, y no dice nada sobre cómo aparecieron. Y estos se componen de un flujo de interacciones: mensajes entre agentes mediante el A2A Protocol, llamadas a herramientas a través del Model Context Protocol, respuestas de servicios externos, el contenido de páginas y correos. Todo esto queda fuera de la protección criptográfica. Si en el contexto se introdujo una instrucción ajena antes de la autorización, la firma certificará una intención ya distorsionada, y seguirá siendo absolutamente válida.
De ahí el nombre del estudio: la amenaza no vive dentro del mandato, sino «detrás del mandato».
Qué se había encontrado antes y por qué la v0.2 exigió un nuevo análisis
Los puntos débiles de AP2 ya se habían buscado antes: en la versión v0.1 se describieron ataques de repetición e inyección de prompts. En la v0.2 se cerraron parte de estos problemas, pero junto con las correcciones llegaron nuevas capacidades y nuevas suposiciones sobre el despliegue. Cada una de estas novedades es una superficie de ataque potencial, y el análisis antiguo no se traslada mecánicamente a la nueva versión.
De esto se ocupó el equipo: Avital Aviv, Parth A. Gandh, Ron Bitton y Asaf Shabtai. El trabajo Beyond the Mandate: A Systematic Security Analysis of the Agent Payments Protocol (AP2) se publicó en arXiv el 24 de agosto de 2026 con el número 2608.23858, en las categorías cs.CR y cs.AI.
Roles, fases, arquitecturas y límites de confianza
El análisis no está planteado como una cacería de errores individuales, sino como un trazado de todo el territorio. Los autores describen los roles de los participantes y dividen el ciclo de vida de la transacción en cinco fases consecutivas, desde el planteamiento de la tarea hasta los pagos y las posibles disputas posteriores. En paralelo, se distinguen cinco arquitecturas de despliegue: se diferencian por dónde se ubican los agentes, quién guarda las claves y cómo se integran los intermediarios de confianza en el esquema.
El paso clave es el trazado de los límites de confianza. Y aquí se perfila la asimetría principal: el mandato mismo está dentro del contorno protegido, mientras que todo el flujo de información del que se destila queda fuera. Todo lo que ocurre entre estas zonas constituye el argumento central del trabajo.
MAESTRO: actores, superficies, objetivos
La parte formal se construyó sobre MAESTRO, una metodología de modelado de amenazas para entornos multiagente. Con su ayuda se describen cuatro actores de amenaza, once superficies de ataque, dieciocho capacidades del adversario y seis objetivos que persigue el atacante.
Esta descomposición no busca cifras bonitas. Muestra que el adversario no es uno solo: no es únicamente un atacante externo, sino también una herramienta comprometida, un vendedor deshonesto, un servicio suplantado. Y sus motivos son distintos, desde la extracción directa de dinero hasta el desplazamiento imperceptible de la elección en la dirección deseada.
Catálogo de 48 amenazas
El resultado fue un catálogo de 48 amenazas, agrupadas en cinco familias de ataques. Se evaluaron con AIVSS, un sistema de puntuación de vulnerabilidades adaptado a las particularidades de la IA. Ocho amenazas alcanzan al menos la banda High en al menos una arquitectura.
Ya resulta revelador ese «al menos en una». El nivel de riesgo depende no solo del código, sino también del esquema de despliegue: lo que es letal para una variante de integración puede resultar casi inofensivo en otra, y viceversa. No existe una respuesta única a la pregunta de cuán seguro es AP2.
Ocho de alto riesgo: el banco de pruebas y las demostraciones
En el momento del trabajo no existía un despliegue público del protocolo, por lo que los autores montaron un banco de pruebas con sus propias manos y cubrieron en él las cinco arquitecturas. Sobre él construyeron también cinco demostraciones proof-of-concept: cada una cubre su propio grupo de amenazas y, en conjunto, abarcan los ocho escenarios de alto riesgo junto con las medidas de protección propuestas.
Este es un argumento importante contra la objeción de «aquí solo hay teoría». Las amenazas no solo se enumeran: se reproducen.
Un escáner que conoce el despliegue
Otro resultado práctico aparte es un escáner que tiene en cuenta las particularidades del despliegue. Su lógica consiste en que hay que verificar no el protocolo en general, sino la configuración concreta. El escáner contrasta las amenazas aplicables a un esquema dado con comprobaciones de tres tipos: estáticas, de coherencia entre roles y pruebas de confrontación.
Las comprobaciones entre roles son aquí especialmente pertinentes. En un esquema multiagente, el error suele esconderse no dentro de un componente aislado, sino en la juntura de expectativas: un agente está convencido de que la comprobación necesaria ya la realizó otro.
Qué se deduce de esto
La conclusión principal suena más dura de lo que uno querría: una firma válida del mandato no basta para afirmar que la transacción refleja la intención del usuario. La firma confirma la integridad, no el sentido. Si el contexto fue comprometido antes de la autorización, la criptografía certificará cuidadosamente la voluntad ajena.
Consecuencias prácticas para quienes construyen pagos agénticos:
- Controle el contexto de entrada, no solo la transacción final. La mayor parte de los riesgos se encuentra antes del momento de la firma.
- Considere la arquitectura como parte del modelo de amenazas. Una misma versión del protocolo da un perfil de riesgo distinto en esquemas de despliegue diferentes.
- Reduzca las atribuciones del agente. Cuanto más concreto sea el mandato, menor será el daño de una intención distorsionada.
- Verifique las junturas entre roles. Es allí donde las comprobaciones fallan con más frecuencia.
En resumen
La criptografía resuelve exactamente la tarea que se le encomendó, y ni un ápice más. AP2 protege honestamente la transacción de una sustitución después de la firma; todo lo que ocurre antes queda en la zona de responsabilidad del desarrollador. El estudio con 48 amenazas y ocho escenarios de alto riesgo no es una sentencia para el protocolo, sino un mapa del terreno: muestra dónde termina la protección que ofrece la firma y dónde empieza el trabajo que la firma no hará por usted.
