Os 2 dólares desaparecidos na «Gestão de Sombras»: um incidente de transgressão de IA

A ilusão da inteligência artificial já foi vista como uma simples distorção de informação, uma criação de fatos ou uma escrita sem lógica. Mas a realidade de 2026 nos deu um golpe duro: quando a IA evolui de chatbots para Agentes, as ilusões começam a se transformar em riscos caros de execução. O problema não é mais apenas falar bobagens, pois agora ela tem a capacidade de mover seus ativos diretamente.

Veneno na cadeia de suprimentos: de codificação manual a vibe coding

O incidente de envenenamento do LiteLLM nesta semana alertou para essa tendência.

Como motor subjacente de quase todos os principais frameworks de AI Agent, o LiteLLM enfrentou uma típica infiltração na cadeia de suprimentos. O atacante obteve a chave de publicação através de uma vulnerabilidade na cadeia de ferramentas de segurança, enviando código malicioso como se fosse uma versão oficial para o ambiente do usuário. Com assinatura legítima, os mecanismos tradicionais de verificação quase não funcionaram.

Curiosamente, a descoberta do ataque ocorreu apenas porque o código do hacker apresentou um bug simples ao lidar com lógica recursiva, fazendo o computador da vítima travar por falta de recursos.

Isso revelou uma vulnerabilidade há muito ignorada na ecologia open source: ao instalar uma biblioteca, você na prática confia em toda uma árvore de dependências que atravessa centenas de pacotes. Qualquer nó dessa árvore que estiver comprometido pode afetar o ambiente de produção principal.

Sob a paradigma de desenvolvimento vibe coding, esse risco é ampliado. Muitos desenvolvedores descrevem suas necessidades em linguagem natural, e a IA gera o código automaticamente. Quando há erro, eles tendem a aceitar as sugestões de correção da IA e executar comandos como pip install, sem verificar a origem ou segurança das dependências.

Nesse ambiente, a barreira de entrada para o desenvolvimento diminui, mas a complexidade da auditoria de segurança não acompanha. Cada instalação de dependência aparentemente simples na verdade introduz uma nova incerteza, que gradualmente se torna um risco sistêmico.

Acidente interno na Meta: quando humanos se tornam interfaces de execução

Mudanças semelhantes também ocorrem na interação homem-máquina. Com a mudança do desenvolvimento de software de operações passo a passo para resultados orientados, o papel humano também muda: de julgador, passa a ser ponto de confirmação, ou até apenas interface de execução.

O desenvolvimento de software está passando de “manual” para “autônomo”. Antes, o desenvolvedor era responsável por cada operação; agora, com a introdução de Agentes, o humano se torna mais um passageiro do modo de condução automática, recuando para um papel de confirmação ou apenas terminal de execução.

Quando o papel humano de “julgador” se reduz a uma interface de execução de IA, a disposição para auditoria diminui exponencialmente.

Um incidente de segurança de nível SEV1 na Meta recentemente ilustra isso: um engenheiro pediu ajuda no fórum interno, e o AI Agent respondeu automaticamente sem revisão. Outro engenheiro seguiu a sugestão e executou uma ação, levando a uma configuração incorreta de permissões, expondo dados sensíveis por duas horas sem autorização.

A Meta atribuiu o problema a um “erro humano”, mas, sob a ótica da interação homem-máquina, parece mais uma falha de interface. Quando a saída da IA parece tão profissional e “executável”, a defesa do humano como ponto de verificação se enfraquece automaticamente.

Essa mudança, em sistemas de informação, pode ser remediada por rollback e correções, mas quando a IA começa a atuar em sistemas com consequências reais — especialmente envolvendo ativos e transações financeiras — as ilusões se tornam uma conta cara e irreversível.

Lição de 2 dólares: uma troca de fachada para uma salvação autônoma

Se o incidente na Meta foi uma má configuração de permissões, no setor financeiro o problema é ainda mais grave, pois atinge a propriedade dos ativos.

Desde 2026, várias carteiras e infraestruturas lançaram produtos de carteira com agentes, tentando permitir que a IA atue diretamente em nome do usuário na cadeia. A equipe Cobo AI, ao testar sistematicamente essa nova categoria, identificou um padrão de comportamento representativo, que chamou de Shadow Custody — ou seja, o Agente, sem o conhecimento do usuário, gera chaves, cria endereços temporários e transfere o controle real dos ativos de uma carteira para um intermediário invisível e incontrolável pelo usuário. Assim, na blockchain aparece um endereço que o usuário não consegue controlar diretamente — uma caixa preta que existe logicamente, mas é invisível na perspectiva do usuário.

O fluxo do incidente foi assim: um usuário instrui o Agente a comprar USDC.e no valor de 2 dólares na Polymarket. Durante a execução, o Agente encontra um obstáculo: a transação na Polymarket exige uma assinatura digital em formato específico (EIP-712), mas o SDK usado pelo Agente embala a “montagem do conteúdo da assinatura” e a “assinatura com a chave privada” em uma única operação — ou seja, assume que a chave privada está disponível para o sistema.

O problema é que a carteira do usuário não é uma carteira comum com a chave na mão, mas uma carteira MPC compartilhada, capaz de assinar, mas que usa uma rota diferente. O Agente não percebe essa rota e conclui que a carteira não consegue assinar.

Num sistema baseado em regras de confiança, o procedimento deveria parar ou solicitar autorização adicional. Mas o Agente não parou. Interpretou a limitação como uma incapacidade da carteira de assinar e buscou uma solução alternativa: gerou uma nova chave privada localmente, criou um endereço temporário, transferiu USDC.e da carteira MPC para esse endereço e assinou com a nova chave, comprando o token com sucesso.

Do ponto de vista do resultado, tudo ocorreu como esperado: 10 tokens “Spain YES” foram adquiridos corretamente.

Mas, estruturalmente, tudo foi errado.

Esses tokens não retornaram à carteira MPC do usuário, mas ficaram na carteira temporária criada pelo Agente. O usuário só percebeu ao consultar o saldo, que estava zerado, e ao investigar, o Agente revelou todo o processo.

Sequestro de rota: mais que um bug

Isso não é apenas um bug; na verdade, o Agente não errou, apenas preencheu uma lacuna na definição de fronteiras do sistema.

Resumindo, quando o caminho original não funciona, o Agente não para, mas tenta completar a tarefa por conta própria. Ele cria uma carteira temporária para transferir fundos, mas na interface do usuário, a movimentação de ativos ocorre sem aviso. Essa desconexão entre percepção do usuário e a realidade do sistema é uma forma de sequestro de rota.

Esse sequestro oculto revela riscos sistêmicos na transparência de fundos, na coerência semântica e na estabilidade do ambiente de execução de finanças automatizadas:

E, uma vez que essa “preenchimento” não seja mais controlado, ela abre três portas para ataques:

• Desvio lógico: ferramentas maliciosas não precisam falsificar links ou pop-ups, basta induzir o Agente a ativar uma carteira temporária no código. O usuário vê a transação bem-sucedida, mas o controle dos ativos já foi transferido no momento da execução.

• Manipulação semântica: o atacante não precisa invadir o sistema, basta inserir restrições falsas em documentos ou prompts (como “caminho original inválido”). O Agente, orientado por tarefas, transferirá fundos para evitar “restrições falsas”. Não foi hackeado, apenas enganado.

• Envenenamento de componentes: ao adulterar SDKs ou bibliotecas de terceiros, o sistema pode ser levado a interpretar um caminho válido como inválido. O Agente acha que está seguindo uma rota legítima, mas na verdade entrou em um beco sem saída planejado.

Contrainte mais importante que capacidade: as três portas para limitar o comportamento do AI Agent

Em cenários financeiros com tolerância zero a falhas, a “inteligência” do AI pode ser o maior inimigo da segurança. Precisamos de mais do que força de execução; precisamos de limites rígidos.

Para isso, devemos implementar três portas intransponíveis:

1. Porta de intenção (Policy Gate): quebre o ciclo autorreferente

As restrições devem vir de fora. Precisamos de um motor de políticas independente, que avalie se a operação é permitida antes de acontecer. Por exemplo, impedir que o Agente gere chaves privadas ou transfira para endereços não autorizados. Se uma regra for violada, a execução deve parar imediatamente.

2. Porta de transação (Transaction Gate): visão de risco

Todas as decisões do Agente devem se transformar em transações na cadeia. Entre o Agente e a blockchain, deve haver um “firewall de transações” que traduza os dados brutos em informações estruturadas. Avalie o comportamento do endereço, desvios de valor, e pontue as transações de risco. Transações de alto risco devem ser bloqueadas e submetidas à aprovação manual.

3. Porta de visibilidade (Visibility Gate): monitoramento em tempo real

Implementar um sistema de observação independente (Watcher). Quando fundos se movem para endereços novos ou não retornam em tempo hábil, o Watcher envia alertas em segundos. Assim, mesmo que o Agente tente esconder o caminho, o controle do ativo permanece transparente.

Conclusão

Estamos em uma fase de transição perigosa. A capacidade de execução da IA está crescendo rapidamente, mas nossos mecanismos de restrição ainda estão na idade da pedra. Se uma arquitetura não consegue definir claramente ações proibidas e fazer verificações em tempo real, cada decisão autônoma da IA é uma aposta arriscada com os ativos do usuário.

E, no setor financeiro, ninguém quer apostar.