Cómo darle una billetera a tu agente de IA
Explora las billeteras para agentes, los controles de Cloudflare Wallets y los pagos x402 por HTTP. Consulta qué está disponible y qué límites siguen sin aclararse.
Una billetera para agentes (agent wallet) es un saldo acotado que un agente de IA puede gastar en nombre de su propietario, dentro de los límites que este establezca. Permite que el agente pague APIs, herramientas y contenido sin llegar a tener nunca la tarjeta del propietario.
Probablemente ya hayas visto a un agente hacerlo: lee la documentación, elige el endpoint correcto, redacta la solicitud y, de repente, se detiene ante un formulario de registro que pide una tarjeta de crédito. El resto del trabajo vuelve a caer en tus manos.
Cloudflare Wallets, anunciado el 4 de agosto de 2026, es un ejemplo concreto de esta idea. Este artículo explica qué es una billetera para agentes, qué controles ha descrito Cloudflare, cómo viaja un pago a través de HTTP y qué preguntas siguen abiertas. Muestra hacia dónde se dirigen los pagos agénticos. No es una recomendación para usarlos en producción: el producto está en una fase temprana y puede cambiar o retirarse.
Puntos clave
- En la documentación de Wallets de Cloudflare, actualizada por última vez el 19 de agosto de 2026, la única funcionalidad operativa es la reserva de un identificador (handle) en cloudflare.pay, y un identificador reservado no puede enviar, recibir ni almacenar fondos.
- Cloudflare describe dos tipos de billetera: las Account Wallets, en manos de las personas propietarias de una cuenta de Cloudflare, y las Virtual Wallets, que los agentes usan mediante claves de API.
- Las salvaguardas anunciadas para una Virtual Wallet son una asignación de gasto, una lista de comercios permitidos y un importe máximo por transacción, además de una anulación manual por parte de una persona. Ni el anuncio ni la documentación describen una caducidad ni una API de revocación.
- x402 vincula un pago a una solicitud HTTP normal reutilizando el código de estado 402 Payment Required, de modo que un agente puede pagar una sola llamada a una API sin crear una cuenta.
- Reservar un identificador es gratuito. No se han publicado precios para las billeteras en sí.
Por qué darle tu tarjeta a un agente no funciona
Un número de tarjeta otorga a un agente mucha más autoridad de la que necesita cualquier tarea individual. No tiene restricción por comercio, ni presupuesto por tarea, ni registro de qué agente gastó qué. La única forma de retirar esa autoridad es cancelar la tarjeta, lo que además interrumpe todos los demás cargos asociados a ella.
Los agentes que navegan y actúan por ti se topan con esto constantemente. El anuncio de Cloudflare señala dos piezas que faltan: los agentes no tienen un identificador fijo con el que registrarse ni un método de pago propio. Por eso, el agente suele detenerse y devolver a una persona el registro, el pago y las claves de API. Esto dificulta que un agente pruebe y compare por sí mismo muchos servicios de pago.
Qué es una billetera para agentes: Account Wallets y Virtual Wallets
Una billetera para agentes separa el dinero de la autoridad para gastarlo. Una persona custodia los fondos y cada agente recibe una porción limitada que puede gastar por su cuenta. El diseño de Cloudflare tiene dos niveles.
| Tipo de billetera | En manos de | Cómo funciona |
|---|---|---|
| Account Wallet | Personas que poseen o usan la cuenta de Cloudflare | Permitirá recargar el saldo, delegar el gasto en Virtual Wallets y retirar dinero; puede tener un identificador de cloudflare.pay |
| Virtual Wallet | Agentes | Los agentes la usan con una clave de API; no puede gastar por encima del tope que fije el propietario de la Account Wallet |
La documentación de Cloudflare Wallets indica que el objetivo de las Virtual Wallets es permitir que un agente trabaje sin que una persona apruebe cada paso, al tiempo que se impone un tope estricto a lo que puede gastar. El anuncio afirma que los agentes las usarán para comprar APIs, contenido y herramientas MCP, las mismas herramientas del lado del servidor que se tratan en nuestra guía sobre el ecosistema MCP.
La mayor parte de esto aún no está disponible:
| Disponible | Anunciado | No descrito en el anuncio ni en la documentación |
|---|---|---|
Reservar un identificador por cuenta (gratis), lo que publica una página en HANDLE.cloudflare.pay y te suscribe a las notificaciones del lanzamiento | Recarga, envío, recepción y almacenamiento de fondos; Virtual Wallets; salvaguardas; anulación manual; identidad para agentes específicos | Precios de las billeteras, fechas de lanzamiento, caducidad, una API de revocación, comportamiento ante concurrencia, cómo los compradores disputan una compra |
Las preguntas frecuentes de Wallets añaden algunas condiciones. Reservar un identificador no garantiza el acceso a una billetera cuando se lance. Una vez reservado, el identificador no se puede modificar, liberar ni transferir. Cloudflare puede rechazar o reclamar reservas. El comunicado de prensa indica que el acceso completo a las billeteras llegará “en los próximos meses”, sin dar una fecha.
¿Qué controles tiene una billetera para agentes y qué le falta?
El anuncio de Cloudflare enumera tres salvaguardas que el propietario configura en una Virtual Wallet, además de una anulación manual para cuando un agente alcanza su límite. Ninguna está disponible todavía. La documentación solo menciona “permisos” y un límite de gasto, sin nombrar los controles individuales.
| Control | Qué limita | Qué no puede expresar |
|---|---|---|
| Asignación de gasto | El gasto total | Si ese gasto fue sensato |
| Lista de comercios permitidos | A quién puede pagar el agente | Qué artículos ni con qué frecuencia |
| Importe máximo por transacción | El importe de cada pago | Muchos pagos pequeños que se acumulan |
| Anulación manual | Permite que una persona autorizada aumente el límite o apruebe fondos adicionales | Cuándo debería caducar una anulación |
Ni el anuncio ni la documentación de Cloudflare describen una fecha de caducidad para la autoridad de gasto de un agente ni una API para revocarla. Cloudflare también afirma que una persona podrá revisar actividad inusual, como un gasto inesperadamente rápido. Se trata de una intención declarada, no de un control documentado: no se ha publicado ningún disparador ni mecanismo.
Cómo paga un agente: x402 y HTTP 402
x402 es un protocolo abierto que vincula un pago a una solicitud HTTP. Reutiliza el código de estado 402 Payment Required, que HTTP reservó hace tiempo pero que nunca se definió en la práctica. La publicación de Cloudflare sobre Monetization Gateway describe el flujo así:
- El agente solicita un recurso a un endpoint compatible con x402.
- El servidor responde con un 402 que incluye el precio y cómo pagar.
- El agente paga y vuelve a intentarlo, esta vez incluyendo un comprobante de pago.
- Un facilitador verifica el pago y, a continuación, el servidor devuelve lo solicitado.
Inicialmente, las billeteras de Cloudflare liquidarán en stablecoins. Es una decisión de Cloudflare, no un requisito de x402. El propio Monetization Gateway se abrió como lista de espera cuando Cloudflare lo anunció.
Un identificador de cloudflare.pay también permite a los comercios ver quién paga, porque muestra a qué organización pertenece un agente. El ejemplo del anuncio es un agente de investigación en research.example.cloudflare.pay. Declarar esa identidad será opcional para el agente, y cada comercio decide si trata de forma diferente a los agentes identificados.
¿Quién es responsable cuando un agente compra algo equivocado?
Ninguna fuente publicada indica todavía quién es responsable cuando un agente compra algo equivocado. Las fuentes dejan abiertas tres preguntas.
¿Qué ocurre con los contracargos? La publicación sobre Monetization Gateway presenta la liquidación en stablecoins como libre de contracargos, con los fondos yendo directamente al vendedor. Ni el anuncio de Wallets ni la documentación explican cómo un comprador puede disputar una compra que un agente hizo mal.
¿Qué registra el historial de auditoría? Un registro de pagos muestra qué se pagó. Ninguna de las fuentes describe un registro de por qué el agente decidió pagar.
¿De quién es el error? Podría ser del propietario de la cuenta, del desarrollador del agente o del comercio. Las fuentes no lo dicen.
El análisis del lanzamiento publicado por InfoQ añade una observación estructural: estos controles fijan un presupuesto, pero no constituyen una política. Cada verificación compara un único pago con una cifra fija. Por tanto, ninguno de ellos puede expresar una regla como “no compres el mismo dataset dos veces esta semana”, porque esa regla depende de pagos anteriores. InfoQ también plantea la cuestión de la concurrencia. Si un agente envía varios pagos a la vez, cada uno podría verificarse contra la asignación completa antes de que se haya descontado cualquiera de los demás, de modo que el total podría superar el límite. Cloudflare no ha publicado cómo se comporta la asignación en ese caso.
La carrera más amplia por los pagos agénticos
Cloudflare no es la única empresa que desarrolla pagos agénticos: el protocolo x402 de Coinbase y la billetera Link para agentes de Stripe abordan el mismo problema de formas distintas. x402 fue creado por Coinbase y cedido a la Linux Foundation. La x402 Foundation comenzó a operar en julio de 2026 con 40 miembros.
Stripe ha optado por el enfoque contrario. En su lanzamiento, su billetera Link para agentes entrega a un agente una tarjeta de un solo uso o un Shared Payment Token solo después de que la persona apruebe cada solicitud de gasto. Stripe afirma que más adelante añadirá límites configurables por el usuario. Los pagos son una capa más dentro de un conjunto más amplio de herramientas para agentes, junto a configuraciones como Docker MCP para agentes de IA y WebMCP, que permite a un sitio exponer sus propias acciones a los agentes.
Conclusión
Una billetera para agentes sustituye el “aquí tienes mi tarjeta” por una autoridad delegada con límites. La versión de Cloudflare fija esos límites por pago, y la responsabilidad, las disputas y la concurrencia aún no están documentadas. Hasta que se lancen la recarga de fondos y los pagos, el único paso concreto disponible es reservar un identificador. Mientras tanto, si desarrollas agentes, define dónde deben residir tus propias reglas de gasto: en la billetera o en tu aplicación.
Preguntas frecuentes
¿x402 solo funciona con Cloudflare o con stablecoins?
No. x402 es un estándar abierto para pagos a través de HTTP. Lo creó Coinbase y ahora lo gobierna la x402 Foundation, bajo el paraguas de la Linux Foundation. La fundación se lanzó con 40 miembros, entre ellos AWS, Google, Stripe, Visa, Mastercard y Cloudflare. Según la Linux Foundation, x402 admite tipos de pago que van desde las tarjetas tradicionales hasta las stablecoins. Cloudflare eligió las stablecoins para sus propias billeteras, pero el protocolo no las exige.
¿HTTP 402 Payment Required es un código de estado oficial?
Sí, pero la especificación no define su comportamiento. El RFC 9110, la especificación HTTP Semantics, recoge el 402 como reservado para uso futuro, y MDN señala que no existe una convención estándar para él. Los navegadores y los clientes HTTP lo tratan como cualquier otro error de cliente 4xx. x402 aporta la convención que faltaba: qué contiene la respuesta 402, cómo paga el cliente y cómo reintenta la solicitud con el comprobante de pago.
¿Cuál es la diferencia entre Cloudflare Wallets y la billetera Link para agentes de Stripe?
Sitúan la aprobación humana en puntos distintos. Cloudflare afirma que las Virtual Wallets permitirán a los agentes gastar por su cuenta, dentro de una asignación de gasto, una lista de comercios permitidos y un importe máximo por transacción definidos de antemano. En su lanzamiento en abril de 2026, la billetera Link para agentes de Stripe entrega a un agente una tarjeta de un solo uso o un Shared Payment Token solo después de que la persona apruebe cada solicitud de gasto. Stripe afirma que más adelante llegarán los límites configurables por el usuario.
¿Cómo aplico reglas de gasto que los límites de una billetera para agentes no pueden expresar?
Añade en tu propia aplicación una verificación de políticas que se ejecute antes de que el agente pague. Mantén un registro contable de las compras anteriores para que la verificación pueda rechazar repeticiones, como comprar el mismo dataset dos veces en una semana. Haz que la verificación reserve los fondos de forma atómica, por ejemplo con una transacción de base de datos o con una cola de pagos por agente. Así evitarás que varios pagos en paralelo se aprueben contra la misma asignación aún no descontada.
