OpenClaw 2.0 e Sigil: Construindo Autorização Verificável para Agentes de IA Autônomos

Após um período de inatividade, o "Lagosta" OpenClaw lançou a versão 2.0 em 30 de agosto.

Segundo a versão oficial, esta é a maior atualização na história do OpenClaw, com mais de 16 mil Pull Requests acumulados, abrangendo quase toda a pilha do produto, incluindo instalação, mensagens, memória, Skills, modelos, Automations, navegador, aplicativos nativos, Plugins e mecanismos de segurança.

Mas, em comparação com essa extensa lista de funcionalidades, o que realmente merece atenção é a trajetória de evolução cada vez mais clara por trás do OpenClaw 2.0: os Agentes estão se tornando cada vez mais capazes de realmente “fazer coisas”.

Ao mesmo tempo, ele também colocou a indústria diante de um dilema de confiança inevitável: à medida que os Agentes se tornam cada vez mais capazes de decidir autonomamente "como fazer", como podemos garantir que cada operação crítica deles não ultrapasse os limites da autorização real do usuário?

No último ano, a mudança mais evidente nos AI Agentes não foi apenas os modelos subjacentes ficarem mais inteligentes.

À medida que infraestruturas como MCP, Skills, Plugins, controle de navegador e execução de código amadurecem, os Agentes começam a adquirir cada vez mais "mãos e pés" reais capazes de influenciar o mundo externo, como modificar informações, clicar em botões ou controlar diretamente o navegador por meio do computer use (leitura complementar: Agentic AI chegou ao ponto de virada? Quando a IA aprende a "agir por conta própria", como redefinir os limites de segurança do Web3?).

Mas o problema justamente ocorre aqui, pois, sob os paradigmas de interação atuais, é fácil cair em dois extremos.

Uma opção é conceder total autonomia, entregando diretamente a chave privada ou uma Session Key de longa duração com permissões suficientemente amplas ao Agente, para que ele decida e execute por conta própria.

A experiência automatizada desse modelo é certamente ideal, mas o risco também está extremamente concentrado: se ocorrer injeção de prompt, página web maliciosa ou poluição de dados, ou se o modelo apresentar desvio de compreensão, o erro pode se propagar por toda a cadeia de execução e acabar se tornando uma operação real (leitura complementar: Sign não é apenas assinatura: quando um AI Agent assina em seu nome, quem ainda tem o controle?).

Apesar de em cenários normais da internet isso poderia ser apenas enviar um e-mail errado ou excluir um arquivo incorretamente, na blockchain, uma transação errada muitas vezes é irreversível.

A outra opção é não delegar nenhum poder, exibindo uma janela de assinatura para confirmar cada operação e cada chamada secundária; a segurança aumenta, mas o significado da automação diminui significativamente.

Apesar de um agente ajudar o usuário a executar uma estratégia DeFi complexa, envolvendo vários passos, se cada um exigir que o usuário pegue o telefone para aprovar manualmente, o usuário na verdade apenas passa de “apertar botões sozinho” para se tornar uma “máquina humana de selagem”, aprovando continuamente para o agente.

Em outras palavras, a liberdade intermediária é tanto a fonte da eficiência do Agente quanto uma nova fonte de risco.

Do ponto de vista deste ângulo, o núcleo da questão não está em “se deve ou não delegar poder ao Agente”, mas sim em se a granularidade da autorização e os mecanismos de verificação possuem flexibilidade dinâmica, pois a gestão de permissões tradicional é binária (ou permitido ou negado), enquanto as tarefas enfrentadas pelo Agente são claramente muito mais complexas.

Mesmo sendo uma única transação, $10 e $100.000 são diferentes; interagir com um protocolo de uso contínuo é diferente de autorizar repentinamente um contrato desconhecido; realizar um Swap solicitado explicitamente pelo usuário não é o mesmo nível de risco que um Agent decidir sozinho transferir ativos para outra cadeia.

Portanto, quanto mais autônomo o agente for, mais os permissões não podem ser apenas um interruptor simples.

O que realmente é necessário é um mecanismo de segurança que permita que ele se mova livremente dentro dos limites e pare automaticamente ao cruzá-los.

Na verdade, o OpenClaw não ignorou esse problema.

Atualmente, ele oferece um mecanismo de permissões múltiplas, por exemplo, os plugins podem pausar e exigir confirmação do usuário antes da execução de operações específicas; quando envolver comandos do host, há ainda aprovações separadas de Exec e listas de permissões, entre outros.

Em comparação com entregar todos os instrumentos e permissões ao Agente de uma só vez, isso já representa um grande avanço. Mas quando o Agente realmente entrar em cenários de pagamento, negociação e gestão de ativos, surge uma questão mais específica: permitir que o Agente use uma determinada capacidade não é a mesma coisa que autorizar o Agente a realizar uma ação específica.

Assim como permitir que o Agente use o navegador não significa permitir que ele compre qualquer coisa em qualquer site; permitir que o Agente acesse o e-mail também não equivale a permitir que ele envie e-mails em seu nome para qualquer pessoa; da mesma forma, permitir que o Agente chame a carteira nunca deveria significar que ele pode enviar qualquer valor para qualquer endereço.

Portanto, o sistema de permissões da era Agent pode precisar distinguir duas questões diferentes. Uma é a permissão de capacidade: o Agent pode ou não usar navegador, terminal, e-mail ou carteira? A outra é uma autorização de ação mais específica: neste exato momento, a ação que ele está prestes a executar é realmente permitida pelo usuário?

Como permitir que o agente seja plenamente automatizado dentro de limites claros, enquanto retransmite a decisão ao usuário quando realmente ultrapassar esses limites?

Essa é também a razão pela qual o imToken está explorando o Sigil. Seu núcleo não é adicionar uma nova "janela de confirmação" tradicional ao Agent, mas sim tentar estabelecer uma barreira de segurança claramente delimitada entre o usuário e o Agent por meio de assinaturas verificáveis e controle de permissões granular.

Um dos princípios mais importantes é "What you see is what you sign": o que você vê, você assina.

Em resumo, os usuários podem conceder previamente ao Agente um determinado escopo de permissões para que ações de baixo risco e alinhadas à estratégia definida sejam executadas automaticamente; quando uma operação atingir limites de valor, protocolos desconhecidos ou outros limites críticos de permissão, a execução será pausada e a solicitação específica será devolvida ao usuário para confirmação.

Mais importante, essa confirmação não deve ser apenas uma vaga afirmação como “Agente está pronto para executar a transação, concorda?”. O que o usuário realmente precisa ver são os parâmetros-chave que realmente mudam nesta operação: quais ativos estão sendo usados, qual é o valor, quem é o parceiro de interação e, finalmente, o que exatamente será executado.

Uma confirmação só tem verdadeiro significado quando o conteúdo visto pelo usuário, o conteúdo autorizado pelo usuário e o conteúdo final executado pelo sistema estão alinhados.

Sigil, em torno disso, também tenta utilizar mecanismos como Passkey, biometria, assinatura única, validade curta e vinculação de parâmetros de solicitação, para que autorizações críticas possam ser compreendidas pelo usuário e verificadas pelo sistema.

Isso significa que uma autorização não é apenas “alguém clicou em confirmar”, mas também pode responder quem aprovou, o que foi aprovado e se a ação realmente executada foi exatamente aquela que foi vista naquele momento.

Do ponto de vista deste, o que o Sigil realmente quer resolver não é "como fazer com que o Agente faça menos coisas".

Por outro lado.

Ele tenta resolver como permitir que o Agente faça mais coisas sem retirar o controle final do usuário (leitura complementar: Do clique cego em “Sim” à assinatura consciente: Como o Sigil adiciona uma barreira de segurança aos Agentes de IA?).

Se você recuar um pouco mais a perspectiva, perceberá que isso também representa uma mudança de papel que as carteiras estão enfrentando.

Desde o nascimento do Ethereum, a carteira imToken presenciou e testemunhou duas gerações-chave: da era 1.0, que gerenciava chaves privadas únicas, até a era 2.0, que otimiza a experiência de interação por meio da abstração de conta (AA).

Com a adoção de Agentes autônomos como o OpenClaw 2.0, as carteiras certamente estão entrando na terceira geração de evolução, exigindo ajuda adicional para os usuários gerenciarem agentes que tomam decisões autônomas e operam continuamente.

É por isso que as capacidades acumuladas no passado pelo setor de carteiras — gerenciamento de chaves privadas, assinatura digital, autenticação de identidade e isolamento de permissões — podem ganhar novo significado na era dos Agentes.

Porque essas tecnologias, à primeira vista, estão resolvendo a questão de “como assinar com segurança uma transação na cadeia”, na verdade tratam de um problema mais geral: como provar que uma ação foi realmente autorizada por um determinado sujeito.

Hoje, essa ação pode ser a transferência de 1 ETH. No futuro, também pode ser enviar um e-mail, modificar um arquivo, usar uma identidade digital, comprar um serviço ou permitir que o Agente execute continuamente um conjunto de estratégias automatizadas durante a próxima semana.

Esses comportamentos nem sempre ocorrem inteiramente na blockchain, mas a relação subjacente é muito semelhante: o Agente está chamando, em nome do usuário, uma capacidade que pertence ao usuário.

Portanto, o significado do Sigil também não se limita necessariamente ao Crypto.

À medida que OpenClaw, Hermes e mais Agentes executados em dispositivos pessoais ou ambientes na nuvem se conectam a e-mail, mensagens instantâneas, calendários, arquivos, navegadores, terminais e ferramentas de pagamento, a questão de “como provar que esta ação foi realmente autorizada pelo usuário” se tornará cada vez mais comum.

Portanto, o Sigil também poderá se expandir no futuro para além das transações na cadeia, incluindo acesso a dados, uso de identidade, modificação de arquivos, publicação de conteúdo, compra de serviços e tarefas automatizadas.

Em geral, como uma exploração conjunta da imToken e da OpenClaw, o Sigil busca levar a experiência acumulada pela imToken nos últimos dez anos em auto-custódia, carteiras e assinaturas digitais para uma nova fase em que Agentes autônomos começam a entrar em ambientes de execução reais.

It does not replace Agent, nor does it replace the wallet.

Ele está entre os dois.