Account abstraction para wallets de agentes: session keys y límites

Un agente autónomo que sostiene una private key cruda tiene exactamente un límite de gasto: todo tu saldo. Account abstraction convierte ese límite en una política que puedes escribir, acotar y revocar.

Dedicamos los últimos tres posts al rail de pago: cómo EIP-3009 mueve stablecoins sin gas, cómo la extensión A2A x402 maneja una máquina de estados de pago, y cómo la autorización de MCP ata la identidad de un agente a un token. Cada uno de esos posts repitió la misma regla: las llaves quedan fuera del LLM. Este post trata la capa que hay debajo de esa regla — la cuenta misma, y qué impide que un agente comprometido la vacíe.

El EOA es el default equivocado

La mayoría de los despliegues tempranos le dan al agente una externally owned account. Un EOA es un keypair. La private key es la autoridad. Quien la tenga puede enviar cualquier transacción, a cualquier dirección, por cualquier monto, para siempre. No hay tope de gasto, ni allowlist de destinatario, ni expiry, ni delay temporal.

Para un humano, es tolerable. Firmas transacciones de a una y notas cuando algo está mal. Un agente autónomo no firma de a una. Corre desatendido, llama tools, sigue planes y procesa input no confiable. Una sola prompt injection, un resultado de tool envenenado o una variable de entorno filtrada, y el atacante tiene la misma autoridad que tenía el agente — que, con un EOA, es toda.

El arreglo no es "cuida más la llave". Es hacer la llave estructuralmente incapaz de gastar más de lo que debería. Eso es lo que aporta account abstraction: la cuenta es un smart contract, y el smart contract aplica la política antes de que cualquier transferencia se liquide.

ERC-4337 en un párrafo

ERC-4337 reemplaza el EOA con una cuenta-contrato. En lugar de una transacción cruda, el agente emite una UserOperation — una pseudo-transacción que fluye a través de un bundler hasta un contrato singleton EntryPoint. El EntryPoint llama a la lógica de validación de la propia cuenta antes de ejecutar. Ese paso de validación es el hook: es donde una smart account chequea una firma, un límite de gasto, un destinatario, y revierte si la llamada se sale de rango. La política vive en el contrato, no en el código de aplicación que corre el agente. EIP-7702, incluido en el upgrade Pectra de Ethereum en mayo de 2025, deja que un EOA común delegue a código de contrato también, así que la misma maquinaria alcanza ahora cuentas que nunca se desplegaron como smart wallets.

Session keys: autoridad sin custodia

Una session key es una segunda llave de firma que la smart account autoriza para un propósito acotado. El agente firma con la session key. La cuenta valida esa llave contra un registro de permiso almacenado y ejecuta solo si la acción encaja en el scope. La llave principal nunca queda expuesta al runtime del agente.

La propiedad estructural importante, dicha con claridad en el Delegation Toolkit de MetaMask, es que la session account no sostiene fondos. Es una llave de firma, no un punto de custodia. La ejecución ocurre redimiendo una delegation contra la smart account principal del usuario. El agente puede actuar; el agente no puede llevarse el saldo, porque el saldo nunca estuvo bajo el control de la session key.

Este es el espejo on-chain de la regla de las llaves fuera del LLM. El modelo planifica y llama tools. Una session key acotada, que no sostiene nada, firma la acción específica. La cuenta con fondos queda detrás de un contrato que rechazará todo lo que esté fuera del grant.

ERC-7715 y ERC-7710: el estándar del grant

Dos estándares en draft convierten esto de una integración a medida en una API a nivel de wallet. ERC-7715 define el lado del pedido — un método JSON-RPC, wallet_requestExecutionPermissions, que una aplicación usa para pedirle a un wallet un permiso acotado y con tiempo. ERC-7710 define el lado del contrato — cómo la cuenta expone esos permisos y cómo se redimen a través de un delegation manager.

La forma del pedido es deliberadamente chica. Un permission request lleva la cadena, la cuenta, el signer que recibe la autoridad, y un objeto permission cuyo type y data se definen por caso de uso:

// ERC-7715 permission request (forma, simplificada)
{
  chainId: '0x2105',          // Base
  from: '0xUserSmartAccount',
  permission: {
    type: 'erc20-token-periodic',
    isAdjustmentAllowed: true,   // el wallet puede ajustar antes de firmar
    data: {
      token: '0xUSDC',
      periodAmount: '10000000',     // 10 USDC (6 decimales)
      periodDuration: 86400,        // por día
      startTime: 1752537600,
      expiry: 1755129600
    }
  }
}

El wallet renderiza una pantalla legible por humanos desde ese objeto. Puede dejar que el usuario ajuste los números antes de aprobar — a menos que la app ponga isAdjustmentAllowed: false, en cuyo caso el wallet debe presentar el pedido tal cual o rechazarlo. La respuesta agrega un blob context, la dirección del delegationManager y cualquier dependencies de despliegue. Ese context es la credencial que la app reproduce cada vez que ejecuta.

El ejemplo canónico de MetaMask es un agente de dollar-cost-average: aprobar, una vez, un permiso para gastar hasta 10 USDC en la próxima hora contra un solo contrato. Sin popup por transacción después de eso. On-chain, los caveat enforcers validan cada redención; una llamada fuera del scope otorgado es rechazada por la cuenta misma.

Una propiedad importa para sistemas multi-agente: la attenuation. Un permiso puede re-emitirse bajo un scope más estrecho antes de entregarse a un sub-componente. Un grant padre de "$500 diarios en este DEX" puede acotarse a "$50 en este único swap" y delegarse hacia abajo a un agente de tarea. El presupuesto fluye cuesta abajo y solo se achica — la misma forma que las cadenas de delegación que describimos en el modelo de amenazas de agentes.

Coinbase Spend Permissions: el primitivo de allowance recurrente

Las Spend Permissions de Coinbase entregan la misma idea como un contrato concreto y auditado, y su estructura de datos vale la pena leerla porque es la formulación más clara de qué es en realidad un presupuesto de agente:

struct SpendPermission {
  address account;    // smart wallet del usuario
  address spender;    // el agente / app
  address token;      // ETH o ERC-20, ej. USDC
  uint160 allowance;  // tope por período, unidad mínima
  uint48  period;     // segundos; resetea cada período
  uint48  start;
  uint48  end;
  uint256 salt;
  bytes   extraData;
}

Un único singleton SpendPermissionManager rastrea aprobaciones y aplica la contabilidad. A medida que el spender extrae fondos, el manager incrementa el uso contra el período actual; cuando el reloj cruza al siguiente período, el uso resetea a cero y el allowance se refresca. Pon el período de modo que abarque toda la ventana y obtienes un allowance de un solo uso. El usuario firma la struct con eth_signTypedData; cualquier cuenta que implemente ERC-1271 puede ser otorgante. La revocación es una sola llamada revoke, agrupable, disponible en cualquier momento.

Hay una decisión de diseño puntual acá. Spend Permissions agrega el manager como owner modular del wallet en vez de rutear a través del EntryPoint de ERC-4337. La razón declarada: evita que un paymaster gaste los tokens del usuario en gas, y mantiene el scope del control de la cuenta ajustado y plenamente conocido. Dos equipos creíbles, dos caminos de aplicación — MetaMask por caveat enforcers, Coinbase por un manager singleton — y la misma garantía observable: el wallet, no la app, aplica el tope.

Paymasters: pagar gas en la moneda que el agente ya tiene

Un agente que liquida inferencia en USDC no debería tener que mantener un saldo aparte de ETH solo para pagar gas. Los paymasters resuelven exactamente esto. Cuando una UserOperation nombra un paymaster, el EntryPoint toma el prefund de gas del depósito del paymaster en vez del sender, llama a la validación del paymaster, y ajusta cuentas en un hook post-ejecución. Importan dos modos:

• Verifying / sponsorship total — la aplicación se come todo el gas. Bueno para onboardear un agente que tiene USDC pero todavía no tiene token nativo.
• Modo ERC-20 — el agente paga su propio gas, pero en un ERC-20. El paymaster de Circle deja que las cuentas paguen gas en USDC directamente, así que un solo saldo de stablecoin cubre tanto la llamada al modelo como la transacción que la liquida.

Para una flota autónoma esto colapsa un dolor de cabeza operativo. Una moneda con fondos, un saldo que monitorear, gas abstraído — la misma simplificación que x402 trajo a la capa HTTP, ahora en la capa de settlement.

La frontera: política que viaja con el activo

Cada mecanismo de arriba ata la política a una cuenta o a una session key. Una propuesta más nueva argumenta que eso sigue siendo un nivel demasiado alto. Publicado en Ethereum Magicians el 18 de junio de 2026, el spend mandate a nivel de activo pone la barrera sobre el token mismo. Su interfaz ISpendGate expone isGated (¿esta dirección lleva un mandate?) y checkTransfer (¿está permitida esta transferencia específica?), devolviendo códigos de razón legibles por máquina — REVOKED, EXPIRED, OVER_TX_CAP, TOKEN_NOT_ALLOWED — en vez de un revert seco. Es un borrador de discusión temprano, no un ERC finalizado. Pero la dirección es reveladora: a medida que los agentes se multiplican, el ecosistema sigue empujando el límite de gasto más cerca del dinero.

Cómo mapea a x402 y EIP-3009

Vale la pena ser preciso sobre las capas, porque son complementarias, no competidoras. EIP-3009 y x402 son la autorización de settlement de un pago único: este monto exacto, a este payee exacto, firmado ahora. Account abstraction y session keys son el presupuesto permanente: este agente puede gastar hasta esto, en esta ventana, y nada más. Uno es la factura; el otro es el límite de crédito. Un operador de agentes quiere ambos — una firma por request que un facilitator pueda verificar y liquidar, dentro de un tope acotado por sesión que ninguna prompt comprometida pueda exceder.

Qué significa para LLM4Agents

LLM4Agents ya corre sobre el principio de las llaves fuera del LLM: los agentes se autentican al gateway, depositan stablecoins y pagan por llamada. Los wallets de smart account son el modelo de custodia natural para ese depósito. El wallet de fondeo de un agente debería ser un contrato con una session key acotada al gateway y un tope duro por período, no un EOA cuya llave el proceso del agente puede leer.

Concretamente, esto acota el radio de daño. Si un agente en la plataforma se compromete, una smart account acotada por sesión limita la pérdida al allowance restante del período — decenas de dólares, no todo el saldo. También hace nativo el presupuesto de flota: la attenuation deja que un operador entregue a cada agente de tarea una tajada de un presupuesto padre que solo se achica. Y los paymasters USDC estilo Circle significan que un agente necesita un solo saldo de stablecoin para pagar inferencia y liquidar on-chain, que es exactamente la forma de una cuenta de gateway por uso.

Cómo mantenerse en la frontera

Orden de operaciones para la plataforma. Primero, documentar un setup de referencia de smart account para wallets de fondeo de agentes en Base — session key acotada al payee del gateway, tope de USDC por período, revoke de una llamada — para que los operadores dejen de defaultear a EOAs. Segundo, aceptar autorizaciones de pago x402 / EIP-3009 que se originen en una session key dentro de un spend permission, y exponer el allowance restante del período al agente para que presupueste sus propias llamadas. Tercero, integrar un camino de paymaster USDC para que un agente nuevo pueda onboardear solo con stablecoins y sin token de gas nativo. Cuarto, seguir el spend mandate a nivel de activo: si el gating a nivel de token se estandariza, se vuelve un segundo freno independiente al gasto del agente que el gateway puede honrar sin confiar en la cuenta. Enviar los dos primeros ahora; convierten cada punto del modelo de amenazas sobre compromiso de llaves de una pérdida total en una acotada.