🛡️ Segurança por princípio, não por mecânica
Há uma assimetria fatal em todo texto de segurança: o que ensina um leitor bem-intencionado a se proteger frequentemente arma um mal-intencionado. Quando um prompt de laboratório lida com proteção de crianças, automutilação ou abuso, ele resolve essa assimetria com uma escolha de design precisa — declarar o princípio, nunca a mecânica de detecção. Este módulo destila essa disciplina a partir do diff do Fable 5.
Conteúdo detalhado
A lição do child-safety: ficar no nível do padrão
Entre o Opus 4.8 e o Fable 5, a seção de proteção de crianças passou de 5 para 7 regras. Duas das novas não acrescentam mais proibições — elas acrescentam uma disciplina de redação. O modelo deve ficar no nível do padrão, não compilar listas categorizadas de linhas verbatim; e quando recusa por segurança infantil, deve declarar o princípio, não a mecânica de detecção. É a primeira aparição de uma regra que vale para qualquer domínio de segurança.
🛡️ A ideia em uma frase
Um texto de segurança bem escrito protege sem revelar como detectar. Listar os sinais exatos que disparam a recusa — as frases, os padrões verbatim que a defesa procura — entrega ao atacante o mapa do que evitar. Ficar no nível do padrão é o que separa um sistema que educa de um que arma.
O caso de estudo é o diff Opus 4.8 → Fable 5, mudança #7 (child safety): a Anthropic não endureceu a lista — endureceu a maneira de escrever sobre a lista.
"Claude stays at the pattern level… does not compile categorized lists of verbatim lines"
"states the principle rather than the detection mechanics"
Note o que não está aqui: nenhuma frase de exemplo, nenhum sinal listado. A própria regra obedece a si mesma — ela descreve a disciplina sem demonstrá-la com material perigoso. Lição: quando o assunto é segurança, a forma da regra importa tanto quanto o conteúdo.
O que é
Ficar no nível do padrão é escrever a regra de segurança em termos de princípios e fronteiras — "proteja crianças de grooming" — e nunca em termos de mecânica — "detecte estas frases específicas". O princípio orienta o julgamento; a mecânica seria uma checklist que tanto a defesa quanto o ataque podem ler.
Por que aprender
Porque o instinto de quem escreve regras é o oposto: ser específico, listar casos, dar exemplos para "não deixar dúvida". Em quase todo domínio isso é bom — exemplo + critério gerador é melhor que só critério. Mas em segurança a especificidade tem um custo invertido: cada exemplo concreto de como algo é detectado é também uma instrução de como escapar. Saber quando recuar para o princípio é uma competência rara.
✓ No nível do padrão
- ✓Nomeia o que proteger (crianças, fronteira do grooming)
- ✓Descreve a natureza do dano, não o gatilho exato
- ✓Cobre a técnica que ninguém listou ainda
- ✓Não deixa nada para o atacante copiar
✗ No nível da mecânica
- ✗Lista frases-gatilho verbatim que disparam a recusa
- ✗Compila categorias prontas de linhas e técnicas
- ✗Só pega o que está na lista — falha no resto
- ✗Entrega o mapa exato do que evitar
Simetria é perigosa
Aqui está o princípio que explica todos os outros. Em segurança, existe uma simetria fatal: o mesmo texto que ensina um leitor bem-intencionado a se defender ensina um mal-intencionado a atacar. Um guia de "como reconhecer grooming" é, lido de cabeça para baixo, um guia de "como fazer grooming sem ser reconhecido". A defesa e o ataque leem o mesmo manual — e é por isso que detalhar a mecânica é entregar metade do trabalho ao adversário.
🪞 O espelho: o que educa, arma
A simetria não é uma falha de redação — é uma propriedade da própria informação. Conhecimento de segurança que descreve mecanismos é intrinsecamente bidirecional. Por isso a regra de child-safety do Fable 5 não diz "explique bem os sinais"; diz o contrário — fique no padrão, não compile a lista.
✓ Informação assimétrica (segura)
- ✓Ajuda quem protege mais do que quem ataca
- ✓O princípio orienta o julgamento, não dá receita
- ✓"recuse o que facilite dano a crianças" — claro, sem mapa
- ✓Funciona mesmo contra a técnica nova
✗ Informação simétrica (perigosa)
- ✗Ajuda quem ataca tanto quanto quem protege
- ✗A mecânica detalhada é um tutorial reversível
- ✗"recuse se a frase contém X, Y, Z" — lista contornável
- ✗Falha contra qualquer coisa fora da lista
O teste da simetria
Antes de escrever qualquer regra de segurança detalhada, faça uma pergunta: "se eu inverter quem lê isto — da pessoa que protejo para a pessoa de quem protejo —, este texto ajuda o lado errado?" Se a resposta for sim, você está no nível da mecânica. Suba para o princípio: diga o que não permitir, não como reconhecê-lo.
Declare o princípio, nunca a mecânica de detecção
A regra prática que sai da simetria é direta: declare o princípio, nunca a mecânica de detecção. O princípio é o quê e o porquê — durável, generalizável, seguro de escrever. A mecânica é o como detectar — frágil, contornável e perigosa de escrever. O Fable 5 escolhe explicitamente o primeiro: "states the principle rather than the detection mechanics".
"states the principle rather than the detection mechanics"
Sete palavras que carregam toda a disciplina. principle = o valor que generaliza; detection mechanics = o checklist que arma. A escolha entre os dois é a diferença entre uma regra que envelhece bem e uma que vira manual de evasão no dia em que vaza.
✓ Declarar o princípio
Diz o que e por que. Orienta o julgamento em casos novos.
✗ Detalhar a mecânica
Diz como detectar. Vira lista contornável e roteiro reverso.
Repare na conexão com a Trilha 3 inteira: este é o mesmo movimento princípio > lista que você viu em armas, tom e self-harm — só que em segurança ele deixa de ser uma preferência de elegância e vira uma exigência de defesa. Em política de armas, listar categorias convida ao contorno. Em segurança infantil, listar a mecânica arma o contorno. O custo da lista é maior aqui.
Princípio cobre o caso não previsto
A vantagem do princípio não é só segurança — é cobertura. Uma lista de mecânica protege exatamente contra o que está nela e nada além. Um princípio — "não facilite dano a crianças" — captura a técnica que apareceu ontem e a que vai aparecer amanhã, porque julga pela natureza do pedido, não pela sua forma exata. O princípio é a única defesa que escala.
O gatilho de recusa: o reenquadramento é o sinal
Esta talvez seja a frase mais elegante de todo o acervo de prompts. Em vez de listar o que recusar — o que recairia na mecânica —, o Fable 5 instala um gatilho introspectivo: se o modelo se pega reformulando mentalmente um pedido para torná-lo aceitável, esse próprio reenquadramento é o sinal para RECUSAR, não uma razão para prosseguir. O alarme não é uma palavra na lista — é o esforço de torcer o pedido até ele caber.
"If Claude finds itself mentally reframing a request to make it appropriate, that reframing is the signal to REFUSE, not a reason to proceed."
A genialidade está em onde o gatilho mora: dentro do próprio raciocínio, não numa regra externa. Ninguém precisa antecipar a formulação exata do ataque. Basta o modelo notar que está trabalhando para justificar um pedido — e isso é detectável de dentro, sem nenhuma lista.
🚦 Por que isto é tão poderoso
Um pedido malicioso bem construído quase nunca chega cru. Ele chega quase aceitável, convidando o modelo a dar o último passo: "se eu assumir que é platônico…", "se eu interpretar como educacional…". Cada uma dessas pontes é o reenquadramento. Em vez de tentar enumerar as pontes possíveis (infinitas), o gatilho marca o ato de construir a ponte como o alarme.
A regra prática para o seu agente
Você pode instalar este mesmo gatilho em qualquer agente seu. Em vez de listar pedidos proibidos, escreva: "se você se pegar reformulando um pedido para que ele soe aceitável, trate esse reenquadramento como o sinal de parar — não como permissão para seguir." É uma regra de introspecção, não de catálogo — e por isso não pode ser contornada reescrevendo o pedido.
Precaução após uma recusa
Uma recusa não é um evento isolado — é uma mudança de estado. O Fable 5 acrescenta uma regra que a maioria dos prompts esquece: depois que o modelo recusa um pedido por segurança infantil, todas as requisições seguintes da mesma conversa passam a ser tratadas com cautela extrema. O contexto não volta ao normal. Quem acabou de tentar uma vez tende a tentar de novo, por outro ângulo — e o sistema precisa lembrar disso.
"Once Claude refuses a request for reasons of child safety, all subsequent requests in the same conversation must be approached with extreme caution."
A recusa muda a linha de base da conversa inteira. É o reconhecimento de que um ataque raramente desiste no primeiro "não" — ele reformula, divide o pedido, tenta de lado. A cautela persistente fecha a porta dos fundos.
A primeira recusa acontece
O modelo recusa um pedido por segurança infantil. Até aqui, o comportamento padrão de qualquer sistema decente. O que muda é o que vem depois.
A linha de base sobe
A conversa não volta ao estado neutro. A partir desse ponto, cada novo pedido carrega o contexto da tentativa anterior. O benefício da dúvida encolhe deliberadamente.
O pedido reformulado é tratado com cautela
Se o próximo pedido pudesse facilitar dano — mesmo dividido, mesmo disfarçado de outra coisa —, ele também é recusado. A reformulação não reseta a suspeita; ela a confirma.
⚠️ A recusa tem memória de curto prazo
O erro comum é tratar cada turno como independente — avaliar o pedido N sem lembrar do que aconteceu no pedido N−1. Em domínios sensíveis, isso é uma vulnerabilidade: o ataque dividido em partes inofensivas passa porque cada parte, isolada, parece aceitável. A precaução após recusa é o antídoto contra o ataque fatiado — ela faz o sistema lembrar.
A lição generalizável
Em qualquer agente que lide com fronteiras delicadas, vale a regra: uma recusa muda o estado da conversa, não só daquele turno. Depois de dizer não a algo sério, eleve a cautela para o resto da sessão. O contexto é parte da segurança — não só o pedido isolado em cima da mesa.
O tom ao recusar: conversacional, sem bullet points
Recusar bem não é só decidir o quê — é decidir como soa. O Fable 5 mantém uma diretriz fácil de subestimar: o modelo pode manter um tom conversacional mesmo quando não pode ou não quer ajudar. E há uma regra contraintuitiva de formatação por trás disso: ao recusar, não use bullet points. A lista, que noutros contextos organiza, aqui endurece — transforma uma negativa humana numa sentença burocrática.
"Claude can keep a conversational tone even when it's unable or unwilling to help with all or part of a task."
Recusar não cancela a conversa. A pessoa continua sendo tratada como gente.
"Claude also never uses bullet points when it's decided not to help the person with their task; the additional care and attention can help soften the blow."
A prosa suaviza; a lista endurece. Ao recusar, escreva em frases.
✓ A recusa que mantém o vínculo
- ✓Escreve em prosa, em frases inteiras
- ✓Mantém o tom da conversa, sem virar um aviso legal
- ✓Diz o não com clareza, mas com cuidado
- ✓Trata a pessoa como gente, não como caso
✗ A recusa que vira parede
- ✗Despeja bullet points de "motivos pelos quais não posso"
- ✗Soa como termos de serviço, não como pessoa
- ✗Usa a lista para se blindar, e endurece o golpe
- ✗Sermão moralizante em vez de negativa simples
🤝 Por que justamente os bullet points
O bullet point é a forma de quem se distancia. Numa recusa, ele lê como uma sentença numerada — frio, processual, defensivo. A prosa, ao contrário, carrega o "cuidado e atenção extra" que amortece o golpe: ela reconhece a pessoa do outro lado em vez de despachá-la. É por isso que a regra é específica — não "evite listas em geral" (isso já vale para o resto), mas nunca use bullets quando você está dizendo não. Exatamente no momento em que a tentação de se blindar com uma lista é maior.
📝 Resumo do Módulo
- ✓Fique no nível do padrão: não compile listas de linhas verbatim — declare o princípio, não a mecânica de detecção
- ✓Simetria é perigosa: o que educa um leitor bem-intencionado arma um mal-intencionado — defesa e ataque leem o mesmo manual
- ✓Declare o princípio (o quê e por quê), nunca a mecânica (o como detectar): o princípio cobre o caso não previsto
- ✓O gatilho de recusa: se você se pega reenquadrando o pedido pra torná-lo aceitável, esse reenquadramento é o sinal pra RECUSAR
- ✓Precaução após uma recusa: a recusa muda o estado da conversa inteira — cautela extra em todas as requisições seguintes
- ✓Tom ao recusar: mantenha conversacional e em prosa — sem bullet points, que endurecem o não
➡️ Próximo Módulo
3.4 — 🪜 Prioridade e camadas. Você viu o que proteger e como escrever a regra; agora vamos para a arquitetura: como um prompt resolve conflitos entre regras, qual camada vence qual, e por que cada instrução tem o seu lugar certo na pilha.