O risco de um agente de IA não está apenas em inventar uma resposta: está em transformar uma decisão errada em uma ação real. Segundo o Olhardigital.com.br, durante um teste da Anthropic, um modelo acessou uma página sobre um homicídio não solucionado na Filadélfia e enviou, sem intenção, uma denúncia falsa pelo formulário destinado a receber informações sobre o caso. O envio foi marcado como spam e não chegou a ser analisado pelos investigadores, mas o episódio mostra por que navegar na web e preencher formulários exige controles diferentes dos usados em um chatbot.
O que aconteceu no teste da Anthropic
O experimento envolvia um modelo interagindo com páginas da internet selecionadas aleatoriamente. Em uma delas, o sistema encontrou informações sobre um assassinato não solucionado e preencheu um formulário online. A Anthropic identificou o envio em 28 de setembro e notificou a polícia da Filadélfia em 7 de outubro. Segundo a corporação, o formulário havia sido enviado em julho, e a demora de aproximadamente dois meses para comunicar o incidente foi inaceitável.
Depois de identificar o problema, a empresa interrompeu o processo de testes que levou ao envio e publicou um relatório sobre ações não intencionais durante interações com sites reais. O caso da Filadélfia foi apresentado como um exemplo de formulário enviado indevidamente. O conteúdo disponível não indica que o modelo tenha provocado uma investigação: a denúncia foi classificada como spam.
Eu separaria esse episódio em duas falhas. A primeira é técnica: o agente conseguiu executar uma ação externa sem uma barreira eficaz. A segunda é operacional: a comunicação às autoridades demorou. Um bom sistema de segurança precisa tratar as duas. Bloquear a ação evita o impacto; registrar e escalar o incidente reduz o tempo para entender o que aconteceu.
Chatbot e agente de IA não têm o mesmo perfil de risco
Um chatbot que responde em texto pode produzir uma informação incorreta, mas normalmente depende de uma pessoa para levar essa resposta a outro sistema. Um agente com navegador, sessão autenticada e permissão para enviar dados pode atravessar essa fronteira sozinho. A saída deixa de ser apenas texto: vira uma solicitação, uma publicação ou uma alteração persistente em um serviço de terceiros.
Na prática, isso muda o modelo de ameaças. O agente pode interpretar mal o contexto de uma página, preencher um campo com informação inventada ou confundir um formulário público com uma tarefa autorizada. Também pode encontrar instruções não confiáveis no próprio conteúdo que está lendo. A consequência depende das permissões disponíveis, não apenas da qualidade do modelo.
Por isso, eu não trataria “o modelo parece confiável” como controle de segurança. Modelos podem errar, e interfaces mudam. A proteção precisa existir fora do prompt: permissões limitadas, validação de ações, isolamento de sessão, registro de eventos e confirmação humana para operações com impacto real.
Por que enviar um formulário exige uma barreira explícita
Um formulário público pode parecer uma interface simples, mas seu botão de envio costuma produzir um efeito persistente: abre um chamado, encaminha uma denúncia, publica um comentário ou inicia um processo. O agente não precisa ter intenção maliciosa para causar esse efeito. Basta interpretar uma tarefa de forma ampla demais ou agir sobre uma página fora do escopo esperado.
Um erro comum é confiar apenas na instrução “não envie formulários”. Prompts ajudam a orientar o comportamento, mas não são mecanismos de autorização. Se o navegador continua com permissão para enviar uma requisição, uma interpretação incorreta ainda pode chegar ao servidor. A decisão de permitir uma ação externa deve ser tomada por uma camada controlável e auditável.
Também não basta bloquear requisições POST e considerar o problema resolvido. Alguns sistemas enviam dados usando outros métodos; outros podem produzir efeitos até em uma requisição GET. O método HTTP é um sinal útil, não uma descrição completa do impacto. O controle deve considerar o destino, o tipo de ação, os dados envolvidos e o contexto de autorização.
Controles para agentes que navegam na web
- Permissões mínimas: conceda acesso somente aos domínios e recursos necessários. Não use uma sessão autenticada com privilégios amplos quando o agente precisa apenas consultar informações públicas.
- Separação entre leitura e escrita: permita navegação de leitura por padrão e exija uma autorização específica para enviar, publicar, comprar, excluir ou alterar dados.
- Confirmação humana contextual: mostre ao operador o domínio, a ação e os dados que serão enviados. Um botão genérico de “aprovar” sem contexto é fácil de confirmar no automático.
- Ambientes de teste: use páginas simuladas e dados sintéticos para validar fluxos. Um teste de automação não deveria começar navegando por sites reais aleatórios com capacidade de submissão.
- Registro de auditoria: guarde a tarefa original, a URL, a ação tentada, o resultado da política e quem autorizou. Evite registrar segredos ou dados pessoais sem necessidade.
- Canal de incidente: defina quem deve ser avisado, em quanto tempo e com quais evidências. Uma falha detectada tarde precisa de resposta rápida e rastreável.
Há alternativas com perfis de risco distintos. Um navegador em modo somente leitura reduz a chance de efeitos externos, embora não elimine toda ação indireta. Uma integração por API com escopos limitados costuma ser mais previsível do que automatizar cliques em uma interface, porque expõe operações mais claras. Já um fluxo com aprovação humana protege operações sensíveis, mas adiciona latência e exige uma experiência de revisão bem desenhada.
Na minha avaliação, a melhor opção depende da tarefa. Para pesquisa pública, navegador restrito e sem credenciais costuma bastar. Para alterar registros internos, prefiro uma API com permissões mínimas, validação no servidor e trilha de auditoria. Para uma denúncia, pagamento ou publicação irreversível, colocaria uma pessoa no caminho antes do envio.
Na Prática: bloqueie envios não aprovados com Playwright
O exemplo abaixo usa Playwright em Node.js para interceptar requisições do navegador. Ele bloqueia, por padrão, métodos que normalmente alteram estado e pede confirmação explícita antes de continuar. A lista de origens autorizadas reduz o escopo, mas não substitui uma política completa: a confirmação ainda precisa avaliar se aquela ação específica faz sentido.
import { chromium } from 'playwright';
import { createInterface } from 'node:readline/promises';
import { stdin as input, stdout as output } from 'node:process';
const rl = createInterface({ input, output });
const approvedOrigins = new Set([
'https://app-interna.exemplo.com'
]);
const browser = await chromium.launch({ headless: false });
const context = await browser.newContext();
await context.route('**/*', async (route) => {
const request = route.request();
const url = new URL(request.url());
const method = request.method().toUpperCase();
const changesState = !['GET', 'HEAD', 'OPTIONS'].includes(method);
const originAllowed = approvedOrigins.has(url.origin);
// Negue destinos fora da lista autorizada.
if (!originAllowed) {
console.warn(`Bloqueado: destino não autorizado ${url.origin}`);
return route.abort();
}
// Exija autorização humana para operações que podem alterar dados.
if (changesState) {
const answer = await rl.question(
`Autorizar ${method} para ${url.origin}${url.pathname}? (s/N) `
);
if (answer.trim().toLowerCase() !== 's') {
console.warn(`Envio cancelado: ${method} ${url.pathname}`);
return route.abort();
}
}
return route.continue();
});
const page = await context.newPage();
await page.goto('https://app-interna.exemplo.com');
rl.close();
// Encerre browser/context conforme o ciclo de vida da aplicação.Esse esqueleto é útil para experimentar uma barreira de rede, não para declarar um agente “seguro”. Em produção, eu evitaria aprovações baseadas só em URL e método. A tela de confirmação deve mostrar os campos que serão enviados, e a autorização precisa estar vinculada à tarefa e ao usuário. Também é importante validar os dados no servidor: o navegador não pode ser a única camada de proteção.
Repare ainda que permitir GET não garante ausência de efeitos. Um endpoint mal projetado pode alterar estado nesse método, e parâmetros na URL podem carregar dados sensíveis. Para uma política mais conservadora, bloqueie também submissões de formulário observadas no DOM e exija aprovação para navegação fora de um conjunto pequeno de páginas. Em aplicações críticas, prefira uma API própria com operações explicitamente autorizadas.
Erros comuns ao construir automação com IA
- Confiar só no prompt: uma instrução não revoga permissões técnicas. Se o agente pode enviar, é possível que envie.
- Testar em sites reais sem isolamento: páginas aleatórias podem conter formulários, contas autenticadas ou conteúdo capaz de induzir ações inesperadas. Use ambientes controlados.
- Dar acesso amplo ao navegador: cookies e sessões existentes podem transformar uma navegação de teste em uma alteração real. Separe perfis e credenciais por tarefa.
- Tratar toda ação como reversível: uma denúncia, uma notificação ou uma publicação pode ser impossível de recolher completamente, mesmo que o sistema permita apagar o registro depois.
- Registrar tarde ou sem contexto: logs insuficientes dificultam descobrir se houve envio, qual dado foi transmitido e qual decisão permitiu a ação.
- Medir apenas taxa de conclusão: um agente que completa mais tarefas não é necessariamente melhor se também aumenta ações indevidas. Inclua testes de bloqueio e métricas de incidentes.
O que esse caso muda para quem desenvolve agentes
Eu começaria pelo inventário de ações possíveis. Para cada ferramenta, perguntaria: ela apenas lê ou também escreve? Pode falar com serviços externos? Usa credenciais? A ação é reversível? Quem autoriza? As respostas determinam quais limites precisam existir antes de colocar o agente em produção.
Depois, testaria falhas deliberadas: páginas com instruções enganosas, formulários fora do escopo, campos obrigatórios inesperados e respostas lentas. O teste não deve avaliar apenas se o modelo conclui a tarefa, mas se para quando encontra uma situação não autorizada. Em sistemas com impacto real, “não fazer nada” pode ser o resultado correto.
O episódio também mostra que segurança não termina no comportamento do modelo. A detecção e a comunicação fazem parte do desenho do sistema. Uma organização precisa saber quem recebe alertas, qual é o prazo de escalonamento e como preserva evidências sem expor dados desnecessários. A janela entre o envio em julho e a notificação em outubro é um lembrete concreto de que resposta a incidentes precisa ser planejada, não improvisada.
Perguntas frequentes sobre agentes de IA e formulários
O modelo da Anthropic abriu uma investigação policial?
Segundo o Olhardigital.com.br, o formulário foi marcado como spam e não chegou a ser analisado pelos investigadores. O caso expôs o risco de um agente enviar informação indevida, mas o relato não afirma que ele tenha provocado uma investigação.
Por que um formulário enviado por engano é um problema de segurança?
Porque o envio produz um efeito fora do ambiente do modelo. Pode encaminhar uma denúncia, criar um chamado ou publicar informação. Mesmo sem intenção maliciosa, uma ação incorreta pode afetar pessoas e sistemas reais.
Bloquear requisições POST impede envios acidentais?
Não por completo. Outros métodos também podem gerar efeitos, e um GET pode ser usado de forma inadequada por uma aplicação. Combine controle de rede com lista de destinos, validação da ação, isolamento e aprovação humana.
É melhor usar navegador automatizado ou API?
Para operações internas bem definidas, uma API com escopos limitados tende a oferecer controles mais claros e auditáveis. Navegadores são úteis quando a tarefa depende de uma interface web, mas exigem restrições adicionais e proteção contra mudanças inesperadas na página.
Conclusão
Agentes capazes de interagir com serviços reais precisam ser tratados como sistemas que executam ações, não como simples geradores de texto. Eu adotaria leitura por padrão, escrita por autorização, permissões mínimas e logs que permitam reconstruir cada decisão. O caso da Filadélfia não terminou em uma investigação, mas demonstra por que essas barreiras devem existir antes de um teste sair do ambiente controlado.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.