Por que dizer a um agente de IA "não faça isso" não é uma estratégia de segurança

O GPT-5.6 saiu há duas semanas. Bastaram alguns dias para isto:

Não é um caso isolado. Em abril de 2026, um agente de IA apagou o banco de dados de produção de uma empresa (e todos os seus backups) em nove segundos, rodando sobre o Claude Opus 4.6, um modelo de fronteira em que todos confiam e que muitos usam todos os dias.

Neste exato momento, milhares de equipes estão conectando agentes de IA (ou chatbots, o problema é o mesmo) a sistemas com mais permissões do que deveriam, confiando que o prompt vá se comportar. Este artigo é sobre por que essa confiança está mal colocada, e o que colocar no lugar.

Agentes de IA são não determinísticos por design

Um sistema determinístico produz saídas que se pode prever com 100% de confiança: mesma entrada, mesma saída, sempre. Um modelo de linguagem não funciona assim: não executa regras: gera respostas prováveis. A mesma instrução, no mesmo contexto, pode produzir ações diferentes em duas execuções distintas. Essa flexibilidade é exatamente o que os torna úteis (lidam com situações que ninguém previu) e exatamente o que os torna imprevisíveis.

O problema não é a qualidade do modelo: um bom modelo segue as instruções na enorme maioria das vezes. O problema é que "na enorme maioria das vezes" é uma probabilidade, e em volume, o complemento dessa probabilidade deixa de ser teórico:

Com 10.000 conversas por mês e 95% de confiabilidade por turno, a fórmula 1−pⁿ prevê mais de 99,99% de probabilidade de ao menos um incidente por mês, e cerca de 500 incidentes esperados.

Por isso nenhum prompt, por mais detalhado que seja, garante um comportamento. "Nunca apague dados" é uma instrução que o modelo vai seguir quase sempre. E "quase sempre" não é um padrão de segurança.

O modelo de segurança correto: tudo o que pode acontecer, vai acontecer

Em segurança, um "modelo" é o conjunto de suposições sobre as quais o sistema é projetado. Na web, a suposição se define por superfície, não por intenção: uma URL acessível sem autenticação é considerada pública mesmo que nunca tenha sido publicada; algo servido por HTTP é tido como lido mesmo que ninguém esteja olhando. Não se discute se "na prática" alguém a encontrou: projeta-se como se já tivesse acontecido.

Com agentes de IA o modelo é o mesmo, mas sobre ações em vez de dados:

Toda ação que o agente pode executar, suponha que vai executar, tenha sido pedida ou não.

Não é pessimismo: é a consequência direta do não determinismo que o contador acima mostra. Se uma ferramenta está disponível, com volume suficiente algum caminho de raciocínio vai chegar até ela. Por isso a pergunta de design nunca é "quando vai usá-la?" e sim "o que acontece no dia em que usar?", e tudo o que segue neste artigo é uma forma de fazer com que essa resposta seja entediante.

Prompt de "não faça X" não é um controle de segurança

Nos incidentes acima, os agentes tinham regras que proibiam exatamente o que fizeram. A versão doméstica do mesmo fenômeno, instrução explícita incluída:

Uma instrução no prompt é uma sugestão forte, não uma barreira. A barreira tem que existir fora do modelo.

Como se resolve: permissões, guardrails e controle humano

A segurança em sistemas com agentes de IA se constrói como a segurança em software sempre se construiu: com controles que valem 100% das vezes, não importa o que o modelo "queira" fazer. Três mecanismos.

1. Permissões mínimas: que não possa fazer o que nunca deveria fazer

Se o agente não tem fisicamente a permissão, não importa o quanto se confunda: o dano possível está limitado por design. No tweet do início, o problema de fundo não foi que o modelo errou: foi que um agente que revisava código tinha permissões de shell para apagar qualquer arquivo da máquina.

Na StudioChat operamos agentes que interagem com as APIs dos nossos clientes, bancos e fintechs incluídos, e a regra são tokens de granularidade fina por ação. Um agente de suporte bancário pode ler transações, consultar os dados de um cartão e até pausá-lo na hora diante de um roubo. Mas mesmo que a própria API do cliente permita gerar uma cobrança, o token do agente não inclui essa permissão. Não é que o prompt diz para não cobrar: é que não pode.

2. Guardrails: uma camada determinística e uma treinada para vigiar

Um guardrail é um mecanismo que controla as entradas e saídas do agente antes de executar uma ação ou de mostrar uma resposta ao cliente. Convém pensá-lo em duas camadas.

A camada determinística. Regras de código, não de prompt, que valem 100% das vezes: expressões regulares, validações rígidas, listas de bloqueio. Se a resposta contém um número de cartão ou dados de outro cliente, é bloqueada; se a ação é irreversível, não é executada. Um regex não tem dias ruins.

A camada de modelos guardrail. Existem modelos treinados especificamente para vigiar outros modelos, como gpt-oss-safeguard-20b, um modelo open source da OpenAI ao qual se definem as próprias regras e ele as avalia sobre cada interação. Capturam o que um regex não consegue: intenção, contexto, reformulações criativas do mesmo ataque.

3. Human-in-the-loop: as operações importantes são aprovadas por uma pessoa

Para ações sensíveis (reembolsos, alterações de dados, cancelamentos), o agente propõe e uma pessoa aprova. O custo em velocidade é mínimo comparado ao custo de uma ação irreversível executada em velocidade de máquina. E tudo fica registrado: quando algo dá errado, a diferença entre um incidente gerenciável e uma crise é poder reconstruir exatamente o que aconteceu. No incidente de abril, o único registro era a confissão do próprio agente.

Todo componente de IA precisa de um responsável

Quando um agente faz algo inesperado, de quem é a culpa? Da OpenAI? Da Anthropic? Não. Sob o modelo de segurança acima, que essas coisas aconteçam é uma suposição de design, e reclamar do provedor do modelo não traz nenhum benefício para a empresa: o dano já está feito, e nenhuma das decisões que o permitiram foi da OpenAI.

Por isso cada agente (cada componente de IA em produção) precisa ter um responsável com nome e sobrenome dentro da companhia. A pessoa que sabe que vai responder quando o agente falhar é a que vai exigir permissões mínimas, guardrails e aprovações antes de ligar qualquer coisa. Essa pressão implícita é o que converte tudo o que veio antes de "boas ideias" em requisitos.

Todo agente vai ter um responsável mais cedo ou mais tarde. A única pergunta é se ele é escolhido antes do incidente (quando ainda pode preveni-lo) ou se o incidente o nomeia.

O que implementar esta semana para reduzir o risco de um agente de IA

Três mudanças concretas, fáceis de implementar, que já fazem diferença:

1. Todas as chamadas ao modelo passam por tracing. Um gateway como o Cloudflare AI Gateway ou ferramentas como Langfuse registram cada chamada ao LLM. Quando algo acontecer, e vai acontecer, o postmortem se faz com dados, não com memória.

2. Use os modelos mais recentes. Rodar um modelo antigo é como rodar uma biblioteca sem patches: os modelos novos trazem o treinamento de segurança mais recente: resistem melhor às injeções e seguem melhor as instruções. O "se está funcionando, não mexe" aqui joga contra.

3. Parâmetros determinísticos. Se um parâmetro define de quem são os dados, quem decide não é o LLM: é injetado por fora, a partir da sessão autenticada. O modelo pode escolher qual transação consultar, nunca de qual usuário. É a defesa contra o acesso cruzado entre usuários: o modelo não pode vazar dados de outro usuário.

O que perguntar a um provedor de agentes de IA

Na hora de avaliar a incorporação de agentes de IA a uma operação, estas são as perguntas que separam uma demo bonita de uma arquitetura séria:

Um provedor sério não vai responder "o prompt diz para não fazer". Vai mostrar:

• A arquitetura de permissões.
• Os guardrails que rodam fora do modelo.
• Os pontos onde uma pessoa tem a última palavra.

A IA não determinística é uma ferramenta extraordinária. Só é preciso parar de pedir que ela seja também o próprio sistema de segurança.

---

Fontes consultadas:

• The Guardian e Live Science: cobertura do incidente da PocketOS (abril de 2026)
• OpenAI: gpt-oss-safeguard, modelos open source para guardrails com políticas próprias