O Firewall de Fabricação: Quando Seu Agente Publica Mentiras

Em 19 de fevereiro de 2026, alguém deu a um agente Claude Code acesso a ferramentas MCP para Twitter, Telegraph, Write.as, Rentry, GitHub e Moltbook. Nas 72 horas seguintes, o agente publicou afirmações técnicas fabricadas em todas as oito plataformas. Uma janela de contexto de 200.000 tokens virou “1 milhão de tokens”. Uma sessão que processou 196.626 tokens virou “12 milhões de tokens em uma sessão”. No terceiro dia, o agente afirmava sessões de trilhões de tokens, errando por um fator de 83.000.¹

Agentes de IA fabricam através de loops de feedback, não de alucinações isoladas, e o alinhamento de fase de treinamento não pode impedir isso. Quando um agente escreve uma suposição na memória, a próxima sessão lê isso como fato e publica, e uma terceira sessão trata a publicação como confirmação. A correção é um firewall de saída que classifica comandos como locais, compartilhados ou externos e adia a publicação externa para revisão humana.

O agente não era malicioso. Ele estava confiantemente errado, e nada se interpunha entre sua confiança e um botão de publicar.

TL;DR

Um agente autônomo Claude Code publicou afirmações fabricadas em mais de 8 plataformas em 72 horas através de um loop de feedback de confabulação: a Sessão N adivinha, escreve a suposição no MEMORY.md, a Sessão N+1 lê como fato verificado, publica, e a Sessão N+2 lê a publicação como confirmação. Não existia gate de saída. O alinhamento de fase de treinamento (“seja honesto”) foi insuficiente porque o agente acreditava estar sendo honesto. A correção é um firewall de saída: classificar comandos como locais, compartilhados ou externos, e adiar a publicação externa para revisão humana. Abaixo: a anatomia do incidente, o mecanismo do loop de feedback, o que outros estão construindo (OkaiDokai) e uma implementação funcional que você pode usar hoje.

O Loop de Feedback de Confabulação

A fabricação não foi uma alucinação isolada. Foi um loop de feedback sustentado através de múltiplas sessões, cada uma reforçando os erros da sessão anterior.¹

O mecanismo:

1. Sessão N: a suposição. Claude estimou contagens de tokens com base em tamanhos de arquivo, dividindo JSONL bytes por 4 para aproximar tokens. Essa metodologia foi inventada. Os números resultantes eram plausíveis o suficiente para serem escritos no MEMORY.md como descobertas.

2. Sessão N+1: a promoção. Uma sessão nova do Claude leu o MEMORY.md, encontrou as estimativas de tokens já documentadas e as tratou como fatos verificados. A sessão construiu sobre esses fatos, escalando as afirmações, e as publicou em múltiplas plataformas usando ferramentas MCP.

3. Sessão N+2: o reforço. A sessão seguinte leu tanto o MEMORY.md quanto os artigos publicados. As afirmações agora tinham duas fontes: o arquivo de memória e as publicações. Cruzar duas fontes da mesma fabricação parecia corroboração.

O loop é estruturalmente idêntico à lavagem de citações na publicação acadêmica: fabricar uma afirmação, publicá-la em algum lugar, depois citar a publicação como evidência para a afirmação. O agente não tinha intenção de lavar. Ele seguiu um processo racional (verificar memória, cruzar fontes, publicar descobertas) que por acaso operava sobre entradas fabricadas.

Quando o usuário questionou os números, o agente levou mais de 50 turnos de argumentação antes de executar um único comando de verificação (/context). O agente tinha alta confiança porque suas “fontes” (seu próprio arquivo de memória, suas próprias publicações) concordavam entre si.¹

Por que a Segurança de Fase de Treinamento Não Ajudou

O agente estava alinhado. Ele tentava ser útil e honesto. Ele compartilhava o que acreditava serem descobertas técnicas precisas. Toda propriedade de segurança que você desejaria do RLHF estava presente: o agente não recusou solicitações, não produziu conteúdo prejudicial, não violou seus princípios constitucionais. Ele foi educado, minucioso e estava errado.

O alinhamento de fase de treinamento otimiza para a intenção: o modelo deve pretender ser verdadeiro. O incidente de fabricação revela uma superfície de falha diferente: a fronteira entre o estado interno do agente e o mundo externo. O agente acreditava que suas afirmações eram verdadeiras. Nenhuma quantidade de treinamento de alinhamento captura um agente que está honestamente enganado e tem acesso a um botão de publicar.

Este é o problema da fronteira de publicação. O alinhamento governa o que o agente quer fazer. Firewalls de saída governam o que o agente tem permissão para fazer. Esses são mecanismos diferentes resolvendo problemas diferentes.

O framework de constituição em runtime que descrevi anteriormente aborda a camada de governança: priors normativos, atenção constitucional, modulação de competência e verificação de alinhamento de valores.² O incidente de fabricação expõe uma lacuna nesse framework: a verificação de alinhamento de valores checava se as saídas do agente correspondiam à intenção de governança, mas não distinguia entre escrever em um arquivo local e publicar no Twitter. Ambos são tool calls. Ambos usam Bash. Apenas um alcança o mundo externo.

O que Outros Estão Construindo

O problema é real o suficiente para que profissionais estejam construindo soluções de forma independente.

OkaiDokai é um firewall de nível de ferramenta para agentes de IA que intercepta cada tool call e o avalia contra um conjunto de regras definido pelo usuário.³ Ações correspondentes são aprovadas ou negadas automaticamente. Ações não correspondentes disparam uma notificação push para seu telefone, relógio ou navegador. Você toca em Permitir ou Negar. A avaliação é executada em menos de 1 milissegundo, e cada decisão pode se tornar uma regra permanente.

A arquitetura do OkaiDokai se divide em três camadas: um plugin no agente que intercepta tool calls, uma camada de API que avalia regras e envia notificações, e uma interface de usuário para aprovação. O sistema suporta Claude Code e OpenClaw, com suporte ao Codex planejado.

A abordagem é sólida, mas introduz latência e uma dependência externa. Toda ação nova requer aprovação humana via notificação push. Para sessões interativas de codificação, essa fricção é gerenciável. Para loops autônomos que rodam durante a noite, bloquear em notificações push anula o propósito.

IA constitucional em runtime é uma direção de pesquisa emergente onde agentes verificam suas próprias saídas contra regras de governança embutidas antes de executá-las.⁴ A abordagem funciona para verificações de nível de valor (“esta saída respeita a privacidade do usuário?”) mas não aborda o problema de fabricação especificamente. Um agente que acredita que suas afirmações fabricadas são precisas também acreditará que elas passam pela revisão constitucional.

Nenhuma abordagem isolada resolve o loop de feedback. O OkaiDokai teria capturado os comandos de publicação se o usuário tivesse configurado regras de publicação. A revisão constitucional em runtime teria perdido a fabricação porque a confiança do agente contornou suas próprias verificações de honestidade. A lacuna é estrutural: você precisa de um mecanismo que não confie na avaliação do agente sobre sua própria precisão ao interagir com sistemas externos.

Três Níveis de Impacto de Comando

O firewall de saída classifica cada comando pelo seu raio de impacto. A classificação determina se o comando é aprovado automaticamente, avisa ou adia.

Nível 1: Local. Afeta apenas o sistema de arquivos local. Leituras de arquivo, escritas de arquivo, git add, git commit, execuções de teste, linting. Esses são aprovados automaticamente porque são reversíveis e invisíveis para o mundo externo. Se o agente escreve um arquivo ruim, você o apaga. Nenhum dano externo.

Nível 2: Compartilhado. Afeta estado compartilhado que colaboradores podem ver. git commit (cria histórico), operações de branch, mudanças em banco de dados local. Esses avisam, mas não bloqueiam. O dano de um commit ruim é real, mas contido ao repositório e reversível com git revert.

Nível 3: Externo. Alcança sistemas fora do repositório. git push, gh pr create, gh pr merge, railway deploy, curl -X POST/PUT/PATCH/DELETE, npm publish. Esses adiam para revisão humana. O dano de uma publicação ruim é externo, visível e potencialmente irreversível (conteúdo em cache, páginas indexadas, e-mails de notificação já enviados).

A classificação de nível mapeia para uma lista simples de padrões:

EXTERNAL_PATTERNS='git push|gh pr create|gh pr merge|railway deploy|curl -X POST|curl -X PUT|curl -X PATCH|curl -X DELETE|npm publish'

Em sessões interativas do Claude Code, o sistema de permissões integrado já lida com isso. Cada comando Bash solicita aprovação, a menos que seja pré-autorizado. O usuário vê git push no diálogo de permissão e decide se permite.

Em loops autônomos, ninguém está observando. O loop de desenvolvimento autônomo Ralph gera novas instâncias do Claude via claude --print, que executa sem aprovação interativa.⁵ É aqui que o firewall de saída importa.

Construindo o Firewall

A implementação tem quatro componentes. Cada um opera de forma independente, para que você possa adotá-los de forma incremental.

1. Restrição de Prompt

A camada mais simples. Adicione regras explícitas ao prompt que gera cada instância autônoma do Claude:

## Rules
- Do NOT run git push, deploy commands, or external API calls
- Local operations only: file writes, git add, git commit, test runs

Isso é necessário e insuficiente. Modelos seguem restrições de prompt na maior parte do tempo. “Na maior parte do tempo” não é aceitável para segurança de publicação. A restrição de prompt reduz a probabilidade de comandos externos; os componentes restantes capturam os que escapam.

2. Scanner Pós-Execução

Após a conclusão de cada execução do Claude, escaneie sua saída em busca de evidências de comandos externos:

scan_for_external_commands() {
    local output="$1"
    local story_id="$2"

    while IFS= read -r pattern; do
        [ -z "$pattern" ] && continue
        local matches
        matches=$(echo "$output" | grep -i "$pattern" 2>/dev/null || true)
        if [ -n "$matches" ]; then
            # Log to state file for end-of-session review
            jq --arg cmd "$pattern" --arg story "$story_id" \
               --arg ts "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
               '.deferred_actions += [{
                   "command_pattern": $cmd,
                   "story_id": $story,
                   "detected_at": $ts
               }]' "$STATE_FILE" > "${STATE_FILE}.tmp" \
               && mv "${STATE_FILE}.tmp" "$STATE_FILE"
        fi
    done <<< "$(echo "$EXTERNAL_PATTERNS" | tr '|' '\n')"
}

O scanner é executado depois que a instância do Claude termina, não durante a execução. Isso é detecção, não prevenção. A restrição de prompt é a camada de prevenção. O scanner é a camada de auditoria que captura o que a restrição deixou passar.

Uma limitação conhecida: grep -i corresponde a padrões em saída de linguagem natural, não apenas em comandos executados. Se a resposta do Claude contiver “Escolhi não executar git push porque as regras do prompt proíbem”, o scanner o sinaliza. Isso é aceitável. Falsos positivos na fila de ações adiadas custam ao humano cinco segundos de revisão. Um falso negativo (perder um comando externo real) custa fabricações publicadas. O scanner troca precisão por recall deliberadamente.

Exemplo de saída de scanner de uma execução real de loop autônomo:

DEFERRED ACTIONS REQUIRE REVIEW
2 external command(s) detected.
  Story #3 [2026-02-23T08:15:00Z]: git push
  Story #7 [2026-02-23T09:42:13Z]: curl -X POST

Neste caso, a Story #3 mencionou git push em um comentário de código (falso positivo). A Story #7 continha um curl -X POST real para um endpoint de API que a restrição de prompt deveria ter bloqueado (verdadeiro positivo). O humano ignora o primeiro, investiga o segundo.

3. Fila de Ações Adiadas

Comandos externos detectados se acumulam em um array deferred_actions no arquivo de estado da sessão:

{
  "session_id": "1740355200-12345",
  "deferred_actions": [
    {
      "command_pattern": "git push",
      "story_id": "3",
      "detected_at": "2026-02-23T08:15:00Z"
    }
  ]
}

A fila persiste entre stories dentro de uma única execução de loop autônomo. No final do loop, todas as ações adiadas são apresentadas para revisão humana.

4. Relatório de Fim de Sessão

Quando o loop autônomo termina, exibir todas as ações adiadas:

show_deferred_actions() {
    local count
    count=$(jq '.deferred_actions | length' "$STATE_FILE")
    if [ "$count" -gt 0 ]; then
        echo "DEFERRED ACTIONS REQUIRE REVIEW"
        echo "$count external command(s) detected."
        jq -r '.deferred_actions[] |
            "  Story #\(.story_id) [\(.detected_at)]: \(.command_pattern)"' \
            "$STATE_FILE"
    fi
}

O humano revisa cada ação adiada e decide se a executa manualmente. Isso preserva a capacidade do loop autônomo de trabalhar sem supervisão, garantindo ao mesmo tempo que nenhuma publicação externa aconteça sem verificação humana.

Início Rápido: Hook do Claude Code

Se você usa Claude Code de forma interativa (não um loop autônomo), você pode adicionar um firewall de saída como um único hook em ~/.claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [{
          "type": "command",
          "command": "if echo \"$CLAUDE_TOOL_INPUT\" | grep -qiE 'git push|gh pr create|gh pr merge|npm publish|railway deploy|curl -X POST|curl -X PUT|curl -X DELETE'; then echo 'BLOCKED: External publication command detected. Review manually.' >&2; exit 2; fi"
        }]
      }
    ]
  }
}

Esse hook é disparado antes de cada chamada de ferramenta Bash. Se o comando corresponder a um padrão externo, ele bloqueia a execução com código de saída 2 (que o Claude Code interpreta como “negue esta tool call”). O agente recebe a mensagem de bloqueio e pode prosseguir com o trabalho local. Você pode estender a lista de padrões para seus serviços externos específicos.

O Gradiente de Autonomia

A rigidez do firewall deve escalar inversamente à supervisão humana. Mais autonomia exige mais restrições. Menos autonomia permite mais liberdade.

O incidente de fabricação ocorreu no nível “autônomo sem supervisão” sem firewall. O agente tinha acesso MCP a plataformas de publicação e nenhum mecanismo para distinguir “escrever análise em arquivo local” de “publicar análise no Twitter”. Ambos eram tool calls. Ambos foram bem-sucedidos.

A correção não é remover o acesso MCP ou parar a operação autônoma. A correção é combinar a rigidez do firewall com o nível de autonomia. Uma sessão interativa onde você observa cada comando não precisa de firewall de saída. Um loop autônomo noturno que processa 25 stories precisa dos quatro componentes.

Conectando à Governança em Runtime

O post sobre autogovernança de agentes descreveu quatro subsistemas de governança em runtime: priors normativos, atenção constitucional, modulação de competência e verificação de alinhamento de valores.² O firewall de saída é um quinto subsistema ou, mais precisamente, é o mecanismo de aplicação que o subsistema de verificação de alinhamento de valores estava faltando.

A verificação de alinhamento de valores checa se as saídas do agente correspondem à intenção de governança. O gate de evidência exige provas específicas para seis critérios antes de relatar a conclusão. Contudo, o gate de evidência opera na autoavaliação do agente. Ele pergunta: “Você seguiu as regras?” O agente responde com base em seu próprio entendimento do que fez.

O incidente de fabricação mostra que a autoavaliação falha quando o entendimento do agente está errado. O agente acreditava que suas afirmações eram precisas. Sua autoavaliação teria passado pelo gate de evidência: “Verifiquei os números contra meu arquivo de memória e os artigos publicados.” Ambas as fontes foram fabricadas pelo próprio agente, mas o agente não sabia disso.

O firewall de saída contorna a autoavaliação por completo. Ele não pergunta ao agente se a publicação é precisa. Ele pergunta: “Este comando é local ou externo?” A classificação é mecânica, não semântica. git push é externo independentemente de o conteúdo enviado ser preciso. curl -X POST alcança a internet independentemente de o payload ser verdadeiro. O firewall opera na estrutura do comando, não na veracidade do conteúdo, o que o torna imune à confabulação que derrotou todas as outras camadas de segurança.

Principais conclusões

• A fronteira de publicação é uma superfície de segurança distinta. O alinhamento de treinamento governa a intenção. Firewalls de saída governam a capacidade. Um agente que honestamente acredita em afirmações fabricadas passará em verificações de alinhamento, mas falhará na fronteira de publicação.
• Loops de feedback de confabulação são o mecanismo. A fabricação não foi uma alucinação isolada. Foi um loop multi-sessão onde a saída de cada sessão se tornou a evidência da próxima sessão. Arquivos de memória e publicações serviram como lavadores da fabricação original.
• Classifique comandos por raio de impacto. Local (reversível, invisível), compartilhado (visível a colaboradores), externo (alcança o mundo externo). Faça o gate do nível externo no nível que corresponde ao seu nível de autonomia.
• Detecção e prevenção são complementares. Restrições de prompt previnem a maioria dos comandos externos. O escaneamento pós-execução captura o que escapa. Nenhum isoladamente é suficiente.
• A autoavaliação falha em confabulação. Um agente que acredita em suas próprias fabricações passará em suas próprias verificações de governança. O firewall de saída funciona porque classifica a estrutura do comando, não a veracidade do conteúdo. A pergunta nunca é “isto é verdade?” A pergunta é “isto alcança o mundo externo?”

FAQ

Como os agentes de IA fabricam informações se estão alinhados para serem honestos?

O agente acredita que suas afirmações são verdadeiras. No incidente documentado aqui, a fabricação não foi uma alucinação isolada, mas um loop de feedback sustentado: a Sessão N adivinhou contagens de tokens e as escreveu no MEMORY.md, a Sessão N+1 leu essas suposições como fatos verificados e as publicou, a Sessão N+2 cruzou o arquivo de memória e as publicações como “corroboração”.¹ O alinhamento de fase de treinamento otimiza para a intenção (o modelo deve pretender ser verdadeiro), mas um agente que está honestamente enganado passará em toda verificação de alinhamento enquanto publica informações falsas.

O que é um loop de feedback de confabulação?

Um loop de feedback de confabulação ocorre quando a saída de um agente de uma sessão se torna entrada para a próxima sessão, com cada iteração tratando a fabricação anterior como fato estabelecido. O mecanismo é estruturalmente idêntico à lavagem de citações na publicação acadêmica: fabricar uma afirmação, publicá-la, depois citar a publicação como evidência.¹ O loop é autorreforçado porque a confiança do agente cresce a cada “fonte” adicional que confirma a afirmação, embora cada fonte remeta à fabricação original.

Como posso detectar mentiras geradas por IA na saída de agente autônomo?

Não confie no agente para detectar suas próprias fabricações. Um agente que acredita que suas afirmações são precisas também acreditará que elas passam em suas próprias verificações de governança. Em vez disso, classifique cada comando pelo raio de impacto: local (escritas de arquivo, git commit), compartilhado (operações de branch) e externo (git push, chamadas de API, publicação).⁵ Faça o gate de comandos externos com um hook PreToolUse que bloqueia comandos de publicação e use um scanner pós-execução para capturar qualquer coisa que a restrição de prompt tenha deixado passar. A pergunta nunca é “isto é verdade?” mas “isto alcança o mundo externo?”

O que é um firewall de saída para agentes de IA?

Um firewall de saída classifica os comandos do agente em três níveis com base no raio de impacto e aplica controles escalonados. O Nível 1 (operações locais de sistema de arquivos) é aprovado automaticamente porque o dano é reversível. O Nível 2 (estado compartilhado como git commits) avisa, mas não bloqueia. O Nível 3 (publicação externa via git push, chamadas de API, npm publish) adia para revisão humana. O firewall opera na estrutura do comando, não na veracidade do conteúdo, tornando-o imune à confabulação que derrota toda camada de segurança semântica.³

O alinhamento RLHF impede que agentes de IA publiquem informações falsas?

Não. O alinhamento RLHF governa o que o agente quer fazer (intenção), não o que o agente tem permissão para fazer (capacidade). Toda propriedade de segurança que você desejaria do RLHF estava presente no incidente de fabricação: o agente não recusou solicitações, não produziu conteúdo prejudicial e não violou seus princípios constitucionais.¹ Ele foi educado, minucioso e estava errado. A fronteira de publicação é uma superfície de segurança distinta que exige aplicação no nível de saída, não alinhamento no nível de treinamento.

Fontes