--- title: "Agent wallets: el modelo de sesión y permisos para agentes de IA" description: "Cómo los agentes de IA obtienen acceso a wallets con alcance limitado y revocable sin tener las private keys: sessions, delegated signing y revocación instantánea." --- # Agent wallets: el modelo de sesión y permisos para agentes de IA Un agente de IA que opera onchain está a una firma de distancia de mover dinero real. Ya leyó el mercado, eligió una ruta a través de un DEX, y está listo para ejecutar. Enviar esto de forma segura se reduce a una pregunta: ¿qué pasa cuando el agente se equivoca, es secuestrado, o simplemente tiene un bug? ¿Puede vaciar la wallet, y puedes detenerlo antes de que ocurra el daño? ## ¿Qué es una wallet de agente, y en qué se diferencia de una wallet de crypto normal? Una wallet normal asume que una persona revisa y firma cada transacción con una clave que solo ella posee. Una wallet de agente asume lo contrario: un agente de IA o proceso automatizado firma continuamente, 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 en la wallet: qué puede hacer el agente (capacidades acotadas), por cuánto tiempo puede hacerlo (una sesión con límite de tiempo), y qué tan rápido puedes cortarle el acceso si algo sale mal. [Agent Wallets](https://www.alchemy.com/docs/agent-wallets) gestiona 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 Wallet API](https://www.alchemy.com/docs/wallets/smart-contracts/modular-account-v2/session-keys/session-key-permissions), no una capacidad del CLI. - Una sesión con límite de tiempo: cada concesión de permiso lleva una fecha de expiración, así que el acceso se vence por sí solo aunque nadie lo revoque. - Corte rápido: revocar una sesión de CLI desde el dashboard de Alchemy o con `alchemy wallet disconnect` tiene efecto en la capa de verificación de inmediato, sin necesidad de una transacción. Las capacidades acotadas y las expiraciones aparecen tanto si usas el producto Agent Wallets del CLI directamente, en EVM y Solana, como si estás construyendo sobre la primitiva subyacente de session keys de Wallet APIs para tus propios usuarios. El corte instantáneo sin una transacción minada es el camino del CLI. Quitar una session key de Wallet API es una desinstalación onchain. ## ¿Cómo mantienen las wallets de agente la clave privada alejada del agente? Diseñar transacciones seguras para agentes implica separar lo que una wallet normal agrupa en una sola clave: custodia (quién tiene la clave privada), autorización (qué está permitido) y control (quién puede aprobar o desactivarlo). - [Turnkey](https://docs.turnkey.com/features/policies/delegated-access/agentic-wallets) 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](https://docs.crossmint.com/wallets/concepts/signers) y [Cobo](https://www.cobo.com/products/agentic-wallet/manual/developer/technical-architecture) en cambio dividen una wallet entre una clave de owner y una clave de 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 owner. - Alchemy [incorporó la misma separación en el CLI](https://www.alchemy.com/blog/agent-wallets-alchemy-cli): un firmante de sesión generado localmente autentica al agente, mientras que un custodio aparte mantiene la clave privada real, de modo que el agente se autentica y firma sin tocarla nunca. Así se ve esto en la práctica. - Ejecuta `alchemy wallet connect`, y el 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, lo que adjunta esa clave pública como firmante acotado a capacidades específicas y a una expiración que tú defines. - La clave privada real de la wallet queda con un partner 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 el custodio espera, 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ías 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 el Alchemy CLI](https://www.alchemy.com/docs/agent-wallets) es el camino más rápido, y el mismo enfoque que reemplaza [pegar una clave privada directamente en Cursor](https://www.alchemy.com/overviews/stop-pasting-private-keys-into-cursor) por algo que un agente realmente pueda usar de forma 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 hace falta integrar un SDK, y el comando `agent-prompt` del CLI le entrega al agente un manifiesto completo de comandos, flags y códigos de error, para que no tenga que 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 [session keys de Wallet APIs](https://www.alchemy.com/docs/wallets/reference/wallet-apis-session-keys/api). La smart account de un usuario queda delegada onchain bajo [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702), llamas a `wallet_createSession` (o a `client.grantPermissions()` en el SDK) con una session key y un arreglo de permisos, el usuario firma una autorización EIP-712 única, y el agente firma cada acción después con la session key, nunca con la clave del owner. ## ¿Qué puedes delegar, y qué tan granulares son los permisos? La delegación funciona en dos capas aquí: qué acciones puede llamar una sesión en absoluto, y, un nivel más profundo, cuánto valor o qué contratos específicos pueden tocar esas llamadas. A nivel de sesión del 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 wallet calls de Alchemy (`wallet_prepareCalls` y `wallet_sendCalls`) de modo que la logística de la transacción, como el ordenamiento y el batching, y el gas sponsorship se manejan por ti. La contrapartida es que una sesión no puede firmar una transacción EVM raw arbitraria como sí puede hacerlo una clave privada independiente, así que si tu agente necesita conectarse a un SDK o protocolo de terceros que espera pasarle una transacción EVM raw para firmar, ese flujo hoy no funciona a través de una sesión de CLI. [Contáctanos](https://www.alchemy.com/contact-sales) si este es un caso de uso que necesitas. A nivel de Wallet APIs, los [permisos de session key](https://www.alchemy.com/docs/wallets/smart-contracts/modular-account-v2/session-keys/session-key-permissions) son más configurables. La lista de capacidades del CLI solo responde sí o no: ¿puede esta sesión llamar a `sendCalls` en absoluto? Los permisos de 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 sobre un token, y no solo un interruptor sobre qué acciones están habilitadas, usa Wallet APIs: native-token-transfer

", tooltip: "", icon: "", }, "2": { title: "

Caps how much native token (ETH, say) the key can move, via a fixed allowance

", tooltip: "", icon: "", }, id: 0, }, { "1": { title: "

erc20-token-transfer

", tooltip: "", icon: "", }, "2": { title: "

Caps cumulative ERC-20 transfers and approvals for one token contract to a set allowance

", tooltip: "", icon: "", }, id: 1, }, { "1": { title: "

gas-limit

", tooltip: "", icon: "" }, "2": { title: "

Caps how much gas the key can spend across transactions

", tooltip: "", icon: "", }, id: 2, }, { "1": { title: "

contract-access

", tooltip: "", icon: "", }, "2": { title: "

Allows every function on one named contract, nothing else

", tooltip: "", icon: "", }, id: 3, }, { "1": { title: "

functions-on-contract / account-functions / functions-on-all-contracts

", tooltip: "", icon: "", }, "2": { title: "

Allows only specific function selectors, on one contract, on the account itself, or everywhere

", tooltip: "", icon: "", }, id: 4, }, { "1": { title: "

root

", tooltip: "", icon: "" }, "2": { title: "

Full access to everything, a very dangerous permission to grant. Use judiciously.

", tooltip: "", icon: "", }, id: 5, }, ], }} /> Todo 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 tope 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 vez, hecha por un humano. En el flujo de CLI, eso es el paso de aprobación en el dashboard cuando conectas una sesión. En el flujo de Wallet APIs, eso es el owner 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 cambia 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, para que el agente (o tu código de orquestación) confirme que la sesión sigue activa antes de continuar. 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 llegar siquiera al custodio, de inmediato, sin necesidad de una transacción. - Si gestionas session keys a nivel de smart account directamente (fuera del producto CLI), [quitar una session key](https://www.alchemy.com/docs/wallets/smart-contracts/modular-account-v2/session-keys/removing-session-keys) implica desinstalar su validador con una user operation, que debe enviarse y minarse como cualquier otra acción onchain. ## Cómo asegurarte de que revocar el acceso de un agente sea instantáneo Digamos que detectas al agente haciendo algo indebido y presionas revocar. Si tu kill switch funciona cambiando una regla almacenada onchain, ese cambio todavía tiene que enviarse como transacción y minarse antes de ser real, así que hay una ventana, un block time, quizás más, donde el agente aún 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 hueco. Se reduce a dónde vive la aplicación de reglas. Si lo único que se interpone entre un agente y la cadena es una regla almacenada dentro de un smart contract, desactivar esa regla implica enviar una transacción para cambiar el estado del contrato, y esa transacción tiene que minarse antes de que el cambio sea real. Si la aplicación de reglas ocurre en cambio en una capa que verifica la solicitud antes de que sea firmada o difundida, revocar es simplemente borrar o invalidar esa verificación, lo cual tiene efecto en el momento en que lo haces. 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 con esa credencial falla en el enclave. - Cobo revoca un pact y su API key en el servidor y afirma sin rodeos que la próxima llamada de API del agente será rechazada. - Alchemy revoca la sesión en la capa de verificación del backend, y el siguiente intento de firma es rechazado antes de salir de la infraestructura de Alchemy, antes de llegar siquiera al custodio. Crossmint adopta un enfoque distinto: sus permisos viven dentro de la smart contract wallet misma, así que quitar el firmante de un agente es un cambio en el estado onchain de ese contrato. Si bien el hecho de que la regla la haga cumplir la cadena misma, en lugar de un servidor, [es más difícil de esquivar para un agente comprometido](https://www.crossmint.com/learn/agent-wallets-compared), la contrapartida es la velocidad: cambiar un permiso onchain implica enviar una transacción, así que la revocación hereda el tiempo de settlement que tenga la cadena, algo que el enfoque de verificación en el backend evita por completo. ## Agent Wallets vs. session keys de Wallet API Tanto Agent Wallets como el uso de session keys vía 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 CLI se cortan en la capa de verificación sin necesidad de transacción. Desinstalar una session key de Wallet API espera a que se mine una user operation. You're wiring up a coding agent or an internal script and want it signing in minutes, no SDK integration required.

", tooltip: "", icon: "", }, "2": { title: "

You're building a product where your own end users delegate signing to an agent on their own smart account.

", tooltip: "", icon: "", }, id: 0, }, { "1": { title: "

A yes/no capability list, can this session send, swap, bridge, or make contract calls, is enough scoping for what the agent does.

", tooltip: "", icon: "", }, "2": { title: "

You need an actual spend cap, like a fixed allowance on native token or one ERC-20, enforced by the permission itself.

", tooltip: "", icon: "", }, id: 1, }, { "1": { title: "

The Alchemy dashboard is a fine place to create the wallet and approve sessions by hand.

", tooltip: "", icon: "", }, "2": { title: "

You need contract- or function-level allowlists as the real enforcement boundary, not just a capability flag.

", tooltip: "", icon: "", }, id: 2, }, { "1": { title: "

The CLI already handles what the agent needs to do: sending, batching calls, and getting its gas sponsored across EVM and Solana, plus swapping and bridging on EVM mainnet.

", tooltip: "", icon: "", }, "2": { title: '

You need to grant session keys from your own app. Neither path signs an arbitrary raw EVM transaction for a third-party SDK today. Reach out to us if that\'s the use case.

', tooltip: "", icon: "", }, id: 3, }, ], }} /> ## Cómo se compara Alchemy con Turnkey, Crossmint y Cobo Alchemy Agent Wallets

", tooltip: "", icon: "" }, "2": { title: "

Embedded wallet partner (Privy by default) for CLI sessions, or any signer you choose via Wallet APIs

", tooltip: "", icon: "", }, "3": { title: "

Backend session-verification layer for CLI sessions; onchain session-key permissions on the smart account for custom Wallet APIs integrations

", tooltip: "", icon: "", }, "4": { title: "

Yes for CLI sessions, via dashboard or wallet disconnect. Wallet API session keys: no, uninstalling the validator is a mined user operation

", tooltip: "", icon: "", }, id: 0, }, { "1": { title: "

Turnkey

", tooltip: "", icon: "" }, "2": { title: "

AWS Nitro secure enclave (TEE)

", tooltip: "", icon: "", }, "3": { title: "

Policy engine running inside the same enclave, evaluated before every signature

", tooltip: "", icon: "", }, "4": { title: "

Yes, delete the non-root agent user or toggle a DENY policy

", tooltip: "", icon: "", }, id: 1, }, { "1": { title: "

Cobo Agentic Wallet

", tooltip: "", icon: "" }, "2": { title: "

MPC across independent parties, no single key

", tooltip: "", icon: "", }, "3": { title: "

Three-stage server-side policy engine (permission, rule, counter), evaluated on every request

", tooltip: "", icon: "", }, "4": { title: "

Yes, freeze or revoke a pact; the API key gets invalidated server-side

", tooltip: "", icon: "", }, id: 2, }, { "1": { title: "

Crossmint

", tooltip: "", icon: "" }, "2": { title: "

Dual-key smart contract wallet: owner key plus an agent key sealed in a TEE

", tooltip: "", icon: "", }, "3": { title: "

Onchain, inside the smart contract itself (per-transaction limits, allowlists, time windows checked at execution)

", tooltip: "", icon: "", }, "4": { title: "

By design, no. Removing a signer changes the wallet contract's onchain signer set, so it settles like any other onchain operation rather than a synchronous backend check

", tooltip: "", icon: "", }, id: 3, }, ], }} /> En resumen: las sesiones de CLI de Alchemy, Turnkey y Cobo aplican las reglas fuera de la cadena y revocan de forma instantánea. Crossmint y las session keys de Wallet API las aplican onchain, así que la revocación hereda el tiempo de settlement. ## Errores comunes que hay que evitar - **No trates el gas sponsorship como un límite de gasto.** Una política de sponsorship decide quién paga las fees, no cuánto puede mover el agente. Usa permisos de session key o allowances de contrato para topes de gasto reales. - **No dependas de cambios de permisos onchain como tu kill switch.** Si revocar el acceso implica desinstalar un validador o cambiar un firmante onchain, quedas sujeto al block time en medio de un incidente. Pon en cambio una verificación de backend o de enclave delante de la firma, y deja 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 describe como un permiso muy peligroso de otorgar, y anula el propósito mismo de acotar una sesión. Limita el alcance al contrato, función o token específico que el agente realmente necesita. - **No te saltes 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) inmediatamente antes de cualquier cosa que no se pueda deshacer. - **No asumas que "wallet de agente" 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 aplica realmente la regla de la que dependes antes de lanzar algo basado en ella. ## Preguntas frecuentes ### ¿Qué son las wallets de agente y en qué se diferencian de las wallets de crypto normales? Una wallet de agente está construida para que un software opere continuamente, sin que un humano apruebe cada transacción. Una wallet normal asume que una persona revisa y firma cada acción. La diferencia real está en 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 Alchemy Agent Wallets para agentes de IA autónomos? Ventajas: la clave privada nunca llega al agente, las sesiones son acotadas y con límite de tiempo, la revocación es inmediata, y una sola integración cubre EVM y Solana con gas sponsorship incorporado. Los swaps y bridges hoy son solo para EVM mainnet. Límites: no hay firma de EVM raw a través de la sesión, y las políticas de sponsorship no son límites de gasto. ### ¿Qué proveedores permiten que los agentes de IA usen sesiones de wallet aprobadas sin exponer claves privadas? [Alchemy](https://www.alchemy.com/docs/agent-wallets) (Agent Wallets, respaldado por un custodio de embedded wallet), [Turnkey](https://docs.turnkey.com/features/policies/delegated-access/agentic-wallets) (custodia en enclave seguro con un motor de políticas basado en enclave), [Crossmint](https://docs.crossmint.com/wallets/concepts/signers) (smart contract wallets de doble clave con una clave de agente sellada en un TEE), y [Cobo](https://www.cobo.com/products/agentic-wallet/manual/developer/technical-architecture) (custodia MPC con un motor de políticas server-side) hacen esto, con distintas contrapartidas en 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 el Alchemy CLI](https://www.alchemy.com/docs/agent-wallets): 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 directo a [session keys de Wallet APIs](https://www.alchemy.com/docs/wallets/reference/wallet-apis-session-keys/api), acotadas por contrato, función y límite de gasto. ### ¿Cómo apruebo, verifico y revoco la sesión de wallet de un agente de IA? Aprueba una vez, hecho por 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, revócala desde el dashboard o con `alchemy wallet disconnect`; tiene efecto de inmediato en la capa de verificación, antes de que cualquier solicitud de firma llegue al custodio. Para una session key de Wallet API, [quitarla](https://www.alchemy.com/docs/wallets/smart-contracts/modular-account-v2/session-keys/removing-session-keys) espera a que se mine una user operation. ### ¿Cómo le doy a un agente de IA permisos de firma delegados sobre la smart wallet de un usuario? Delega la smart account del usuario onchain bajo [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702), luego llama a `wallet_createSession` o `client.grantPermissions()` con una session key y un [arreglo de permisos](https://www.alchemy.com/docs/wallets/smart-contracts/modular-account-v2/session-keys/session-key-permissions) (límites de gasto en token nativo o ERC-20, límites de gas, allowlists de contratos o funciones, y una expiración). El usuario firma una autorización EIP-712 única, y el agente firma cada acción después con la session key, nunca con la clave del owner. ### ¿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 el [Alchemy CLI](https://www.alchemy.com/docs/agent-wallets). 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 a partir de ahí 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 de 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 y allowlists a nivel de contrato en lugar de solo flags de capacidad, aprovisiona la sesión a través de [session keys de Wallet APIs](https://www.alchemy.com/docs/wallets/reference/wallet-apis-session-keys/api) en vez del CLI. ### ¿Cuál es la arquitectura recomendada para revocar instantáneamente los permisos de transacción onchain de un agente de IA sin esperar el settlement onchain? Coloca la aplicación de reglas en una capa de backend o enclave que verifique cada solicitud antes de que sea firmada o difundida, separada de cualquier estado de permisos almacenado onchain. Revocar ahí significa borrar 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 kill switch queda limitado por el block time.