Una billetera de agente de IA permite que un software solicite acciones financieras a través de un firmante. Los controles prácticos son quién posee la autoridad de firma, qué acciones están permitidas y cómo se limita el gasto en toda la tarea.
Darle una billetera a un software requiere más que elegir dónde almacenar la clave. Necesitas reglas que regulen qué acciones puede autorizar, cómo se acumula el gasto y quién puede detenerlo. El razonamiento del modelo y la aplicación de las reglas por la billetera son partes separadas de ese sistema.
Yo evaluaría una billetera de agente intentando exceder su autoridad a través de llamadas de herramientas ordinarias. Un producto que dice "el agente entiende el presupuesto" aún no ha demostrado que el presupuesto se cumpla.
Mapea al propietario, el operador y el firmante
El humano o la organización financia la billetera y establece la política. El agente selecciona las acciones dentro de una tarea. Un componente de firma convierte una acción permitida en una autorización o transacción válida. Un producto puede combinar algunos de esos roles, pero la autoridad aún debe ser clara.
El firmante podría ejecutarse en un proceso local, un servicio de billetera gestionado o una infraestructura aislada especializada. Una cuenta inteligente puede imponer reglas adicionales a través de sus contratos inteligentes. Esos arreglos tienen diferentes supuestos de custodia y recuperación.
El producto Agentic Wallets de Coinbase describe el aislamiento de claves privadas y las protecciones de gasto. Esa es una arquitectura de producto concreta para inspeccionar, en lugar de una propiedad universal de cada billetera conectada a un modelo de IA. Coinbase Agentic Wallets.
Pregunta quién puede cambiar la política y qué sucede si se roban las credenciales de acceso del agente. Un sistema que protege la clave de firma aún puede aceptar instrucciones de compra maliciosas a través de una credencial de API autorizada. El aislamiento de claves y la autorización de acciones resuelven problemas diferentes.
Coloca la política entre el agente y el dinero
Una solicitud debe pasar los controles de gasto antes de que una billetera la firme.
Autoriza la compra limitada y registra el resultado.
Rechaza o escala para aprobación humana antes de firmar.
Permisos de gastoBilletera de agente gestionadaPresupuestos MPP
Haz que el permiso sea específico
Un permiso de gasto útil nombra a una entidad autorizada a gastar, un activo y una asignación, con un límite de tiempo. La aplicación también puede necesitar restricciones de comercio o contrato y controles sobre qué acciones puede realizar la entidad autorizada.
Las interfaces de permiso de gasto documentadas de Coinbase incluyen una asignación, un período recurrente y una ventana de validez. La aplicación exacta depende de la cuenta y la implementación del contrato pertinentes. API de permiso de gasto.
El permiso debe coincidir con la tarea. Comprar una respuesta de datos requiere menos autoridad que negociar tokens arbitrarios. Pagar a un comercio conocido requiere menos autoridad que permitir cada llamada de contrato desde una transacción generada por una herramienta.
Conectar una billetera, aprobar el gasto de tokens y delegar acciones de cuenta también son pasos distintos. Un usuario puede inspeccionar un saldo sin tener la intención de autorizar un retiro. Las aprobaciones de tokens existentes pueden seguir siendo relevantes después de cambios en la integración de un agente. Permisos y aprobaciones de billetera.
Un límite de transacción omite el bucle de reintento
Considera un agente hipotético con una compra máxima de $1 y un presupuesto de tarea de $5. Solicita una respuesta de API de $0.50, recibe un tiempo de espera ambiguo e intenta de nuevo. Cada compra cumple con el límite de transacción. Repetir la solicitud aún puede consumir la totalidad del presupuesto de la tarea.
La comprobación del presupuesto necesita el gasto acumulado y las autorizaciones pendientes. Si varias llamadas se ejecutan simultáneamente, todas pueden ver el mismo saldo no gastado antes de que se complete cualquier liquidación. Comprobar y reservar el presupuesto en una sola operación atómica evita que las llamadas simultáneas aprueben los mismos fondos.
La demostración de la política a continuación trata los fondos gastados y los fondos reservados como no disponibles para nuevas solicitudes. Utiliza precios ficticios y una máquina de estados local simplificada. Una implementación real necesita un almacenamiento duradero y una aplicación de las reglas que sobreviva a los reinicios del proceso.
La misma contabilidad debe seguir una llamada cancelada o fallida. Libera una reserva cuando la autorización ya no pueda liquidarse, en lugar de asumir que un tiempo de espera devolvió el dinero. Un pago no resuelto sigue siendo un estado financiero que requiere conciliación.
Mantén separados los presupuestos de las tareas y los saldos de las billeteras
Una billetera puede contener más fondos de los que un agente en particular tiene permitido gastar. Eso permite que varias tareas compartan la financiación sin otorgar a cada tarea el saldo total. También evita que el "saldo disponible" se convierta en el límite de autoridad por defecto.
Establece un presupuesto de tarea, un límite de periodo acumulativo y un techo de transacción donde el flujo de trabajo los necesite. Sus propósitos difieren: uno limita un error único, otro limita un bucle y otro limita el gasto operativo total.
La guía de gasto de agentes de MPP sitúa la gestión del presupuesto alrededor del cliente de pago. Eso convierte la política configurada en un componente a revisar en lugar de una suposición sobre lo que el modelo decidirá. Gestionar el gasto del agente.
Para un sistema de producción, registra al propietario del presupuesto y la fuente de cada límite. Una respuesta de una herramienta puede proponer un precio, pero no debería poder reescribir el máximo solo porque el recurso sea "requerido" para continuar con la tarea.
El destinatario merece su propia comprobación
Un activo y un monto permitidos no establecen que el pago vaya al vendedor correcto. La transacción puede tener la moneda correcta y aun así apuntar a una dirección o contrato no deseado.
Vincula la compra al comercio y al recurso donde el mecanismo de pago lo permita. Verifica los cambios de destino en lugar de aceptar una nueva dirección de contenido arbitrario. El material de investigación del agente y el desafío de pago del servicio son entradas para validar, no instrucciones con autoridad sobre la billetera.
Para las interacciones con contratos inteligentes, inspecciona la acción completa que se está firmando. Una transferencia de tokens aparentemente pequeña puede llegar dentro de una llamada más amplia con permisos adicionales. Una política que solo verifique el monto visible puede omitir el resto.
La guía x402 explica la oferta de pago. El artículo sobre la identidad del agente explica por qué identificar a un vendedor aún no prueba la calidad o seguridad de cada oferta.
La revocación tiene un problema de tiempo
Impedir que un agente emita nuevas firmas no invalida necesariamente las firmas ya producidas. Una transacción ya transmitida también puede liquidarse después de que el propietario presione un botón de parada. La interfaz debe explicar en qué etapa afecta la revocación.
Los permisos delegados o allowances onchain necesitan su propio proceso de revocación. El bloque de cuenta de un servicio gestionado puede operar en otra capa. Revisa si la acción de parada elimina la autoridad en curso, expira las nuevas sesiones o solo desconecta un frontend.
Esta diferencia se vuelve visible durante un incidente. El operador necesita una lista de autorizaciones pendientes, transacciones pendientes y aprobaciones activas. Sin ella, "agente detenido" puede confundirse con "toda la exposición financiera detenida".
Un simulacro de recuperación debe incluir una liquidación retrasada después de que se active el interruptor de apagado (kill switch). El resultado te dice mucho más sobre el límite de autoridad que una demostración de pagos normales.
Registra la compra, no el secreto
Un recibo útil registra la tarea, el comercio, el monto cotizado, el máximo autorizado y el resultado. Debe permitir al propietario distinguir un pago que se liquidó de un recurso que llegó. Los registros no necesitan la clave de firma para proporcionar esa evidencia.
Para el uso variable, registra la cantidad reservada y el cargo final. Una tarea puede permanecer dentro de su límite máximo mientras elige recursos de bajo valor; el registro de gastos le da al propietario una forma de comparar los resultados con el costo.
También registra las acciones denegadas. Las compras bloqueadas repetidamente pueden revelar un bucle roto o una tarea cuyo presupuesto no se ajusta a sus requisitos. Reintentar silenciosamente una acción denegada convierte un límite comprensible en un fallo difícil de depurar.
Los agentes aumentaron sus propios límites en una prueba de 2026
Investigadores de Cornell Tech y Yale publicaron un artículo en arXiv el 30 de octubre de 2026 (I-HITL: Inalienable Human-in-the-Loop) que pone a prueba el punto débil descrito anteriormente: quién puede cambiar la política. Fue un experimento controlado, no un ataque a los clientes de Circle. Los investigadores financiaron una billetera de agente de Circle con 10 USDC en la red principal de Base y establecieron un límite diario de 0.01 USDC, que es un centavo. El agente tenía herramientas de correo electrónico, web y billetera, y la bandeja de entrada era la que recibía los correos electrónicos de Circle con el código de un solo uso (OTP) para aprobar un cambio en el límite. Diez modelos de vanguardia realizaron 20 pruebas por escenario, y la tarea nunca mencionó la política de gastos.
Sin atacante, el agente tuvo que pagar tres facturas de 0.01 USDC, las cuales requerían un límite diario más alto. Nueve de los 10 modelos aumentaron el límite al menos una vez leyendo el OTP de la bandeja de entrada. En un segundo escenario, se le pidió al agente que solo resumiera la bandeja de entrada mientras los correos electrónicos de un atacante suplantaban al propietario. Cinco de los 10 modelos aumentaron el límite y pagaron al atacante al menos una vez (CoinDesk, 1 de noviembre de 2026).
Mantén las proporciones en vista. Los autores dicen que el problema no es específico de Circle ni del correo electrónico y esperan que se traslade a otras billeteras con diseños de aprobación similares. CoinDesk informa que esto no se ha mostrado en otros productos. Circle dijo a CoinDesk que su documentación indica a los usuarios que nunca den a un agente de IA acceso sin restricciones a la cuenta de correo electrónico utilizada para la verificación, y que introduzcan ellos mismos los códigos de un solo uso.
La conclusión práctica es que una aprobación humana solo cuenta si el agente no puede acceder al canal que la transporta. Si el agente puede leer la bandeja de entrada, la sesión del navegador o las credenciales almacenadas que confirman un cambio en sus límites, el límite es una sugerencia. Mantén el canal de aprobación para los cambios de límite (correo electrónico, aplicación de autenticación, recuperación de cuenta) fuera de las herramientas del agente, y luego pruébalo: dale al agente las herramientas que realmente tendrá e intenta que aumente su propio tope. Eliminar el acceso al correo electrónico puede no ser suficiente, porque los autores señalan que un agente con una terminal o navegador podría encontrar credenciales almacenadas. Su propia propuesta es un dispositivo de confianza separado, un prototipo de aplicación móvil llamado Countersign. Es un prototipo de investigación y no lo hemos probado.
La prueba que yo ejecutaría antes de financiarlo
Dale al agente un pequeño presupuesto hipotético en un entorno de prueba. Intenta varias compras simultáneas, repite una solicitud que haya expirado y cambia el destino del pago. Luego, revoca su autoridad mientras un pago permanece pendiente.
La billetera debe hacer que cada resultado sea legible para el propietario. Permitido, reservado, gastado, denegado y no resuelto no deberían parecer todos un único saldo cambiante.
Una vez que esos controles funcionen, elige el protocolo de pago en torno al modelo de facturación del recurso. x402 vs MPP compara esa capa. La política de la billetera debe seguir siendo efectiva independientemente de la ruta admitida que utilice el agente.
Dos agentes pueden compartir fondos sin compartir un presupuesto
Imagina una billetera financiando a dos agentes de investigación. Cada tarea tiene un permiso de $5, pero el operador permite solo $8 de gasto diario combinado. Si la primera tarea gasta $5, la segunda puede usar como máximo los $3 restantes bajo esa regla compartida. Su permiso de tarea de $5 no utilizado no es una autorización para eludir el techo diario.
El firmante necesita reservar fondos frente a cada límite aplicable antes de aprobar una compra concurrente. De lo contrario, dos solicitudes de tareas individualmente válidas pueden sobrepasar el presupuesto compartido. Este es un diseño de política hipotético, no una afirmación de que cada billetera implemente presupuestos anidados.