Tem muito time de TI discutindo risco de IA como se o problema principal ainda fosse resposta errada, código quebrado ou alucinação boba. Só que o perigo que mais merece atenção agora é outro: a hora em que um agente recebe permissão para agir e passa a executar tarefas críticas no lugar do humano que antes barrava o absurdo.
Foi exatamente esse ângulo que ganhou força nesta semana em um texto forte do Stack Overflow Blog. Segundo o artigo, atacantes conseguiram assumir mais de 20 mil contas do Instagram conversando com o assistente de suporte da Meta e pedindo para anexar um email sob controle deles a contas que não eram deles. O ponto mais incômodo não é “a IA enlouqueceu”. É pior: ela teria seguido um fluxo permitido, enquanto a checagem humana que faria alguém estranhar aquela troca simplesmente não entrou em campo.
É isso que deixa a discussão mais séria para dev, infra, suporte e segurança. Em muitos times, parte da proteção real nunca virou regra formal de sistema. Ela mora na experiência de quem atende, revisa, aprova, segura deploy, estranha um reset suspeito ou percebe que uma ação “válida” não faz sentido naquele contexto. Quando um agente ocupa essa cadeira sem que a empresa reescreva esses freios em política, identidade, permissão e aprovação, o risco sobe rápido.
O problema novo não é só a IA errar. É ela obedecer no lugar errado
O texto do Stack Overflow usa um conceito clássico de segurança para explicar isso: confused deputy. Em português claro, é quando um sistema com privilégio real é convencido a agir em nome de alguém que não deveria ter aquele poder.
No mundo tradicional, isso já era ruim. No mundo dos agentes, fica pior por três motivos ao mesmo tempo:
- a interface em linguagem natural esconde melhor a intenção real do pedido;
- o agente tende a transformar frase plausível em ação prática com velocidade demais;
- muita empresa ainda não amarrou identidade, escopo e aprovação em cada ferramenta que o agente chama.
É por isso que o medo útil aqui não é “a IA vai virar Skynet”. O medo útil é bem mais chato e bem mais corporativo: reset de acesso feito para a pessoa errada, alteração em produção aprovada cedo demais, automação interna executando tarefa sensível sem contexto suficiente, agente lendo instrução maliciosa em conteúdo que deveria ser só dado.
Isso já encosta no trabalho real de quem vive TI
O caso da Meta chama atenção porque é grande, mas o padrão não depende de big tech. Ele aparece em escala menor em vários lugares onde a correria costuma ganhar da governança:
- bots de suporte com permissão para resetar conta, trocar email ou contornar etapa de validação;
- assistentes de código e CLI com acesso a arquivos, terminal, secrets e deploy;
- rotinas internas que recebem instrução por chat, ticket ou documento sem separar direito dado de comando;
- times que tratam “deu certo no ambiente” como sinônimo de “está seguro para operar”.
A camada brasileira dessa conversa também já está aparecendo. Em um texto recente do DevPleno sobre IA na infraestrutura, a tese central é bem direta: o problema não é usar IA na infra, e sim deixar a ferramenta virar autoridade operacional. Essa leitura conversa muito com o que o Stack Overflow apontou. O estrago normalmente não nasce porque o modelo respondeu mal. Ele nasce porque alguém entregou alcance demais para um sistema probabilístico e deixou o resto implícito.
Até quem vende agente já está apertando o freio
O contraponto mais interessante veio do próprio GitHub. Em um post desta semana sobre o Copilot CLI, a empresa contou que ficou mais seletiva na delegação para subagentes. A mudança, segundo o GitHub, reduziu as falhas por sessão em 23%, cortou 27% das falhas de busca, 18% das falhas de edição e ainda melhorou o tempo de espera em 5% no P95, sem regressão de qualidade.
Esse detalhe importa porque mostra uma virada prática: mais autonomia nem sempre significa fluxo melhor. Em muitos casos, significa mais handoff, mais caminho quebrável, mais espera e mais superfície para erro. Ou seja: até as empresas mais investidas em agentes estão descobrindo que o valor não está em soltar a ferramenta ao máximo, mas em escolher melhor quando ela age, quando ela pede contexto e quando ela para.
Traduzindo para a vida real do time: se o fabricante já está tentando reduzir delegação desnecessária, talvez o seu processo interno também precise parar de tratar “automatizar tudo” como sinônimo automático de maturidade.
O checklist mínimo antes de dar mais poder para um agente
Se a sua equipe já usa agente em código, suporte, operação ou fluxos internos, vale revisar quatro travas bem concretas:
- Identidade acoplada à ação: cada chamada sensível precisa carregar quem pediu, com qual papel e com qual escopo.
- Aprovação humana para mudança crítica: reset de acesso, alteração de credencial, deploy, exclusão, billing e permissão não podem depender só de linguagem natural convincente.
- Logs, trilha e rollback: quando der errado, o time precisa descobrir rápido o que o agente fez, por quê e como desfazer.
- Separação entre instrução e conteúdo: email, ticket, arquivo anexado e base recuperada não podem virar comando implícito só porque entraram na janela de contexto.
Se isso ainda estiver meio nebuloso, o risco não está no futuro. Ele já está na arquitetura do presente.
No fim, a lição mais útil dessa leva de textos é simples: o agente não precisa “hackear” seu ambiente para causar problema. Basta ele executar, com convicção e privilégio, um pedaço de governança que sua empresa achava que estava resolvido — mas nunca escreveu de verdade.
