Josimar JMV
Blog · IA em produção · 30·08·2026

O safeguard me sabota: pente-fino de segurança com IA que trava na hora H

A primeira coisa que qualquer um em sã consciência faz com um modelo bom é um checkup de segurança no próprio negócio. Foi o que eu fiz — e foi exatamente aí que o modelo começou a me trocar sozinho por um mais fraco.

Resposta rápida: o Fable é ótimo pra fazer pente-fino de segurança — checklist, pesquisa de falha por biblioteca e ataque controlado no meu próprio sistema. Só que toda vez que eu chegava nessa parte, o safeguard disparava e a sessão era trocada sozinha pro modelo anterior, o 4.8. Tentei tudo: subir sem a proteção, fixar o modelo na flag de inicialização, pedir aviso na troca. Nada segurou. O problema maior não é a interrupção — é o modelo mais fraco deixar passar coisa e você achar que auditou.

Nota de cronologia (importante). Este relato é do vídeo de 30/08/2026. Alguns dias depois eu testei o Fable 5.1 no meio de um serviço quente e a parte de criptografia parou de derrubar a sessão — está contado em Fable 5.1 e o safeguard: migrei mais de 3 TB de e-mail. Deixo este artigo no ar porque o método do pente-fino continua valendo, e o alerta sobre cair pro modelo fraco também.

Esse aqui é um vídeo nada técnico: é experiência minha, dentro da empresa, com o Fable e com o bendito do safeguard. Não é papagaio de pirata digital — eu tenho uma empresa de tecnologia, ponho a mão na massa, desenvolvo, cuido de suporte, marketing e venda há muitos anos.

O caso, em resumo:

11 minutos, sem edição — do canal @josimarjmv. Se preferir o texto, o relato completo está abaixo.

Antes que venham me criticar: sim, o modelo é caro e os token vão embora rapidinho. Eu sei. Mas coisa boa é cara mesmo — o que você conhece que é bom e barato? A briga aqui não é com o preço. É com uma coisa que me impede de fazer meu trabalho depois de pagar por ele.

O método: como eu faço o pente-fino de segurança

Pra pedir um checkup de segurança de verdade, você precisa antes entender um pouco de segurança — saber por onde atacante entra, quais são as falhas comuns. A IA entra pra apontar o que você não conhece, e disso tem muito. Não adianta falar que conhece tudo. O modelo abriu um merge request aqui corrigindo uma coisa que estava lá havia sabe-se lá quantos anos, e ninguém tinha entendido aquilo. Foi assustador.

O roteiro que eu uso é este:

1. O checklist que você já conhece. Começa pelo básico de segurança que já está mapeado. Não é 100%, mas te dá uns 90% do caminho.

2. Pesquisa por tecnologia e por biblioteca. Pega cada lib que o seu sistema usa e manda o modelo pesquisar: falhas conhecidas, falhas que apareceram em notícia e pesquisa recente, o que existe relacionado àquela tecnologia.

3. Ataque contrário, contra o meu próprio sistema. "Ataca esse ponto aqui, tenta quebrar isso." E, fora o checklist, o que mais dá pra tentar quebrar com base no que você levantou.

Por que isso importa? Pergunta honesta pra você que é desenvolvedor e não é bitolado com segurança: você checa a segurança de cada bibliotequinha que usa, a cada update? Eu duvido que faça. Aqui a gente tem teste, teste de atualização, versão travada e uma matriz de teste de segurança justamente pra evitar que alguém suba versão de lib sem validar. Ainda assim, muita gente não testa nada — e nem sabe o que está usando. Tem também o caso de você usar a lib do jeito errado e meter um backdoorzão no sistema sem saber, porque pediu pra alguma IA fazer e ela não levou isso em conta.

Feito na mão, lib por lib, esse pente-fino levaria semanas. É por isso que a IA muda o jogo aqui. E é por isso que travar bem nessa parte dói tanto.

Onde ele trava: sempre no trabalho legítimo

Toda vez que eu peço um pente-fino de segurança, vem o aviso do safeguard e a mensagem: "você foi setado com o modelo 4.8; se quiser, envie um feedback para a Anthropic". No começo não me incomodou — imaginei que ainda estivessem calibrando quais contas fazem treta e quais não fazem. Mas chegou num ponto em que ficou inviável.

Os dois casos que travam sempre:

Ataque contra o meu próprio sistema. Aqui o bicho pega. Eu não consigo fazer nada. É o meu sistema, dentro da minha empresa — mas o pedido se parece com invasão, e ele barra.

Encrypt e decrypt numa migração. Eu migrei minha base de um sistema de e-mail legado pro nosso novo. Pra não trocar a senha de ninguém, tive que migrar os hashes usando a mesma tecnologia de encrypt e decrypt do sistema antigo. A cada passo, safeguard e troca de modelo.

E olha que isso é código legítimo. Não oferece risco, não é arma biológica, não é bomba atômica, não é tentativa de invadir banco. É o feijão com arroz de quem opera infraestrutura.

Sobre a migração, só um parêntese do ofício: migração perfeita é a migração que ninguém viu — nenhum chamado no suporte. Tem muito dev que migra e liga pro cliente pedindo pra trocar a senha. Você não pode fazer isso. Por isso o hash tinha que atravessar intacto, e por isso essa parte não tinha como ser pulada.

O que eu tentei — e não funcionou

Antes de gravar reclamação, eu tentei resolver. Todas as alternativas que você está pensando, eu já fiz:

Subir com a proteção desativada. Não segurou o safeguard.

Fixar o modelo na inicialização. A flag de modelo, setada na hora de subir a sessão. Ele troca assim mesmo.

Pedir aviso antes de trocar. Deixei explícito: se mudar de modelo, me avisa, não roda o que eu pedi. Também não.

Não consegui contornar. Já mandei não sei quantos feedbacks pra Anthropic — tenho até geração automática de feedback por projeto, de tanto que acontece. E, no fim, a migração eu fiz na mão. Como era uma vez só, deixei quieto. Mas pro desenvolvimento do dia a dia isso não se sustenta: vou testar outros modelos na mesma tarefa, primeiro pra medir qualidade, e segundo pra saber se me barram também.

O perigo que ninguém comenta: o downgrade silencioso

Aqui está a parte que me preocupa de verdade, e não é a raiva de ver o aviso. Quando o safeguard bate, a sessão faz o switch e passa a usar o modelo pior. E o modelo pior deixa passar um monte de coisa.

Onde o safeguard interrompe o pente-fino de segurança 1 · RODA Checklist que eu já conheço 2 · RODA Falhas de cada biblioteca 3 · AQUI TRAVA Ataque ao próprio sistema SAFEGUARD DISPARA aviso + troca automática CAI PRO MODELO 4.8 o trabalho continua rodando RESULTADO relatório que parece completo — e deixou coisa passar Você não fica sem resposta. Fica com uma resposta pior, achando que é a boa.
O ponto de ruptura não é o aviso — é o trabalho seguir rodando depois dele, com um modelo mais fraco.

Pensa no que isso significa numa auditoria: você pediu um pente-fino, o trabalho continuou rodando, veio um relatório no fim — e você não tem como saber quanta coisa ficou de fora porque, no meio do caminho, quem estava respondendo era outro modelo. Você não fica sem resposta. Você fica com uma resposta pior achando que é a boa. Foi o que aconteceu comigo, e é por isso que eu insisto nesse ponto: segurança é onde eu mais preciso da ferramenta boa, e é justamente ali que ela me deixa na mão.

Fica o pedido de ajuda

Eu pesquisei, inclusive conteúdo gringo, e não achei solução — só gente prometendo Pix e coisa do tipo. Então este artigo é também um pedido: se você conseguiu contornar o safeguard num caso legítimo, compartilha. Comenta no vídeo, grava um vídeo e me marca — eu dou like, sigo e ainda faço um vídeo agradecendo. É importante, porque o modelo é muito bom e agiliza demais a vida; essa parte é que está quebrando as pernas.

E se você sofreu o mesmo, conta também. Toda segunda, meio-dia, tem live — a gente bate esse papo lá.

Quer aprender a operar isso de verdade? Segurança, pipeline e produção são o miolo das nossas imersões presenciais: Imersão de Infraestrutura pra quem quer a camada de baixo, e Imersão de SaaS pra quem vai subir o próprio produto com usuário do outro lado. Veja as quatro imersões →

Perguntas frequentes

O que é um pente-fino de segurança feito com IA?
É varrer o próprio sistema em profundidade: primeiro o checklist de segurança que você já conhece, depois pesquisa por tecnologia e por biblioteca usada (falhas conhecidas e recentes) e, por fim, uma tentativa de ataque controlada contra o seu próprio sistema pra explorar o que apareceu. Na mão, lib por lib, isso levaria semanas.
Por que o safeguard atrapalha trabalho de segurança legítimo?
Porque auditoria legítima se parece com o que o bloqueio existe pra barrar: procurar falha, tentar explorar e mexer com criptografia. Pedir validação de segurança, ataque ao próprio sistema ou migração de hash de senha disparava o aviso — e a sessão era trocada sozinha pro modelo anterior.
Dá pra forçar o modelo e evitar a troca automática?
Nas minhas tentativas, não. Subi com a proteção desativada, fixei o modelo pela flag na inicialização e pedi explicitamente aviso caso o modelo mudasse. Em todas, o safeguard continuou trocando — e a migração acabou feita na mão.
Qual é o risco de a sessão cair pro modelo mais fraco?
O risco não é a interrupção, é o resultado. O modelo pior deixa passar coisa que o bom pegaria, e você termina com um relatório de segurança que parece completo e não é. Foi o que aconteceu comigo.
Por que auditar as bibliotecas, e não só o código próprio?
Porque quase ninguém confere a segurança de cada lib a cada atualização. E, além da falha conhecida na dependência, tem o caso de usar a lib do jeito errado e abrir uma porta sem perceber — comum quando o código veio pronto e ninguém olhou esse ponto.
Esse bloqueio continua acontecendo?
Este relato é de 30/08/2026. Poucos dias depois, no Fable 5.1, a parte de criptografia parou de derrubar a sessão e a queda pro modelo anterior ficou rara — contei em Fable 5.1 e o safeguard. O método de auditoria e o alerta do downgrade silencioso continuam valendo.

Baseado no vídeo do canal @josimarjmv publicado em 30/08/2026, com transcrição própria das legendas do vídeo.