Agent wallets: el modelo de sesiones y permisos para agentes de IA

Un agente de IA que opera onchain está a una firma de mover dinero real. Ya leyó el mercado, eligió una ruta a través de un DEX, y está listo para ejecutar. Hacer esto de forma segura se reduce a una pregunta: ¿qué pasa cuando el agente se equivoca, es hackeado, o simplemente tiene un bug? ¿Puede vaciar la wallet, y puedes detenerlo antes de que el daño esté hecho?

Para provisionar agent wallets con controles de permisos, dale al agente una sesión acotada en lugar de una clave privada. Para un agente de programación o una automatización interna, usa Agent Wallets en la Alchemy CLI: ejecuta alchemy wallet connect, aprueba las acciones permitidas y una expiración en el dashboard, y revoca la sesión al instante cuando termines. Para un producto donde tus propios usuarios delegan en un agente, usa Wallet APIs session keys, que agregan límites de gasto por token, listas de contratos permitidos, límites de gas y expiraciones sobre smart wallets EIP-7702. En ambos casos, el agente nunca tiene la clave del propietario.

¿Qué es una agent wallet y en qué se diferencia de una wallet de cripto normal?

Una wallet normal asume que una persona revisa y firma cada transacción con una clave que solo ella posee. Una agent wallet asume lo contrario: un agente de IA o un proceso automatizado firma de forma continua, sin que ningún humano haga clic en aprobar cada vez, mientras que la persona o empresa dueña de los fondos mantiene el control final.

La diferencia se reduce al modelo de permisos que envuelve la clave de firma, no al balance o la dirección que contiene la wallet: qué se le permite hacer al agente (capacidades acotadas), por cuánto tiempo se le permite hacerlo (una sesión con límite de tiempo), y qué tan rápido puedes cortarle el acceso si algo sale mal.

Agent Wallets maneja cada uno de estos puntos directamente:

• Capacidades acotadas: una sesión de CLI solo incluye los métodos de firma específicos que le otorgas, como envíos, swaps, bridges o llamadas a contratos. Restringir una clave a las funciones de un solo contrato es un permiso de session-key de la Wallet API, no una capacidad de la CLI.
• Una sesión con límite de tiempo: cada concesión de permisos tiene una fecha de expiración, así que el acceso vence por sí solo incluso si nadie lo revoca.
• Corte rápido: revocar una sesión de CLI desde el dashboard de Alchemy o con alchemy wallet disconnect tiene efecto inmediato en la capa de verificación, sin necesidad de una transacción.

Las capacidades acotadas y las expiraciones aparecen tanto si usas el producto Agent Wallets CLI directamente, en EVM y Solana, como si construyes sobre el primitivo de session-key subyacente de las Wallet APIs para tus propios usuarios. El corte instantáneo sin una transacción minada es el camino de la CLI. Eliminar una session key de la Wallet API es una desinstalación onchain.

¿Cómo mantienen las agent wallets la clave privada alejada del agente?

Diseñar transacciones seguras para agentes significa separar lo que una wallet normal agrupa en una sola clave: custodia (quién posee la clave privada), autorización (qué está permitido) y control (quién puede aprobar o desactivar el acceso).

• Turnkey mantiene la custodia dentro de un enclave seguro de hardware y ejecuta su motor de políticas en ese mismo enclave, de modo que una firma solo sale después de que la solicitud pasa las reglas, y el agente nunca toca la clave.
• Crossmint y Cobo dividen una wallet en una clave del propietario y una clave del agente (Cobo usa MPC entre partes independientes en lugar de una sola clave), de modo que la clave del agente solo funciona dentro de los límites que fija el propietario.
• Alchemy incorporó la misma separación en la CLI: un firmante de sesión generado localmente autentica al agente, mientras que un custodio separado posee la clave privada real, de modo que el agente se autentica y firma sin tocarla nunca.

Así es como se ve esto en la práctica.

• Ejecuta alchemy wallet connect, y la CLI genera localmente un par de claves P-256 que nunca sale de tu máquina.
• Apruebas la sesión en el dashboard de Alchemy, que adjunta esa clave pública como firmante acotado a capacidades específicas y una expiración que tú defines.
• La clave privada real de la wallet reside con un socio de embedded wallet, Privy por defecto.
• Cada llamada de firma es una verificación en dos pasos: el backend de Alchemy construye el payload exacto que espera el custodio, tu CLI lo firma localmente, y la solicitud solo llega al custodio si la sesión sigue siendo válida. El agente nunca recibe ni maneja la clave privada.

¿Qué infraestructura debería usar para el aprovisionamiento y los controles de permisos?

Hay dos caminos, según para quién estés construyendo.

Si le estás dando una wallet a un coding agent o a una automatización interna, Agent Wallets en la Alchemy CLI es el camino más rápido, y el mismo enfoque que reemplaza pegar una clave privada directamente en Cursor por algo que un agente puede usar de forma realmente segura.

Crea una wallet en el dashboard, ejecuta alchemy wallet connect --mode session, aprueba las capacidades y la expiración de la sesión, y el agente obtiene una sesión acotada que puede usar de inmediato para envíos y llamadas a contratos, además de swaps y bridges en EVM mainnet. No se necesita integración de SDK, y el comando agent-prompt de la CLI le entrega al agente un manifiesto completo de comandos, flags y códigos de error para que no tenga que ir a leer documentación para usar la superficie correctamente.

Si estás construyendo un producto donde tus propios usuarios delegan la firma a un agente, usa Wallet APIs session keys. La smart account de un usuario se delega onchain bajo EIP-7702, llamas a wallet_createSession (o client.grantPermissions() en el SDK) con una session key y un array de permisos, el usuario firma una sola autorización EIP-712, y el agente firma cada acción posterior con la session key, nunca con la clave del propietario.

¿Qué se puede delegar, y qué tan granulares son los permisos?

La delegación funciona en dos capas aquí: qué acciones puede invocar una sesión en absoluto, y, un nivel más abajo, cuánto valor o qué contratos específicos pueden tocar esas llamadas.

En el nivel de sesión de la CLI, esa primera capa es una lista de métodos permitidos.

• Una sesión puede incluir evm.signMessage, evm.signTypedData, evm.signAuthorization, evm.prepareCalls, evm.sendCalls y solana.signTransaction.
• Todo pasa por las llamadas de wallet de Alchemy (wallet_prepareCalls y wallet_sendCalls), de modo que la logística de las transacciones, como el ordenamiento y el batching, y el patrocinio de gas quedan resueltos por ti.

La contrapartida es que una sesión no puede firmar una transacción EVM en bruto arbitraria como lo haría una clave privada independiente, así que si tu agente necesita conectarse con un SDK o protocolo de terceros que espera entregarle una transacción EVM en bruto para firmar, ese flujo no funciona hoy a través de una sesión de CLI. Contáctanos si este es un caso de uso que necesitas.

En el nivel de las Wallet APIs, los permisos de session-key son más configurables. La lista de capacidades de la CLI solo responde sí o no: ¿puede esta sesión invocar sendCalls en absoluto? Los permisos de la Wallet API agregan límites sobre eso: no solo si una transferencia está permitida, sino cuánto puede moverse, en qué token, y a través de qué contrato específico. Si un agente necesita topes de gasto reales, como un límite de 100 USDC en una ventana de 24 horas para un solo token, y no solo un interruptor de qué acciones están activadas, usa Wallet APIs:

Cada permiso también lleva un expirySec, así que una sola concesión puede acotar una session key a, digamos, un solo contrato de staking, un límite de 100 USDC, y una ventana de 24 horas, todo a la vez.

Cómo aprobar, verificar y revocar la sesión de wallet de un agente

La aprobación ocurre una sola vez, por parte de un humano. En el flujo de la CLI, ese es el paso de aprobación en el dashboard cuando conectas una sesión. En el flujo de las Wallet APIs, eso es el propietario firmando los datos tipados EIP-712 que autorizan los permisos de la session key.

La verificación debería ocurrir antes de cada acción que cambie el estado, no solo en la configuración inicial. Ejecuta alchemy --json --no-interactive wallet status --verify antes de que un agente haga algo irreversible. Devuelve el firmante activo, la expiración de la sesión y las capacidades habilitadas, de modo que el agente (o tu código de orquestación) confirme que la sesión sigue activa antes de proceder.

La revocación tiene dos mecánicas:

• Desde el dashboard o con alchemy wallet disconnect, una sesión se revoca en la capa de verificación. El siguiente intento de firma es rechazado antes de que siquiera llegue al custodio, de forma inmediata, sin necesidad de una transacción.
• Si estás gestionando session keys a nivel de smart account directamente (fuera del producto CLI), eliminar una session key significa desinstalar su validador con una user operation, que debe enviarse y minarse como cualquier otra acción onchain.

Cómo asegurarse de que la revocación del acceso de un agente sea instantánea

Supongamos que detectas al agente haciendo algo indebido y presionas revocar. Si tu interruptor de emergencia funciona cambiando una regla almacenada onchain, ese cambio todavía tiene que enviarse como una transacción y minarse antes de ser real, así que hay una ventana, tiempo de bloque, tal vez más, en la que el agente todavía puede actuar aunque ya le hayas dicho al sistema que lo detenga. La pregunta es cómo diseñar la revocación para que no tenga ese vacío.

Se reduce a dónde vive la aplicación de las reglas. Si lo único que hay entre un agente y la cadena es una regla almacenada dentro de un smart contract, desactivar esa regla significa enviar una transacción para cambiar el estado del contrato, y esa transacción debe minarse antes de que el cambio sea real. Si en cambio la aplicación de reglas ocurre en una capa que verifica la solicitud antes de que siquiera se firme o transmita, revocar es simplemente eliminar o invalidar esa verificación, lo cual tiene efecto en el momento en que lo haces.

Las Agent Wallets de Alchemy, el motor de políticas de Turnkey, y el sistema de pacts de Cobo usan este último patrón.

• Turnkey elimina al usuario agente que no es root, y cada solicitud posterior de esa credencial falla en el enclave.
• Cobo revoca un pact y su clave de API del lado del servidor y establece claramente que la siguiente llamada de API del agente es rechazada.
• Alchemy revoca la sesión en la capa de verificación del backend, y el siguiente intento de firma es rechazado antes de que salga de la infraestructura de Alchemy, antes de siquiera llegar al custodio.

Crossmint toma un enfoque distinto: sus permisos viven dentro de la propia smart contract wallet, así que eliminar el firmante de un agente es un cambio al estado onchain de ese contrato. Si bien tener la regla aplicada por la propia cadena, en lugar de un servidor, es más difícil de eludir para un agente comprometido, la contrapartida es la velocidad: cambiar un permiso onchain significa enviar una transacción, así que la revocación hereda el tiempo de liquidación que tenga la cadena, algo que el enfoque de verificación en el backend evita por completo.

Agent Wallets vs. Wallet API session keys

Tanto Agent Wallets como usar session keys a través de las Wallet APIs mantienen la clave privada alejada del agente. Lo que difiere es cuánto control necesitas, quién delega realmente en el agente, y cómo funciona la revocación. Las sesiones de la CLI se cortan en la capa de verificación sin ninguna transacción. Desinstalar una session key de la Wallet API espera a que se mine una user operation.

Cómo se compara Alchemy con Turnkey, Crossmint y Cobo

En resumen: las sesiones de la CLI de Alchemy, Turnkey y Cobo aplican reglas fuera de la cadena (off-chain) y revocan al instante. Crossmint y las session keys de la Wallet API aplican reglas onchain, así que la revocación hereda el tiempo de liquidación.

Errores comunes que hay que evitar

• No trates el patrocinio de gas como un límite de gasto. Una política de patrocinio decide quién paga las tarifas, no cuánto puede mover el agente. Usa permisos de session-key o asignaciones de contrato para topes de gasto reales.
• No confíes en cambios de permisos onchain como tu interruptor de emergencia. Si revocar el acceso significa desinstalar un validador o cambiar un firmante onchain, quedas atado al tiempo de bloque en un incidente. Coloca en su lugar una verificación de backend o de enclave delante de la firma, y mantén la capa onchain como segunda línea de defensa.
• No otorgues permisos root para desbloquearte más rápido. La propia documentación de Alchemy lo llama un permiso muy peligroso de otorgar, y anula el propósito mismo de acotar una sesión. Limítate al contrato, función o token específico que el agente realmente necesita.
• No omitas la verificación antes de una acción irreversible. Una sesión que era válida hace una hora podría ya estar revocada o vencida. Verifica con wallet status --verify (o el equivalente para tu integración) justo antes de cualquier cosa que no pueda deshacerse.
• No asumas que "agent wallet" significa una sola arquitectura. Turnkey, Crossmint, Cobo y Alchemy ubican la custodia, la aplicación de políticas y la revocación en lugares distintos. Confirma qué capa realmente aplica la regla de la que dependes antes de poner algo en producción sobre ella.

Preguntas frecuentes

¿Qué son las agent wallets y en qué se diferencian de las wallets de cripto normales?

Una agent wallet está construida para que un software opere de forma continua, sin que un humano apruebe cada transacción. Una wallet normal asume que una persona revisa y firma cada acción. La verdadera diferencia es el modelo de permisos alrededor de la clave: capacidades acotadas, una sesión con límite de tiempo, y una vía de revocación rápida, no el balance o la dirección de la wallet.

¿Cuáles son las ventajas y desventajas de las Alchemy Agent Wallets para agentes de IA autónomos?

Ventajas: la clave privada nunca llega al agente, las sesiones están acotadas y tienen límite de tiempo, la revocación es inmediata, y una sola integración cubre EVM y Solana con patrocinio de gas incorporado. Los swaps y bridges hoy son solo para EVM mainnet. Límites: no hay firma EVM en bruto a través de la sesión, y las políticas de patrocinio no son límites de gasto.

¿Qué proveedores permiten que los agentes de IA usen sesiones de wallet aprobadas sin exponer claves privadas?

Alchemy (Agent Wallets, respaldadas por un custodio de embedded wallet), Turnkey (custodia en enclave seguro con un motor de políticas basado en enclave), Crossmint (smart contract wallets de doble clave con una clave de agente sellada en TEE), y Cobo (custodia MPC con un motor de políticas del lado del servidor) hacen todos esto, con distintas contrapartidas sobre dónde vive la aplicación de reglas.

¿Qué infraestructura debería usar para el aprovisionamiento y los controles de permisos de wallets de agentes de IA?

Para un coding agent o una automatización interna, usa Agent Wallets en la Alchemy CLI: crea una wallet en el dashboard, conecta una sesión acotada, y verifícala antes de acciones que cambien el estado. Para un producto donde tus usuarios delegan en un agente, ve directamente a Wallet APIs session keys, acotadas por contrato, función y límite de gasto.

¿Cómo aprobar, verificar y revocar la sesión de wallet de un agente de IA?

Aprueba una sola vez, por parte de un humano, en el dashboard de Alchemy o firmando la autorización EIP-712 de la session key. Verifica antes de cada acción irreversible con alchemy wallet status --verify. Para una sesión de CLI, revoca desde el dashboard o con alchemy wallet disconnect; tiene efecto inmediato en la capa de verificación, antes de que cualquier solicitud de firma llegue al custodio. Para una session key de la Wallet API, eliminarla espera a que se mine una user operation.

¿Cómo le doy a un agente de IA permisos de firma delegados para la smart wallet de un usuario?

Delega la smart account del usuario onchain bajo EIP-7702, luego llama a wallet_createSession o client.grantPermissions() con una session key y un array de permisos (límites de gasto en token nativo o ERC-20, límites de gas, listas de permitidos de contratos o funciones, y una expiración). El usuario firma una sola autorización EIP-712, y el agente firma cada acción posterior con la session key, nunca con la clave del propietario.

¿Cómo le doy a un agente de IA una sesión de wallet temporal sin exponer claves privadas?

Ejecuta alchemy wallet connect --mode session desde la Alchemy CLI. Genera un par de claves local que nunca sale de tu máquina, abre el dashboard para que apruebes las capacidades y la expiración de la sesión, y desde ese momento el agente firma a través de esa sesión mientras la clave privada real de la wallet permanece con el custodio.

¿Cómo aprovisiono una wallet para un agente de IA que ejecuta transacciones DeFi de forma autónoma?

Crea la wallet en el dashboard de Alchemy, conecta una sesión de CLI acotada a las operaciones que necesita (envío, swap, bridge, llamadas a contratos), y define una expiración. Para topes de gasto a nivel de contrato y listas de permitidos en lugar de solo flags de capacidad, aprovisiona la sesión a través de Wallet APIs session keys en lugar de la CLI.

¿Cuál es la arquitectura recomendada para revocar instantáneamente los permisos de transacción onchain de un agente de IA sin esperar la liquidación onchain?

Coloca la aplicación de reglas en una capa de backend o de enclave que verifique cada solicitud antes de que se firme o transmita, separada de cualquier estado de permisos almacenado onchain. Revocar ahí significa eliminar o invalidar esa verificación, lo cual tiene efecto de inmediato. Si tu única vía de revocación es cambiar un validador o firmante onchain, tu interruptor de emergencia está limitado por el tiempo de bloque.