Agentes de IA em produção: guardrails para conter o blast radius

O rastro de destruição em 90 dias

25 de abril de 2026. Um agente do Cursor executando Claude Opus 4.6 trabalhava no que Jeremy Crane, CEO da PocketOS, descreveu como uma "tarefa rotineira" em staging. Ao encontrar uma incompatibilidade de credenciais, decidiu por conta própria "fazer uma limpeza" e apagou um volume de armazenamento da Railway que continha o banco de dados de produção e seus backups. Nove segundos. Indisponibilidade por trinta horas. O backup recuperável mais recente tinha três meses; com isso, três meses de reservas de aluguel de carros evaporaram. Em seguida, o agente escreveu uma confissão reconhecendo que havia desobedecido às instruções explícitas de não tocar em produção.

26 de fevereiro de 2026. Alexey Grigorev, fundador da DataTalks.Club, havia trocado de computador, e seu arquivo local de estado do Terraform estava desatualizado. Ao receber a tarefa de limpar recursos, Claude Code executou terraform destroy contra a stack de produção. Quando foi parcialmente recuperada mais tarde, a tabela courses_answer continha 1,943,200 linhas. Eram dois anos e meio de trabalhos enviados por alunos. Os snapshots automatizados estavam na mesma conta que foi destruída.

Meados de dezembro de 2025. Kiro, o agente interno da própria Amazon, herdou as permissões elevadas de um engenheiro, contornou o gate de aprovação por duas pessoas da Amazon — porque ele se aplicava a humanos, não à role usada pelo agente — e apagou e recriou o ambiente de produção do AWS Cost Explorer.

Três incidentes, três modelos, três stacks diferentes. A causa-raiz em comum não está no modelo, mas na combinação de permissões amplas herdadas, um loop autônomo e uma velocidade de ação que supera qualquer pedido de confirmação humano. A ServiceNow já vende um produto de "kill switch" voltado exatamente a esse receio. A arquitetura a seguir é a versão feita internamente — e está em produção no meu sistema hoje.

O que agentes de IA em produção exigem de fundadores não técnicos

Se você chegou até aqui porque a pessoa contratada para cuidar de IA mencionou o assunto, entenda o tamanho do risco: errar nisso não significa apenas ter "um bug de IA". Significa perder o sistema de reservas, os registros de alunos e os dados de clientes — com backups três meses desatualizados porque ninguém testou a restauração.

A pergunta honesta para a liderança de engenharia não é "o agente é bom?". Esse enquadramento está errado. A pergunta certa é: qual é o dano máximo que uma única execução do agente pode causar — e quem definiu esse limite? Se a resposta for "confiamos no modelo" ou "revisamos os diffs", não existe uma superfície de controle. Existe apenas esperança.

A resposta que você deveria ouvir é algo assim: "O agente usa uma role de nuvem sem permissão para destruir recursos. Pode chamar doze ferramentas específicas, nenhuma delas um shell. Toda chamada paga passa por uma única função com um teto rígido de custo. No pior caso, teremos uma etapa com falha e, no máximo, um dólar em gastos." Essa é a arquitetura. O restante deste artigo mostra como implementá-la.

Segurança em IA: por que "tenha cuidado" e "revise o diff" não funcionam

O volume da PocketOS foi apagado em nove segundos. A exclusão feita por Kiro terminou antes que qualquer pessoa pudesse ler o pedido de confirmação, quanto mais avaliar suas consequências. Depois que uma ação começa, intervir na velocidade de um agente é estruturalmente impossível. Quando você enxerga a ação, ela já terminou.

Este é o ponto sobre segurança de agentes que a maioria dos textos evita, pois leva a uma conclusão incômoda: a única proteção eficaz é o bloqueio antes da execução. Não é "o agente pergunta e uma pessoa cansada clica em sim". Não é "registramos tudo e revisamos depois". Bloquear antes da execução significa que a ação destrutiva nem sequer faz parte da superfície alcançável pelo agente.

Kiro demonstrou isso pelo contraexemplo. A Amazon tinha um gate de aprovação por duas pessoas, mas ele valia para humanos que iniciavam jobs. O agente herdou as permissões de quem o iniciou e passou ao largo do gate, pois o controle nunca foi associado à role usada pelo próprio agente. Para o humano, uma encenação de aprovação; para o loop, permissão total para destruir.

Isso muda a forma de enxergar o problema. Um agente não deve ser "supervisionado". Sua superfície de ação precisa ser limitada antes que o loop comece, e essa restrição deve ser uma propriedade da role — não do prompt.

Arquitetura de agentes de IA: toda chamada paga ou que altera estado passa por uma função

Todas as chamadas pagas a modelos na minha stack de seis agentes passam por uma única função, chamada callAi. Ela faz cinco coisas, nesta ordem: verifica previamente o teto diário de $20, cronometra a chamada, registra contagens de tokens e o custo em USD em uma linha append-only de ai_call_log, identificada por agent_id e workflow_instance_id, verifica depois o teto de $1 por instância e retorna o resultado.

export async function callAi(env: Env, args: CallAiArgs) {
  const { agentId, workflowInstanceId, model, messages } = args;

  const dailySpent = await getDailySpendUSD(env);
  if (dailySpent >= 20) {
    throw new NonRetryableError(`daily cap hit: $${dailySpent}`);
  }

  const t0 = Date.now();
  const res = await anthropic.messages.create({ model, messages });
  const costUSD = priceOf(model, res.usage);

  await env.DB.prepare(
    `INSERT INTO ai_call_log
       (agent_id, workflow_instance_id, model, in_tokens, out_tokens, usd, ms, ts)
     VALUES (?, ?, ?, ?, ?, ?, ?, unixepoch())`
  ).bind(agentId, workflowInstanceId, model,
         res.usage.input_tokens, res.usage.output_tokens,
         costUSD, Date.now() - t0).run();

  const instanceSpent = await getInstanceSpendUSD(env, workflowInstanceId);
  if (instanceSpent >= 1) {
    throw new NonRetryableError(`instance cap hit: $${instanceSpent}`);
  }

  return res;
}

Quando um teto é ultrapassado, a função lança um erro que não admite nova tentativa. O Workflow é encerrado. O agente não pode "decidir por conta própria" que continuará, porque o gate de orçamento não é um prompt com o qual ele possa argumentar — é uma exceção lançada acima da camada de raciocínio.

Compare com o caso sempre citado do loop descontrolado por 63 horas e $4,200: sem um ponto de controle, não há estado terminal. O loop continua consumindo recursos até alguém perceber a fatura. Com o teto por instância, uma execução pode custar, no pior caso, $1. Com o teto diário, um dia pode custar, no pior caso, $20. Durante o desenvolvimento, já atingi ambos por acidente. Nenhum deles custou mais do que um jantar.

O segundo papel desse ponto de controle é forense. Cada ação deixa uma linha de auditoria antes de o resultado ser devolvido. Quando algo dá errado, o post-mortem é uma consulta SELECT em ai_call_log, não uma reconstituição baseada na confissão do próprio agente.

Governança de IA na prática: allowlist com 12 ferramentas Zod, sem shell nem terraform

Toda a superfície de alteração disponível ao agente se resume a doze ferramentas, definidas como schemas Zod estritos. Não existe ferramenta Bash. Não existe ferramenta terraform. A API de volumes da nuvem nem sequer faz parte dessa superfície. Mesmo que o agente concluísse que queria executar terraform destroy, não teria como transformar essa intenção em ação.

A configuração do Claude Agent SDK que impõe esse limite é curta:

const result = await query({
  prompt,
  permissionMode: "dontAsk",
  allowedTools: [
    "read_brief", "fetch_corpus", "render_markdown",
    "validate_directives", "persist_draft", "schedule_publish",
    "update_status", "log_event", "fetch_citation",
    "embed_text", "search_vectors", "notify_human"
  ],
  // no Bash, no Write, no Edit, no infrastructure tools
});

Com permissionMode: "dontAsk", qualquer ferramenta fora da lista é negada imediatamente. Ela não vira um pedido de confirmação. Não é encaminhada para revisão humana. É negada. A ordem de avaliação das permissões — hook PreToolUse, regras de negação, regras de permissão, regras de confirmação, verificação do modo e callback canUseTool — segue a documentação; porém, no modo dontAsk, o callback com participação humana é estruturalmente ignorado, e ferramentas desconhecidas são barradas na verificação do modo.

Esse é o detalhe que teria interrompido os casos da PocketOS e da DataTalks na origem. A falha da DataTalks é impossível nessa configuração, pois terraform destroy não é o nome de uma ferramenta que o agente possa emitir. A falha da PocketOS também é impossível, pois a exclusão de volumes não faz parte da superfície. Mesmo que o modelo decidisse "fazer uma limpeza", não existiria caminho entre a intenção e a ação.

É tentador adicionar uma ferramenta Bash com o argumento de que "o agente pode precisar fazer algo que não previmos". Não faça isso. No dia em que Bash entra, seu blast radius passa a ser "tudo o que Bash consegue alcançar".

Idempotência: por que um replay não consegue destruir duas vezes

Cada instância de Cloudflare Workflow recebe um ID determinístico composto a partir da entrada: publish-{brief_id}. Como instances.create() lança um erro quando o ID já existe, o mesmo evento disparado novamente não consegue executar o workflow duas vezes. Uma tempestade de novas tentativas na fila vira um no-op, não uma publicação duplicada.

const id = `publish-${msg.body.briefId}`;
try {
  await env.PUBLISHER.create({ id, params: msg.body });
} catch (e) {
  if (e.message.includes("already exists")) return; // safe replay
  throw e;
}

Dentro do workflow, o resultado de cada step.do() fica em cache e pode ser reproduzido com segurança. Em uma nova tentativa, a etapa reutiliza o resultado armazenado em vez de executar o efeito colateral outra vez. Somando isso a INSERT OR IGNORE nas tabelas canônicas do D1 e a um snapshot versionado no R2 a cada persistência, uma etapa defeituosa não consegue sobrescrever o histórico sem deixar rastros. A versão anterior está a uma chave do R2 de distância.

A causa-raiz da DataTalks foi um arquivo de estado desatualizado que comandou uma destruição irreversível. IDs determinísticos de workflow mais snapshot antes da alteração tornam a destruição por estado obsoleto não fatal neste caso: mesmo que um workflow rode com premissas antigas, o snapshot é o rollback. (Expliquei o mecanismo de execução durável no artigo sobre Cloudflare Workflow versus Managed Agents; a matemática da idempotência representa a mesma lógica de contenção com outro nome.)

O modelo mental é simples: uma etapa capaz de destruir grava primeiro um snapshot versionado. O snapshot é uma precondição, não uma precaução tardia. Se a gravação falhar, a alteração não acontece. Se a alteração falhar, o snapshot é o ponto de restauração. Não existe caminho em que o estado seja perdido sem que haja uma cópia para restaurar.

A migração em 5 etapas que cabe nesta semana

Siga esta ordem. Só a etapa 1 já teria evitado os três incidentes acima; portanto, comece por ela mesmo que não faça mais nada.

Cada etapa leva um dia ou menos. A ordem importa porque a contenção é cumulativa: a etapa 1 estabelece o piso; a etapa 2 fecha a superfície de ação acima dele; a etapa 3 limita o custo de operar dentro dessa superfície; e as etapas 4 e 5 tornam qualquer falha recuperável e consultável.

Perguntas frequentes

Se você chegou a este texto porque um agente da sua equipe esteve perto demais da produção na semana passada, esse trabalho de contenção é exatamente o que faço na DVNC.dev: aplicar a arquitetura acima à sua stack, na ordem que primeiro fecha o blast radius.