Carteiras de agentes: o modelo de sessão e permissão 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 uma 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?

Para provisionar carteiras de agente com controles de permissão, dê ao agente uma sessão delimitada em vez de uma chave privada. Para um agente de codificação ou uma automação interna, use Agent Wallets na Alchemy CLI: execute alchemy wallet connect, aprove as ações permitidas e uma expiração no dashboard, e revogue a sessão instantaneamente quando terminar. Para um produto no qual seus próprios usuários delegam a um agente, use as session keys das Wallet APIs, que acrescentam limites de gasto por token, allowlists de contratos, limites de gas e expirações sobre smart wallets EIP-7702. Nos dois casos, o agente nunca detém a chave do proprietário.

O que é uma carteira de agente, e em que ela difere de uma carteira de cripto comum?

Uma carteira comum pressupõe que uma pessoa revisa e assina cada transação com uma chave que só ela possui. Uma carteira de agente pressupõe o oposto: um agente de IA ou processo automatizado assina continuamente, sem que um humano clique 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 em torno da chave de assinatura, não no saldo ou endereço presentes na carteira: o que o agente tem permissão para fazer (capacidades delimitadas), por quanto tempo tem essa permissão (uma sessão com prazo definido), e com que rapidez você consegue cortar o acesso se algo der errado.

Agent Wallets trata cada um desses pontos diretamente:

• Capacidades delimitadas: uma sessão CLI inclui apenas os métodos de assinatura específicos que você concede, como envios, swaps, bridges ou chamadas de contrato. Restringir uma chave às funções de um único contrato é uma permissão de session key da Wallet API, não uma capacidade da CLI.
• Uma sessão com prazo definido: toda concessão carrega uma expiração, então o acesso caduca sozinho 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ê está usando o produto Agent Wallets CLI diretamente, em EVM e Solana, quanto se está construindo sobre a primitiva de session-key subjacente das Wallet APIs para seus próprios usuários. Desligamento instantâneo sem uma transação minerada é o caminho da CLI. Remover uma session key da Wallet API é uma desinstalação onchain.

Como as carteiras de agente mantêm a chave privada longe do agente?

Projetar transações seguras para agentes significa separar o que uma carteira comum reúne em uma única chave: custódia (quem detém a chave privada), autorização (o que é permitido) e controle (quem pode aprovar ou desligar o acesso).

• Turnkey mantém a custódia dentro de um enclave seguro de hardware e executa seu mecanismo 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.
• Crossmint e Cobo dividem uma carteira em uma chave de proprietário e uma chave de agente (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 definidos pelo proprietário.
• A Alchemy construiu a mesma separação na CLI: um assinante de sessão gerado localmente autentica o agente, enquanto um custodiante separado detém a chave privada real, de modo que o agente autentica e assina sem nunca tocar nela.

Veja como isso funciona na prática.

• Execute alchemy wallet connect, e a CLI gera localmente um par de chaves P-256 que nunca sai da sua máquina.
• Você aprova a sessão no dashboard da Alchemy, que vincula essa chave pública como um assinante limitado a capacidades e uma expiração específicas definidas por você.
• A chave privada real da carteira fica com um parceiro de embedded wallet, o 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, sua 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 manipula a chave privada.

Que infraestrutura você deve 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 agente de codificação ou a uma automação interna, Agent Wallets na Alchemy CLI é o caminho mais rápido, e a mesma abordagem que substitui colar uma chave privada diretamente no Cursor por algo que um agente pode realmente usar com segurança.

Crie uma carteira no dashboard, execute 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 envios e chamadas de contrato, além de swaps e bridges na EVM mainnet. Não é necessária integração de SDK, e o comando agent-prompt da CLI entrega ao agente um manifesto completo de comandos, flags e códigos de erro, de modo que ele não precisa ler a documentação para usar a superfície corretamente.

Se você está construindo um produto no qual seus próprios usuários delegam a assinatura a um agente, use as session keys das Wallet APIs. A smart account de um usuário recebe delegação onchain sob 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 única autorização EIP-712, e o agente assina cada ação depois disso com a session key, nunca com a chave do proprietário.

O que pode ser delegado, e qual o grau 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 fundo, 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 chamadas de carteira 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 são tratados para você.

A contrapartida é que uma sessão não pode assinar uma transação EVM bruta arbitrária como uma chave privada isolada faria, então, se seu agente precisar se conectar a um SDK ou protocolo de terceiros que espera entregar a ele uma transação EVM bruta para assinar, esse fluxo não funciona hoje através de uma sessão CLI. Entre em contato conosco se este for um caso de uso que você precisa.

No nível das Wallet APIs, as permissões de session-key são mais configuráveis. A lista de capacidades da CLI só responde sim ou não: essa sessão pode chamar sendCalls ou não? As permissões das Wallet API acrescentam limites em cima disso: não apenas se uma transferência é permitida, mas quanto pode se movimentar, em qual token, e através de qual contrato específico. Se um agente precisa de limites de gasto reais, como um teto de 100 USDC em uma janela de 24 horas em um token, e não apenas uma chave liga/desliga para quais ações estão habilitadas, use as Wallet APIs:

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 da CLI, isso é a etapa de aprovação no dashboard quando você conecta uma sessão. No fluxo das Wallet APIs, isso é o proprietário assinando os dados tipados EIP-712 que autorizam as permissões da session key.

A verificação deve ocorrer antes de cada ação que altera estado, não apenas na configuração inicial. Execute alchemy --json --no-interactive wallet status --verify antes que um agente faça qualquer coisa irreversível. Isso retorna o assinante ativo, a expiração da sessão e as capacidades habilitadas, de modo que o agente (ou seu código de orquestração) confirma que a sessão ainda está ativa antes de prosseguir.

A revogação tem dois mecanismos:

• 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ê está gerenciando session keys no nível da smart account diretamente (fora do produto CLI), remover uma session key significa desinstalar seu validador com uma user operation, que precisa ser enviada e minerada como qualquer outra ação onchain.

Como garantir que a revogação do acesso de um agente seja instantânea

Suponha que você perceba o agente fazendo algo errado e aciona a revogação. Se seu interruptor de emergência funciona alterando uma regra armazenada onchain, essa mudança ainda precisa ser enviada como transação e minerada antes de ser real, então há uma janela, o tempo de um bloco, talvez mais, na qual o agente ainda pode agir mesmo que você já tenha dito ao sistema para pará-lo. A questão é como projetar a revogação de modo que ela não tenha essa lacuna.

Isso se resume a onde a aplicação da regra vive. Se a única coisa entre um agente e a chain é uma regra armazenada dentro de um smart contract, desligar 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 seja real. Se a aplicação acontece em vez disso em uma camada que verifica a solicitação antes que ela seja assinada ou transmitida, revogar é apenas excluir ou invalidar essa verificação, o que tem efeito no momento em que você faz isso.

O Agent Wallets da Alchemy, o mecanismo de políticas do Turnkey e o sistema de pacts da Cobo usam todos esse último padrão.

• O Turnkey exclui o usuário agente não-root, e toda solicitação subsequente com aquela credencial falha no enclave.
• A Cobo revoga um pact e sua chave de API no 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 mesmo de sair da infraestrutura da Alchemy, antes de chegar ao custodiante.

A Crossmint adota uma abordagem diferente: suas permissões vivem dentro da própria smart contract wallet, de modo que remover o assinante de um agente é uma mudança no estado onchain daquele contrato. Embora a regra ser aplicada pela própria chain, e não por um servidor, seja mais difícil de contornar por um agente comprometido, a contrapartida é a velocidade: mudar uma permissão onchain significa enviar uma transação, então a revogação herda o tempo de assentamento da chain, algo que a abordagem de verificação no backend evita totalmente.

Agent Wallets vs. session keys das Wallet API

Tanto o Agent Wallets quanto o uso de session keys via Wallet APIs mantêm a chave privada longe do agente. O que difere é 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.

Como a Alchemy se compara ao Turnkey, Crossmint e Cobo

Em resumo: sessões CLI da Alchemy, o Turnkey e a Cobo aplicam regras off-chain e revogam instantaneamente. A Crossmint e as session keys da Wallet API aplicam regras onchain, então a revogação herda o tempo de assentamento.

Erros comuns a evitar

• Não trate o patrocínio de gas como um limite de gasto. 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 limites de contrato para tetos de gasto reais.
• Não dependa de mudanças de permissão onchain como seu interruptor de emergência. Se revogar o acesso significa desinstalar um validador ou mudar um assinante onchain, você fica limitado pelo tempo de bloco em um incidente. Coloque, em vez disso, uma verificação no backend ou enclave antes 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 a chama 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 de 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 uma hora atrás 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 presuma 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ê está dependendo antes de colocar isso em produção.

Perguntas frequentes

O que são carteiras de agente e como elas diferem de carteiras de cripto comuns?

Uma carteira de agente é construída para que um software opere continuamente, sem que um humano aprove cada transação. Uma carteira comum pressupõe que uma pessoa revisa e assina cada ação. A diferença real está no 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 das Agent Wallets da Alchemy para agentes de IA autônomos?

Prós: a chave privada nunca chega ao agente, as sessões são delimitadas e com 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: nenhuma assinatura de transação EVM bruta através da sessão, e políticas de patrocínio não são limites de gasto.

Quais provedores permitem que agentes de IA usem sessões de carteira aprovadas sem expor chaves privadas?

Alchemy (Agent Wallets, apoiada por um custodiante de embedded wallet), Turnkey (custódia em enclave seguro com um mecanismo de políticas baseado em enclave), Crossmint (smart contract wallets de chave dupla com uma chave de agente lacrada em TEE), e Cobo (custódia MPC com um mecanismo de políticas no lado do servidor) fazem isso, com contrapartidas diferentes em relação a onde a aplicação das regras vive.

Que infraestrutura devo usar para provisionamento e controles de permissão de carteiras de agentes de IA?

Para um agente de codificação ou automação interna, use Agent Wallets na Alchemy CLI: crie uma carteira no dashboard, conecte uma sessão delimitada, e verifique-a antes de ações que alterem estado. Para um produto no qual seus usuários delegam a um agente, vá direto para as session keys das Wallet APIs, delimitadas por contrato, função e limite de gasto.

Como eu 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 cada 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 que qualquer solicitação de assinatura chegue ao custodiante. Para uma session key da Wallet API, removê-la espera por uma user operation minerada.

Como eu 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 EIP-7702, depois chame wallet_createSession ou client.grantPermissions() com uma session key e um array de permissões (limites de gasto em token nativo ou ERC-20, limites de gas, allowlists de contrato ou função, e uma expiração). O usuário assina uma única autorização EIP-712, e o agente assina cada ação depois disso com a session key, nunca com a chave do proprietário.

Como eu dou a um agente de IA uma sessão de carteira temporária sem expor chaves privadas?

Execute alchemy wallet connect --mode session a partir da Alchemy CLI. Isso gera um par de chaves 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 chave privada real da carteira permanece com o custodiante.

Como eu 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 ele precisa (envio, swap, bridge, chamadas de contrato), 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 em vez da CLI.

Qual é a arquitetura recomendada para revogar instantaneamente as permissões de transação onchain de um agente de IA sem esperar pelo assentamento onchain?

Coloque a aplicação de regras em uma camada de backend ou enclave que verifica cada solicitação antes de ela ser assinada ou transmitida, separada de qualquer estado de permissão armazenado onchain. Revogar ali significa excluir ou invalidar essa verificação, o que tem efeito imediato. Se seu único caminho de revogação é mudar um validador ou assinante onchain, seu interruptor de emergência fica limitado pelo tempo de bloco.