--- title: "Agent wallets: o modelo de sessão e permissões para agentes de IA" description: "Como agentes de IA obtêm acesso a wallets com escopo definido e revogável, sem manter chaves privadas: sessions, delegated signing e revogação instantânea." --- # Agent wallets: o modelo de sessão e permissões para agentes de IA Um agente de IA operando onchain está a uma assinatura de movimentar dinheiro de verdade. Ele leu o mercado, escolheu uma rota através de um DEX, e está pronto para executar. Fazer isso com segurança se resume a uma pergunta: o que acontece quando o agente erra, é sequestrado, ou simplesmente tem um bug? Ele consegue drenar a carteira, e você consegue impedi-lo antes que o dano seja feito? ## O que é uma carteira de agente, e como ela difere de uma carteira crypto comum? Uma carteira comum assume que uma pessoa revisa e assina cada transação com uma chave que só ela possui. Uma carteira de agente assume o oposto: um agente de IA ou processo automatizado assina continuamente, sem nenhum humano clicando em "aprovar" a cada vez, enquanto a pessoa ou empresa dona dos fundos mantém o controle final. A diferença está no modelo de permissões que envolve a chave de assinatura, não no saldo ou endereço da carteira: o que o agente tem permissão para fazer (capacidades delimitadas), por quanto tempo ele tem essa permissão (uma sessão com prazo definido), e com que velocidade você consegue cortar o acesso se algo der errado. O [Agent Wallets](https://www.alchemy.com/docs/agent-wallets) lida diretamente com cada um desses pontos: - Capacidades delimitadas: uma sessão CLI inclui apenas os métodos de assinatura específicos que você concede, como sends, swaps, bridges ou contract calls. Restringir uma chave às funções de um único contrato é uma [permissão de session key da Wallet API](https://www.alchemy.com/docs/wallets/smart-contracts/modular-account-v2/session-keys/session-key-permissions), não uma capacidade de CLI. - Uma sessão com prazo definido: toda concessão carrega uma expiração, então o acesso caduca por conta própria mesmo que ninguém o revogue. - Desligamento rápido: revogar uma sessão CLI pelo dashboard da Alchemy ou com `alchemy wallet disconnect` tem efeito imediato na camada de verificação, sem necessidade de transação. Capacidades delimitadas e expirações aparecem tanto se você estiver usando o produto Agent Wallets CLI diretamente, em EVM e Solana, quanto se estiver construindo sobre a primitiva subjacente de session-key das Wallet APIs para seus próprios usuários. Desligamento instantâneo sem uma transação minerada é o caminho do CLI. Remover uma session key da Wallet API é uma desinstalação onchain. ## Como as carteiras de agente mantêm a private key longe do agente? Projetar transações seguras para agentes significa separar o que uma carteira comum agrupa em uma única chave: custódia (quem detém a private key), autorização (o que é permitido) e controle (quem pode aprovar ou desligar o acesso). - A [Turnkey](https://docs.turnkey.com/features/policies/delegated-access/agentic-wallets) mantém a custódia dentro de um enclave seguro de hardware e roda seu motor de políticas nesse mesmo enclave, de modo que uma assinatura só sai depois que a solicitação passa pelas regras, e o agente nunca toca na chave. - A [Crossmint](https://docs.crossmint.com/wallets/concepts/signers) e a [Cobo](https://www.cobo.com/products/agentic-wallet/manual/developer/technical-architecture) dividem uma carteira em uma owner key e uma agent key (a Cobo usa MPC entre partes independentes em vez de uma única chave), de modo que a chave do agente só funciona dentro dos limites que o owner define. - A Alchemy [incorporou a mesma separação no CLI](https://www.alchemy.com/blog/agent-wallets-alchemy-cli): um session signer gerado localmente autentica o agente, enquanto um custodiante separado detém a private key real, de modo que o agente autentica e assina sem nunca tocar nela. Veja como isso funciona na prática. - Ao rodar `alchemy wallet connect`, o CLI gera localmente um keypair P-256 que nunca sai da sua máquina. - Você aprova a sessão no dashboard da Alchemy, que anexa essa chave pública como um signer delimitado a capacidades específicas e uma expiração definida por você. - A private key real da carteira fica com um parceiro de embedded wallet, Privy por padrão. - Toda chamada de assinatura passa por uma verificação em duas etapas: o backend da Alchemy monta o payload exato que o custodiante espera, seu CLI o assina localmente, e a solicitação só chega ao custodiante se a sessão ainda for válida. O agente nunca recebe ou manuseia a private key. ## Qual infraestrutura usar para provisionamento e controles de permissão? Há dois caminhos, dependendo de para quem você está construindo. Se você está dando uma carteira a um coding agent ou a uma automação interna, o [Agent Wallets no Alchemy CLI](https://www.alchemy.com/docs/agent-wallets) é o caminho mais rápido, e a mesma abordagem que substitui [colar uma private key diretamente no Cursor](https://www.alchemy.com/overviews/stop-pasting-private-keys-into-cursor) por algo que um agente pode de fato usar com segurança. Crie uma carteira no dashboard, rode `alchemy wallet connect --mode session`, aprove as capacidades e a expiração da sessão, e o agente recebe uma sessão delimitada que pode usar imediatamente para sends e contract calls, além de swaps e bridges na EVM mainnet. Não é necessária integração de SDK, e o comando `agent-prompt` do CLI entrega ao agente um manifesto completo de comandos, flags e códigos de erro, então ele não precisa ler documentação para usar a superfície corretamente. Se você está construindo um produto onde seus próprios usuários delegam a assinatura a um agente, use as [session keys das Wallet APIs](https://www.alchemy.com/docs/wallets/reference/wallet-apis-session-keys/api). A smart account de um usuário é delegada onchain sob o [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702), você chama `wallet_createSession` (ou `client.grantPermissions()` no SDK) com uma session key e um array de permissões, o usuário assina uma autorização EIP-712, e a partir daí o agente assina cada ação com a session key, nunca com a chave do owner. ## O que pode ser delegado, e qual o nível de granularidade das permissões? A delegação funciona em duas camadas aqui: quais ações uma sessão pode chamar, e, um nível mais abaixo, quanto valor ou quais contratos específicos essas chamadas podem afetar. No nível da sessão CLI, essa primeira camada é uma lista de métodos permitidos. - Uma sessão pode incluir `evm.signMessage`, `evm.signTypedData`, `evm.signAuthorization`, `evm.prepareCalls`, `evm.sendCalls` e `solana.signTransaction`. - Tudo passa pelas wallet calls da Alchemy (`wallet_prepareCalls` e `wallet_sendCalls`), de modo que a logística das transações, como ordenação e batching, e o patrocínio de gas ficam a cargo da plataforma. A contrapartida é que uma sessão não pode assinar uma transação EVM bruta arbitrária como uma private key isolada consegue, então se seu agente precisa se conectar a um SDK ou protocolo de terceiros que espera passar a ele uma transação EVM bruta para assinar, esse fluxo hoje não funciona através de uma sessão CLI. [Entre em contato conosco](https://www.alchemy.com/contact-sales) se esse for um caso de uso que você precisa. No nível das Wallet APIs, as [permissões de session-key](https://www.alchemy.com/docs/wallets/smart-contracts/modular-account-v2/session-keys/session-key-permissions) são mais configuráveis. A lista de capacidades do CLI só responde sim ou não: essa sessão pode chamar `sendCalls` ou não? As permissões da Wallet API acrescentam limites a isso: não apenas se uma transferência é permitida, mas quanto pode ser movido, em qual token, e através de qual contrato específico. Se um agente precisa de limites de gastos reais, como um teto de 100 USDC em uma janela de 24 horas para um token, e não apenas um switch de quais ações estão ativadas, use as Wallet APIs: native-token-transfer

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

Limita quanto native token (ETH, por exemplo) a chave pode movimentar, via um allowance fixo

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

erc20-token-transfer

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

Limita as transferências e aprovações acumuladas de ERC-20 para um contrato de token a um allowance definido

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

gas-limit

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

Limita quanto gas a chave pode gastar entre transações

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

contract-access

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

Permite todas as funções de um contrato nomeado, e nada além disso

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

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

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

Permite apenas seletores de função específicos, em um contrato, na própria account, ou em todos os lugares

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

root

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

Acesso total a tudo, uma permissão muito perigosa de conceder. Use com critério.

", tooltip: "", icon: "", }, id: 5, }, ], }} /> Toda permissão também carrega um `expirySec`, de modo que uma única concessão pode delimitar uma session key a, digamos, um contrato de staking, um teto de 100 USDC e uma janela de 24 horas, tudo ao mesmo tempo. ## Como aprovar, verificar e revogar a sessão de carteira de um agente A aprovação acontece uma vez, por um humano. No fluxo CLI, essa é a etapa de aprovação no dashboard quando você conecta uma sessão. No fluxo das Wallet APIs, é o owner assinando os dados tipados EIP-712 que autorizam as permissões da session key. A verificação deve acontecer antes de toda ação que altera estado, não apenas na configuração inicial. Rode `alchemy --json --no-interactive wallet status --verify` antes de um agente fazer algo irreversível. Ele retorna o signer ativo, a expiração da sessão e as capacidades habilitadas, de modo que o agente (ou seu código de orquestração) confirme que a sessão ainda está ativa antes de prosseguir. A revogação tem duas mecânicas: - Pelo dashboard ou com `alchemy wallet disconnect`, uma sessão é revogada na camada de verificação. A próxima tentativa de assinatura é rejeitada antes mesmo de chegar ao custodiante, imediatamente, sem necessidade de transação. - Se você estiver gerenciando session keys diretamente no nível da smart-account (fora do produto CLI), [remover uma session key](https://www.alchemy.com/docs/wallets/smart-contracts/modular-account-v2/session-keys/removing-session-keys) significa desinstalar seu validator com uma user operation, que precisa ser enviada e minerada como qualquer outra ação onchain. ## Como garantir que revogar o acesso de um agente seja instantâneo Digamos que você perceba o agente fazendo algo errado e aciona a revogação. Se seu kill switch funciona alterando uma regra armazenada onchain, essa alteração ainda precisa ser enviada como uma transação e minerada antes de valer, então há uma janela, um block time, talvez mais, em que o agente ainda pode agir mesmo depois que você já disse ao sistema para pará-lo. A questão é como projetar a revogação de modo que não tenha essa lacuna. Isso se resume a onde a aplicação das regras reside. Se a única coisa entre um agente e a chain é uma regra armazenada dentro de um smart contract, desativar essa regra significa enviar uma transação para alterar o estado do contrato, e essa transação precisa ser minerada antes que a mudança valha. Se a aplicação das regras acontece, em vez disso, em uma camada que verifica a solicitação antes mesmo dela ser assinada ou transmitida, revogar é apenas deletar ou invalidar essa verificação, o que tem efeito no momento em que você faz isso. O Agent Wallets da Alchemy, o motor de políticas da Turnkey e o sistema de pacts da Cobo usam esse último padrão. - A Turnkey deleta o usuário agente não-root, e toda solicitação subsequente com essa credencial falha no enclave. - A Cobo revoga um pact e sua API key no lado servidor e afirma claramente que a próxima chamada de API do agente é rejeitada. - A Alchemy revoga a sessão na camada de verificação do backend, e a próxima tentativa de assinatura é rejeitada antes de sair da infraestrutura da Alchemy, antes mesmo de chegar ao custodiante. A Crossmint adota uma abordagem diferente: suas permissões residem dentro do próprio smart contract wallet, então remover o signer de um agente é uma mudança no estado onchain desse contrato. Embora a regra ser aplicada pela própria chain, em vez de por um servidor, seja [mais difícil de contornar por um agente comprometido](https://www.crossmint.com/learn/agent-wallets-compared), a contrapartida é a velocidade: alterar uma permissão onchain significa enviar uma transação, então a revogação herda o tempo de settlement que a chain tiver, algo que a abordagem de verificação no backend evita completamente. ## Agent Wallets vs. session keys das Wallet API Tanto o Agent Wallets quanto o uso de session keys via as Wallet APIs mantêm a private key longe do agente. O que muda é quanto controle você precisa, quem de fato está delegando ao agente, e como funciona a revogação. Sessões CLI são cortadas na camada de verificação sem transação. Desinstalar uma session key da Wallet API espera por uma user operation minerada. Você está configurando um coding agent ou um script interno e quer que ele assine em minutos, sem necessidade de integração de SDK.

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

Você está construindo um produto onde seus próprios usuários finais delegam a assinatura a um agente na própria smart account deles.

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

Uma lista de capacidades sim/não, essa sessão pode enviar, fazer swap, bridge, ou fazer contract calls, é delimitação suficiente para o que o agente faz.

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

Você precisa de um teto de gasto real, como um allowance fixo em native token ou em um ERC-20, aplicado pela própria permissão.

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

O dashboard da Alchemy é um bom lugar para criar a carteira e aprovar sessões manualmente.

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

Você precisa de allowlists no nível de contrato ou função como o real limite de aplicação, não apenas uma flag de capacidade.

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

O CLI já cuida do que o agente precisa fazer: enviar, agrupar chamadas (batching), e ter seu gas patrocinado em EVM e Solana, além de swap e bridge na EVM mainnet.

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

Você precisa conceder session keys a partir do seu próprio app. Nenhum dos dois caminhos assina hoje uma transação EVM bruta arbitrária para um SDK de terceiros. Entre em contato conosco se esse for o seu caso de uso.

', tooltip: "", icon: "", }, id: 3, }, ], }} /> ## Como a Alchemy se compara com Turnkey, Crossmint e Cobo Alchemy Agent Wallets

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

Parceiro de embedded wallet (Privy por padrão) para sessões CLI, ou qualquer signer que você escolher via Wallet APIs

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

Camada de verificação de sessão no backend para sessões CLI; permissões de session-key onchain na smart account para integrações personalizadas de Wallet APIs

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

Sim para sessões CLI, via dashboard ou wallet disconnect. Session keys de Wallet API: não, desinstalar o validator é uma user operation minerada

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

Turnkey

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

Enclave seguro AWS Nitro (TEE)

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

Motor de políticas rodando dentro do mesmo enclave, avaliado antes de cada assinatura

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

Sim, deletar o usuário agente não-root ou ativar uma política DENY

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

Cobo Agentic Wallet

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

MPC entre partes independentes, sem chave única

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

Motor de políticas em três estágios no lado servidor (permission, rule, counter), avaliado a cada solicitação

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

Sim, congelar ou revogar um pact; a API key é invalidada no lado servidor

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

Crossmint

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

Smart contract wallet de chave dupla: owner key mais uma agent key selada em um TEE

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

Onchain, dentro do próprio smart contract (limites por transação, allowlists, janelas de tempo verificadas na execução)

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

Por design, não. Remover um signer altera o conjunto de signers onchain do contrato da carteira, então isso é processado como qualquer outra operação onchain, em vez de uma verificação síncrona no backend

", tooltip: "", icon: "", }, id: 3, }, ], }} /> Em resumo: sessões CLI da Alchemy, Turnkey e Cobo aplicam as regras fora da chain e revogam instantaneamente. Crossmint e session keys de Wallet API aplicam as regras onchain, então a revogação herda o tempo de settlement. ## Erros comuns a evitar - **Não trate o patrocínio de gas como um limite de gastos.** Uma política de patrocínio decide quem paga as taxas, não quanto o agente pode movimentar. Use permissões de session-key ou allowances de contrato para tetos de gastos reais. - **Não confie em mudanças de permissão onchain como seu kill switch.** Se revogar o acesso significa desinstalar um validator ou alterar um signer onchain, você fica limitado pelo block time em um incidente. Coloque uma verificação de backend ou enclave na frente da assinatura, e mantenha a camada onchain como uma segunda linha de defesa. - **Não conceda permissões `root` para desbloquear algo mais rápido.** A própria documentação da Alchemy chama isso de uma permissão muito perigosa de conceder, e isso anula o propósito de delimitar uma sessão. Delimite ao contrato, função ou token específico que o agente realmente precisa. - **Não pule a verificação antes de uma ação irreversível.** Uma sessão que era válida há uma hora pode já estar revogada ou expirada. Verifique com `wallet status --verify` (ou o equivalente para sua integração) imediatamente antes de qualquer coisa que não possa ser desfeita. - **Não assuma que "carteira de agente" significa uma única arquitetura.** Turnkey, Crossmint, Cobo e Alchemy colocam custódia, aplicação de políticas e revogação em lugares diferentes. Confirme qual camada de fato aplica a regra da qual você depende antes de colocar isso em produção. ## Perguntas frequentes ### O que são carteiras de agente e como elas diferem de carteiras crypto comuns? Uma carteira de agente é construída para que um software opere continuamente, sem que um humano aprove cada transação. Uma carteira comum assume que uma pessoa revisa e assina cada ação. A verdadeira diferença é o modelo de permissões em torno da chave: capacidades delimitadas, uma sessão com prazo definido, e um caminho rápido de revogação, não o saldo ou endereço da carteira. ### Quais são os prós e contras do Alchemy Agent Wallets para agentes de IA autônomos? Prós: a private key nunca chega ao agente, as sessões são delimitadas e têm prazo definido, a revogação é imediata, e uma única integração cobre EVM e Solana com patrocínio de gas embutido. Swaps e bridges hoje são exclusivos da EVM mainnet. Limites: sem assinatura EVM bruta através da sessão, e políticas de patrocínio não são limites de gastos. ### Quais provedores permitem que agentes de IA usem sessões de carteira aprovadas sem expor private keys? [Alchemy](https://www.alchemy.com/docs/agent-wallets) (Agent Wallets, apoiado por um custodiante de embedded wallet), [Turnkey](https://docs.turnkey.com/features/policies/delegated-access/agentic-wallets) (custódia em enclave seguro com um motor de políticas baseado em enclave), [Crossmint](https://docs.crossmint.com/wallets/concepts/signers) (smart contract wallets de chave dupla com uma agent key selada em TEE), e [Cobo](https://www.cobo.com/products/agentic-wallet/manual/developer/technical-architecture) (custódia MPC com um motor de políticas no lado servidor) fazem isso, com diferentes contrapartidas em relação a onde a aplicação das regras reside. ### Qual infraestrutura devo usar para provisionamento e controles de permissão de carteiras de agente de IA? Para um coding agent ou automação interna, use o [Agent Wallets no Alchemy CLI](https://www.alchemy.com/docs/agent-wallets): crie uma carteira no dashboard, conecte uma sessão delimitada, e verifique-a antes de ações que alteram estado. Para um produto onde seus usuários delegam a um agente, vá direto para as [session keys das Wallet APIs](https://www.alchemy.com/docs/wallets/reference/wallet-apis-session-keys/api), delimitadas por contrato, função e limite de gastos. ### Como aprovo, verifico e revogo a sessão de carteira de um agente de IA? Aprove uma vez, por um humano, no dashboard da Alchemy ou assinando a autorização EIP-712 da session key. Verifique antes de toda ação irreversível com `alchemy wallet status --verify`. Para uma sessão CLI, revogue pelo dashboard ou com `alchemy wallet disconnect`; isso tem efeito imediato na camada de verificação, antes de qualquer solicitação de assinatura chegar ao custodiante. Para uma session key da Wallet API, [removê-la](https://www.alchemy.com/docs/wallets/smart-contracts/modular-account-v2/session-keys/removing-session-keys) espera por uma user operation minerada. ### Como dou a um agente de IA permissões de assinatura delegadas para a smart wallet de um usuário? Delegue a smart account do usuário onchain sob o [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702), então chame `wallet_createSession` ou `client.grantPermissions()` com uma session key e um [array de permissões](https://www.alchemy.com/docs/wallets/smart-contracts/modular-account-v2/session-keys/session-key-permissions) (limites de gasto em native ou ERC-20, limites de gas, allowlists de contrato ou função, e uma expiração). O usuário assina uma autorização EIP-712, e a partir daí o agente assina cada ação com a session key, nunca com a chave do owner. ### Como dou a um agente de IA uma sessão de carteira temporária sem expor private keys? Rode `alchemy wallet connect --mode session` a partir do [Alchemy CLI](https://www.alchemy.com/docs/agent-wallets). Isso gera um keypair local que nunca sai da sua máquina, abre o dashboard para você aprovar as capacidades e a expiração da sessão, e a partir daí o agente assina através dessa sessão enquanto a private key real da carteira permanece com o custodiante. ### Como provisiono uma carteira para um agente de IA que executa transações DeFi de forma autônoma? Crie a carteira no dashboard da Alchemy, conecte uma sessão CLI delimitada às operações de que ela precisa (send, swap, bridge, contract calls), e defina uma expiração. Para tetos de gasto e allowlists no nível de contrato, em vez de apenas flags de capacidade, provisione a sessão através das [session keys das Wallet APIs](https://www.alchemy.com/docs/wallets/reference/wallet-apis-session-keys/api) em vez do CLI. ### Qual é a arquitetura recomendada para revogar instantaneamente as permissões de transação onchain de um agente de IA sem esperar pelo settlement onchain? Coloque a aplicação das regras em uma camada de backend ou enclave que verifique cada solicitação antes de ela ser assinada ou transmitida, separada de qualquer estado de permissão armazenado onchain. Revogar nessa camada significa deletar ou invalidar essa verificação, o que tem efeito imediato. Se seu único caminho de revogação é alterar um validator ou signer onchain, seu kill switch fica limitado pelo block time.