Chaves de sessão e permissões: delegação em contratos…

As chaves de sessão e permissões de agente são uma forma de uma conta inteligente delegar um mandato estritamente definido a um aplicativo ou agente de IA, aplicado on-chain pela lógica de validação da carteira. O objetivo é a execução autônoma on-chain sem transformar um agente em um signatário de plenos poderes, utilizando limites como janelas de tempo, listas de permissão e um limite de gastos que o contrato pode se recusar a exceder.

Principais Conclusões

• Uma chave de sessão é uma credencial de assinatura temporária com autoridade limitada, projetada para que uma aprovação possa cobrir um conjunto restrito de ações dentro de um escopo definido.
• A atualização de segurança vem de contas inteligentes aplicando políticas on-chain, não do fato de a chave ser "temporária".
• ERC-4337 torna a execução delegada operacional através de UserOperations, bundlers e um contrato EntryPoint canônico, com paymasters opcionais que podem patrocinar gas.
• ERC-8196 propõe o próximo passo para o design de carteiras de agente: prova criptográfica de conformidade com a política mais um audit encadeado por hash para a atividade da sessão.

Noções básicas sobre chaves de sessão e permissões de agente

A delegação começa com uma divisão simples: uma credencial mantém o controle total, enquanto outra credencial recebe uma tarefa específica. Em uma configuração de conta inteligente, a chave mestra do proprietário permanece como "root", enquanto uma chave de sessão é criada ou autorizada para uma janela e escopo específicos. Esse escopo é o que as pessoas querem dizer com permissões de agente ou acesso de agente com escopo. O aplicativo ou agente pode assinar, mas apenas dentro da caixa que o contrato da carteira reconhece.

Essa estrutura é importante para a execução autônoma onchain porque os agentes já sabem como assinar transações. O modo de falha é dar a eles uma chave de acesso total e esperar que o host, o prompt, a árvore de dependências e a interface do usuário nunca o traiam. As chaves de sessão são a postura oposta.

Elas são um orçamento de risco que você pode precificar: tempo + alvos + limites de valor, com o contrato da carteira atuando como o segurança.

Um modelo mental útil é “distintivo, não chave mestra.” O distintivo pode abrir algumas portas, durante algumas horas, para uma tarefa específica. Se o distintivo vazar, o raio de impacto deve ser limitado por design. É por isso que a frase chaves de sessão em cripto frequentemente aparece ao lado de contas inteligentes e carteiras embutidas. O objetivo é ter menos aprovações repetidas sem conceder controle permanente e ilimitado a um aplicativo.

Dois detalhes são fáceis de perder. Primeiro, "temporário" não é a propriedade de segurança. O escopo é. Segundo, chaves de sessão não são padronizadas em todos os lugares hoje. As implementações ainda são de carteira para carteira, o que significa que a semântica exata de revogação, listas de permissão e casos extremos varia entre os provedores.

Como contas inteligentes impõem permissões

ERC-4337 muda onde a autorização acontece. Em vez de um EOA transmitindo uma transação normal para o públicomempoolUma conta inteligente espera uma UserOperation que possa validar de acordo com suas próprias regras antes que qualquer coisa seja executada. O agente assina a UserOperation com uma chave autorizada, um bundler agrega UserOperations, e o bundler chama um contrato EntryPoint canônico que as processa. O sistema de permissões reside na camada de validação da conta inteligente, não na interface do usuário.

Essa arquitetura é a razão pela qual “confie no aplicativo” pode ser substituído por “o contrato recusa.” A RebelFi captura a mudança com duas linhas que valem a pena manter verbatim: “confie no código do aplicativo agente para não gastar demais” versus “o contrato impõe a política de gastos independentemente do que o aplicativo faz.” A segunda frase é o mecanismo real. Se a política diz não, a operação não é validada, e o EntryPoint não a executa.

Os paymasters são a outra peça que faz os agentes se sentirem sempre ativos. No ERC-4337, um paymaster pode patrocinar o gás, o que significa que um agente que possui USDC e nãoETHainda pode transacionar se um paymaster estiver configurado para aceitar USDC em troca de cobrir os custos de gás em ETH. Isso não é um truque cosmético de UX.

Remove a exigência operacional de manter um saldo separado de ETH sempre abastecido apenas para que o agente possa continuar funcionando.

Isto também é ondeeip 7702entra na conversa. A ZeroDev posiciona sua pilha como suporte tanto para ERC-4337 quanto para EIP 7702, com chaves de sessão como um primitivo de UX de primeira classe para automação. O fio condutor é o mesmo: mover a delegação para uma carteira que possa impor políticas, em vez de deixá-la como uma promessa off-chain.

Escopos e limites de permissão comuns

Uma política de sessão é tão boa quanto os controles que expõe e impõe. O exemplo concreto da RebelFi é um modelo claro de como as permissões de agentes devem parecer quando alguém realmente tem capital em risco: um gasto máximo por transação (exemplo: $50), uma lista de destinatários aprovados, uma janela de expiração (exemplo: 24 horas) e um orçamento total de sessão (exemplo: $500) antes da reautorização.

Esse último ponto é importante porque “muitos pequenos gastos” podem se acumular mesmo quando cada transferência individual é limitada.

Esses botões correspondem a como contas inteligentes validam a intenção:

1. Limites de tempo. Uma janela validAfter e validUntil torna a chave inútil fora da sessão, o que reduz o valor de roubá-la. 2. Restrições de alvo. Listas de permissões de destinatários ou contratos permitidos impedem que a chave seja reutilizada para transferências arbitrárias. 3. Restrições de valor. Um limite de gasto por transação limita danos de um único golpe, enquanto um orçamento total limita danos contínuos.

A revogação é a rede de segurança operacional. Na arquitetura do RebelFi, a chave raiz de assinatura mantém o controle total da conta e pode revogar chaves de sessão a qualquer momento. Essa é a diferença entre delegação e rendição. A chave do proprietário não está "compartilhando identidade." Ela está emitindo um mandato que pode ser cancelado.

Mais uma nuance: as chaves de sessão são frequentemente descritas como "temporárias".chaves privadas," mas essa descrição está incompleta. A chave é apenas um signatário. A segurança vem da conta inteligente se recusando a validar operações que violam a política. Sem essa aplicação em cadeia, "temporário" ainda pode ser catastrófico dentro da janela.

Fluxos de trabalho de agentes habilitados por delegação

A delegação não se trata apenas de conveniência. Ela muda quais fluxos de trabalho são viáveis sem transformar cada etapa em uma nova cerimônia de assinatura. O caso de uso óbvio são os pagamentos a agentes. Uma carteira de agente pode ser autorizada a pagar um conjunto de prestadores de serviços pré-aprovados, enquanto é bloqueada de transferir fundos para endereços arbitrários.

O agrupamento atômico é o desbloqueio de segunda ordem. Contas inteligentes ERC-4337 podem executar transações em lote atômicas, portanto sequências como retirar-de-rendimento+ pagar pelo serviço ter sucesso ou falhar juntos. Isso é importante porque impede um estado incompleto. Se a parte do pagamento falhar, a parte do saque reverte, e os fundos não acabam estrangulados em um estado intermediário não intencional.

O agrupamento também aparece como uma alavanca de custo mensurável. A RebelFi estima doisERC-20transfere separadamente a aproximadamente 2 × 65.000 gas em comparação com cerca de 1 × 110.000 gas em lote, o que representa uma economia de cerca de 15%. Em uma tela, essa é a diferença entre um fluxo de trabalho de agente que é economicamente viável em escala e um que consome taxas.

O patrocínio de gas une o ciclo para agentes “sem ETH”. Com um paymaster, o agente pode operar enquanto mantém apenas USDC, assumindo que o paymaster aceita USDC para gas. Essa é a resposta prática para o equívoco de que os agentes devem manter ETH para funcionar.

O posicionamento da ZeroDev é consistente com essa visão de fluxo de trabalho. Sua documentação enquadra chaves de sessão como parte de um conjunto de ferramentas de UX de conta inteligente mais amplo que inclui agrupamento e abstração de gas, e afirma alimentar mais de 6 milhões de contas inteligentes em mais de 50 redes para mais de 200 equipes.

Essa afirmação de escala não é uma garantia de segurança, mas é um sinal de que esses padrões já estão sendo usados em pilhas de produção.

Execução vinculada a políticas e trilhas de auditoria

ERC-8196 é a declaração mais clara de para onde as permissões dos agentes estão indo: carteiras que executam ações apenas quando acompanhadas de prova criptográfica de que a ação está em conformidade com uma política definida pelo proprietário. Isso não é apenas “definir limites em uma interface”. É “provar conformidade no momento da execução”, com a carteira atuando como o ponto de aplicação.

A proposta especifica campos de política necessários que se assemelham a uma versão formalizada das políticas de sessão atuais: ações permitidas, contratos permitidos e bloqueados, valor máximo por transação, uma janela de validade e um limite mínimo de pontuação de verificação.

Também introduz um conceito de trilha de auditoria imutável e encadeada por hash para a atividade da sessão, onde cada entrada de auditoria inclui um hash anterior para integridade. O ERC-8196 permite que implementações armazenem entradas fora da cadeia e publiquem periodicamente raízes na cadeia, o que é uma troca pragmática entre custo e verificabilidade.

Este é o jogo final implícito pela tese: chaves de sessão só se tornam significativamente seguras quando a carteira pode aplicar políticas na cadeia, e a próxima barreira é a conformidade verificável mais auditabilidade. Se um host de agente for comprometido, “os logs dizem que se comportou” não é bom o suficiente.

Uma trilha à prova de adulteração mais execução vinculada a políticas está mais próxima da postura que plataformas regulamentadas e operadores sérios desejam.

Duas advertências pertencem à mesma respiração. O ERC-8196 está explicitamente em revisão por pares, então a interface e os requisitos podem mudar. Separadamente, mesmo um padrão perfeito não remove o risco de implementação. A lógica de validação da carteira, verificações de verificação e encanamento de auditoria ainda precisam ser construídos corretamente.

Riscos, advertências e melhores práticas

A cara concepção errônea é pensar que uma chave de sessão é segura porque é temporária. Limites de tempo ajudam, mas um escopo totalmente aberto dentro da janela ainda é um escopo totalmente aberto. Uma chave de 24 horas que pode transferir para qualquerendereçoé um botão de drenagem de 24 horas.

A segunda concepção errônea é a portabilidade. Chaves de sessão não são padronizadas em todos os lugares hoje, e as implementações variam de carteira para carteira. Isso significa que as "permissões de agente" podem parecer semelhantes entre produtos, enquanto se comportam de maneira diferente nas bordas, incluindo comportamento de revogação e quão rigorosamente as listas de permissão são aplicadas.

A terceira concepção errônea é operacional: agentes precisam de ETH para operar. Paymasters ERC-4337 podem patrocinar gás, permitindo que um agente que possui USDC e nenhum ETH transacione se o paymaster estiver configurado para aceitar USDC.

A melhor prática é escrever políticas como limites de risco, não como alternâncias de recursos:

1. Comece com um pequeno limite de gastos por transação. Esta é a maneira mais rápida de limitar danos de um único golpe. 2. Use uma lista de permissão rígida de destinatários ou contratos. Se o agente não puder nomear o alvo na política, ele não deve ser capaz de tocá-lo. 3. Mantenha a janela de validade curta. O vencimento reduz o valor de uma chave vazada. 4. Adicione um orçamento total de sessão. Isso impede que "muitos pequenos golpes" esvaziem a conta.

O agrupamento também é uma ferramenta de segurança, não apenas um truque de gás. Lotes atômicos reduzem a chance de acabar com um estado meio-completo quando um fluxo de trabalho de agente abrange várias etapas.

A revogação precisa ser tratada como um controle de primeira classe. As fontes são explícitas que a chave raiz do proprietário pode revogar chaves de sessão. Operacionalmente, isso implica projetar para interruptores de desligamento rápidos e tratar nonces e vencimentos como controles centrais para reduzir problemas de repetição e temporização.

É aqui que a história mais ampla da execução autônoma se estabelece: os designs vencedores movem a delegação para fora das promessas do aplicativo e para limites impostos por contrato, e então adicionam conformidade verificável e um histórico de auditoria por cima.

A Opinião

Eu vi equipes tratarem "chave temporária" como um argumento de segurança e depois silenciosamente lançarem uma sessão que estava totalmente aberta em alvos ou orçamento. A chave expirou, claro. Os fundos ainda estavam desaparecidos dentro da janela. A única versão disso que se sustenta é quando a camada de validação de conta inteligente é a que diz não, não um host de agente ou uma caixa de seleção na interface.

A postura limpa é pensar em uma chave de sessão como um mandato precificado: relógio curto, lista de permissões restrita, pequeno limite de gasto por transação e um orçamento total rígido. Se o sistema também suportar agrupamento atômico e pagadores, o agente pode parecer sempre ativo sem ser sempre perigoso.

Essa é a direção em que a execução autônoma em blockchain está convergindo, e o ERC-8196 é a primeira tentativa séria de tornar a conformidade e a auditabilidade parte do trabalho da carteira, não uma reflexão tardia.

Fontes

• RebelFi
• Propostas de Melhoria do Ethereum
• CryptoAdventure
• ZeroDev Docs