Cloudflare ha detallado una arquitectura de cartera de dos niveles para el comercio de agentes que separa las carteras principales controladas por el desarrollador de las carteras secundarias por agente, las cuales tienen topes de gasto estrictos. El diseño, publicado esta semana, otorga a los desarrolladores un control programático sobre cómo los agentes de IA gastan stablecoins sin requerir aprobación humana en cada transacción. La importancia de esta arquitectura radica en que aborda el miedo operativo más concreto en los pagos de agentes: que un modelo autónomo se descontrole y agote un presupuesto antes de que nadie lo note. Los detalles de cómo funcionan la jerarquización, los topes y la vinculación de identidad determinarán si este enfoque es realmente más seguro que simplemente entregarle una clave privada a un agente.
La separación de carteras principal y secundaria
La arquitectura sitúa una cartera principal controlada por el desarrollador en la cima de la jerarquía. Esta cartera contiene el balance principal de stablecoins — probablemente USDC en Base, dada la integración de Cloudflare con el estándar de pago x402 y la infraestructura de agentes de Coinbase. La cartera principal no ejecuta los pagos de los agentes directamente. En su lugar, financia carteras secundarias, cada una aprovisionada para un agente de IA o clase de agente específica. Las carteras secundarias reciben una asignación definida, y el agente solo puede gastar lo que hay en su propia cartera. Una vez agotada la asignación, los pagos fallan silenciosamente o devuelven un error que el agente puede gestionar. Este aislamiento significa que un agente comprometido o con fallos no puede vaciar el balance completo del desarrollador; está limitado a lo que se le asignó explícitamente.
Cómo funcionan los topes de gasto
El mecanismo de límite de gasto opera a nivel de cartera, no por transacción. Un desarrollador establece un techo estricto en la cartera secundaria — por ejemplo, 50 USDC al día o 500 USDC en total. El agente puede entonces realizar docenas o cientos de micropagos a través de múltiples llamadas a la API sin autorización adicional, siempre y cuando el gasto acumulado se mantenga por debajo del tope. Este es un compromiso deliberado. La aprobación por transacción sería más segura, pero eliminaría la autonomía que hace útil al comercio de agentes en primer lugar. Los topes a nivel de cartera permiten a los agentes negociar y pagar por recursos en tiempo real — obteniendo datos, llamando a modelos, comprando cómputo — mientras mantienen el peor escenario acotado. El tope se reinicia o rellena basándose en reglas configuradas por el desarrollador, no por el comportamiento del agente.
Vinculación de identidad y pistas de auditoría
Cada cartera secundaria recibe un identificador de identidad vinculado al agente específico que la utiliza. Esto no es lo mismo que una verificación de identidad humana (KYC). Es una identidad de máquina — un identificador criptográfico que vincula cada pago que realiza la cartera con la instancia del agente que lo inició. Si un agente realiza una serie de pagos a un endpoint de API que luego resulta ser fraudulento o adversarial, la pista de auditoría muestra qué agente, bajo qué configuración, tomó esas decisiones. Esto es importante para la depuración de errores, para la revisión posterior a un incidente y para la cuestión de responsabilidad que toda empresa hará antes de desplegar agentes con capacidad de pago: quién o qué es responsable cuando algo sale mal. El identificador de identidad también habilita políticas de limitación de tasa y control de acceso en el borde de la red, donde Cloudflare ya opera.
Preguntas abiertas y limitaciones
Varios aspectos siguen poco claros a partir de lo que se ha revelado. El mecanismo para reponer las carteras secundarias — ya sea automático cuando el balance de la cartera principal es suficiente, o si requiere una acción explícita del desarrollador — no está completamente especificado. La relación entre los topes de gasto y el flujo de negociación de pagos x402 también necesita aclaración: ¿evalúa un agente una respuesta de precios 402 frente al balance restante de su cartera antes de comprometerse, o intenta realizar el pago y falla? Esta última opción desperdiciaría un ciclo de ida y vuelta de la API. Además, la arquitectura no resuelve inherentemente el problema de los precios adversariales, donde un proveedor de recursos podría manipular la señal de precio 402 para extraer el máximo del tope de un agente. Estas no son fallas fatales, pero determinarán si el modelo de dos niveles resiste bajo una carga real de despliegue.