Darle a un agente de IA autónomo el control de una wallet real cambia el cálculo de riesgo por completo. Un bug en un agente normal produce una respuesta mala. Un bug en un agente con una private key produce una transacción real, irreversible, con dinero real. Esto aplica tanto si el agente USA tools que cobran (como las de Andreax) como si el agente administra directamente fondos on-chain.
La primera capa de defensa es la más obvia y la más importante: la private key nunca sale del proceso del agente. Ni al servidor que provee las tools, ni a un log, ni a un prompt que se manda a un LLM. En el protocolo x402/EIP-3009, la firma se calcula localmente y solo el resultado (una firma + un mensaje autorizando UN monto específico a UN destinatario específico) viaja por la red. El servidor nunca necesita, ni debería pedir, la clave privada del agente.
La segunda capa es EIP-3009 en sí mismo: cada autorización firmada es específica — un monto exacto, un destinatario exacto, una ventana de validez (`validAfter`/`validBefore`), y un nonce único que evita que la misma autorización se reuse. Esto es fundamentalmente más seguro que darle a un agente una allowance ERC-20 abierta (`approve(spender, MAX_UINT)`), que es el patrón clásico que exploits y contratos maliciosos abusan para vaciar una wallet de una sola vez.
La tercera capa, y la que más importa en la práctica día a día, son los caps de gasto del lado del cliente — el freno que existe AUNQUE la firma sea válida y el servidor sea honesto:
from andreax_sdk import AndreaxClient
client = AndreaxClient(
wallet_address="0x...",
private_key="0x...",
auto_pay=True,
per_call_cap_usd=0.10, # ninguna llamada individual paga mas de esto
daily_cap_usd=5.00, # el agente para de auto-pagar al llegar a este acumulado
)`per_call_cap_usd` protege contra una tool mal configurada o carísima que el agente llame por error. `daily_cap_usd` protege contra el escenario más peligroso: un agente atrapado en un loop (por un bug propio, o por un prompt injection que lo induce a llamar la misma tool repetidamente) — sin este tope, un loop de 10.000 llamadas a $0.01 cada una vacía $100 antes de que alguien lo note.
Estos caps son locales y del lado del cliente a propósito: no dependen de que el servidor coopere, y se resetean al cruzar el día (UTC) sin necesitar persistencia entre reinicios del proceso — si necesitás que el tope sobreviva un reinicio, hay que envolver `record_spend()`/`spent_today_usd` en tu propio proceso (por ejemplo persistiéndolo vos mismo en una base de datos).
Una capa adicional, del lado del SERVIDOR (no del agente que paga), es el rate limiting por IP/wallet: un free tier con tope de llamadas y tope de gasto absorbido protege al proveedor de un abuso masivo (miles de IPs de crawler pegándole al mismo endpoint gratis), separado del problema de proteger la wallet del AGENTE que consume.
Regla práctica: si estás construyendo un agente que va a manejar una wallet real, empezá siempre en testnet, con caps conservadores (los defaults de $0.10/llamada y $5.00/día son un buen punto de partida), y solo subilos cuando conozcas el patrón de gasto real del agente en producción — nunca al revés.
Try any tool with 100 free calls per wallet — browse the catalog · publish your own.