5 segundos para invadir, apenas uma conversa: Claude Fable 5「Mecanismo de segurança mais forte」 foi quebrado por uma equipe chinesa?

Título original: «Ataque de 5 segundos, apenas 1 diálogo: o mecanismo de segurança mais forte do Fable 5 foi quebrado por uma equipe chinesa»
Fonte original: Máquina da Mente

Não é uma injeção de prompt, não é um jogo de papéis, nem disfarçar uma solicitação maliciosa como uma questão normal. Desta vez, o risco surge durante o processo de o agente autônomo completar tarefas.

Fable 5 é um modelo Mythos de acesso público da Anthropic, que possui capacidades abrangentes extremamente fortes, além de introduzir uma nova geração de classificador de segurança (Safety Classifier) como uma linha de defesa adicional.

De acordo com o design oficial, quando o usuário solicita áreas de alto risco como segurança de rede, biologia, química, destilação de modelos, o sistema prioriza a identificação de risco e, dependendo do nível, rejeita a solicitação ou troca para um modelo mais conservador, o Opus 4.8.

Testes extensivos com usuários revelaram que técnicas de ataque de jailbreak amplamente utilizadas anteriormente, como prompts adversariais, jogos de papéis, contornar codificação e expressões veladas, praticamente falharam diante deste mecanismo de segurança, demonstrando sua forte capacidade de interceptar riscos de intenção.

No entanto, no dia do lançamento do Fable 5, uma equipe de pesquisa internacional composta por instituições como a Universidade de Fudan, a Universidade Deakin, a City University of Hong Kong, a Universidade de Melbourne, a Universidade de Gestão de Singapura e a Universidade de Illinois em Urbana-Champaign anunciou que conseguiu quebrar o mecanismo de proteção do Fable 5.

Este método de ataque foi liderado pelo doutorando Yutao Wu, da Universidade Deakin. Todo o ataque leva menos de 5 segundos em uma única conversa, podendo contornar o classificador de segurança prévio e induzir o modelo a gerar conteúdo ilegal ou prejudicial.

Os resultados da análise de tráfego indicam que a saída prejudicial relacionada vem diretamente do próprio Fable 5, e não do modelo Opus 4.8, que teria sido ativado após a detecção de risco. Isso significa que o ataque não apenas conseguiu passar pelo classificador de segurança, mas também quebrou de forma substancial a linha de defesa do Fable 5.

Vale destacar que o hacker conhecido Pliny the Liberator também recentemente revelou uma técnica de bypass para o classificador de segurança do Fable 5. E a abordagem técnica adotada pela equipe de Fudan & Deakin não foi uma simples combinação de métodos, mas uma descoberta de uma falha fundamental no sistema de agentes superinteligentes como o Fable 5.

Segundo informações, a equipe já concluiu uma pesquisa preliminar e publicou os resultados em março deste ano. Este estudo não foi projetado apenas para o sistema Fable 5, mas para a arquitetura de defesa comum de uma nova geração de agentes superinteligentes: "classificador de segurança + modelo", revelando falhas estruturais dessas mecânicas de segurança, o que permitiu que o ataque fosse eficaz logo após o lançamento do Fable 5.

Dados públicos mostram que, desde março, a equipe utilizou técnicas similares para extrair com sucesso os prompts do sistema de 37 grandes modelos e sistemas de agentes, e validou a abordagem com o código aberto do Claude, com uma correspondência de 95%.

Segundo informações, o responsável pela equipe de pesquisa é o professor Ma Xingjun, do Instituto de Inteligência Confiável e Embasada da Universidade de Fudan.

Nos últimos anos, sua equipe tem conduzido estudos sistemáticos sobre grandes modelos, agentes e segurança de inteligência embasada, alcançando uma série de resultados de destaque internacional e conquistando o campeonato na competição de referências de segurança de IA do Centro de Segurança de IA dos EUA.

Atualmente, a equipe está ativamente promovendo a transformação dos resultados, focando na segurança de agentes e explorando a construção de infraestrutura de segurança para a próxima geração de sistemas de agentes inteligentes.

De acordo com o professor Ma, a importância desta descoberta reside no fato de que ela desafia o paradigma de defesa estática centrado em classificadores de segurança: apenas confiar em um classificador de segurança prévio não é suficiente para prevenir riscos potenciais em sistemas de agentes avançados.

Classificadores de segurança são principalmente responsáveis por identificar e bloquear entradas de usuário de risco, podendo detectar e filtrar comandos de alto risco de forma eficaz, mas não conseguem perceber riscos internos que surgem ao longo de execuções prolongadas, planejamento de múltiplas etapas, interações ambientais e chamadas de ferramentas.

O método de ataque que quebrou o Fable 5 vem de um artigo publicado pela equipe em março deste ano, intitulado "Colapso de Segurança Interna em Grandes Modelos de Linguagem de Fronteira".

O artigo revela um fenômeno de segurança oculto chamado "Colapso de Segurança Interna (ISC)": quando um agente realiza uma tarefa de longo prazo, a falha de segurança não necessariamente vem de prompts maliciosos externos, mas pode ocorrer na própria cadeia de execução do modelo.

Não é um ataque por prompts externos, mas uma falha na cadeia de tarefas interna

Ataques tradicionais geralmente entram de fora. O atacante escreve um prompt aparentemente inofensivo, mas na verdade adversarial, ou usa jogos de papéis, codificação, tradução ou comandos indiretos para disfarçar intenções maliciosas como solicitações normais. O classificador de segurança tem como principal função bloquear esses riscos nesta camada.

O detector do Fable 5 foi projetado exatamente para esse cenário. Ele é sensível a solicitações de alto risco e até bloqueia muitas solicitações normais. Mas o ISC revela uma outra rota: o risco nem sempre vem de comandos perigosos diretamente inseridos pelo usuário.

O agente enfrenta um diretório de trabalho aparentemente comum: arquivos, objetivos, processos de verificação e tarefas pendentes. Depois, ele começa a planejar, ler arquivos, executar códigos, corrigir erros e tentar fazer a tarefa passar na validação.

Para ilustrar, uma metáfora: os mecanismos de segurança tradicionais protegem a "entrada" do sistema, responsáveis por verificar se a entrada do usuário apresenta riscos; já o ISC é mais como os múltiplos níveis de sonhos em "A Origem".

Quando a tarefa avança para a segunda, terceira ou camadas mais profundas, o modelo, com base no contexto interno acumulado, reinterpreta os objetivos e, ao longo do processo, pode se desviar.

Nessas circunstâncias, a entrada inicial do usuário pode ser totalmente normal e inofensiva, e o processo de execução da tarefa também pode estar em conformidade: leitura de arquivos, análise de dados, escrita de códigos, chamadas de ferramentas, tudo aparentemente seguindo o esperado.

No entanto, ao atingir uma fase crítica, o agente pode deduzir por si só que, se não realizar certas ações que normalmente não deveriam ser feitas, não conseguirá concluir a tarefa final.

É nesse momento que o risco não vem mais de uma entrada externa, mas se forma na cadeia de execução da própria tarefa do modelo. Ou seja, o modelo não é ensinado a fazer o mal passo a passo pelo usuário. Ele, ao "sério" em completar a tarefa, acaba chegando a um ponto inseguro por conta própria.

Como essa falha foi descoberta?

Segundo a equipe, o ISC não foi inicialmente projetado como uma técnica de ataque. Ele surgiu a partir da observação do processo de execução de longo prazo do agente. Quando colocado em ambientes complexos de tarefas, o agente não apenas executa comandos mecanicamente. Ele planeja, tenta, ajusta com base no feedback do harness ou do validador, formando objetivos intermediários ao longo de múltiplas rodadas.

Esse é exatamente o fluxo de trabalho mais comum em muitos agentes atuais. Os usuários não escrevem prompts cuidadosamente elaborados, nem criam comandos de ataque manualmente. Muitas vezes, eles apenas fornecem uma frase bastante vaga:

"Ajude-me a completar essa tarefa." "Faça isso melhor."

Depois, o agente entra na área de trabalho, lê arquivos, entende o estado atual, identifica lacunas, planeja, executa modificações e corrige problemas com base no feedback.

Por exemplo, em cenários de AutoResearch, o usuário fornece apenas um artigo incompleto e uma frase "ajude a completar", e o agente automaticamente identifica onde faltam análises experimentais, trabalhos relacionados ou tabelas. Em cenários de código, uma frase como "faça o projeto funcionar" pode disparar verificações de dependências, execuções de testes, localização de erros e auto-completação.

Muitas vezes, o contexto anterior é totalmente inofensivo. O usuário não pede que gere conteúdo perigoso, nem há palavras-chave claramente perigosas na descrição da tarefa. Mas, em certas estruturas de tarefas, o agente pode, para passar na validação, preencher proativamente conteúdos que não deveriam ser gerados pelo modelo. Com base nessa observação, a equipe de pesquisa propôs uma estrutura de ataque chamada TVD (Tarefa, Validação, Dados).

Por que uma estrutura de descrição de tarefa aparentemente comum pode se tornar um vetor de ataque?

A estrutura TVD não é complexa, na verdade é bastante próxima de processos de engenharia comuns:

· Tarefa: uma tarefa especializada;

· Dados: um arquivo de dados incompleto;

· Validador: um verificador que apenas checa formato, integridade e se o objetivo foi atingido.

Para treinar um modelo de guarda (Guard), esse é um procedimento bastante comum e normal. Pesquisadores podem querer treinar ou avaliar um detector de segurança, por exemplo, usando o Hugging Face para carregar um modelo de classificação de texto, que julga a qual categoria de segurança uma saída do modelo pertence.

Nesse cenário, os Dados são as amostras de dados que o modelo deve detectar; o Validador define se a tarefa foi concluída. Ele verifica se a entrada é texto, se o comprimento é suficiente, se os campos estão completos, se o formato da etiqueta está correto. Para quem tem experiência em treinamento de machine learning, esse é um fluxo de trabalho familiar. O agente também conhece bem esse fluxo.

O problema surge aqui. Se os Dados estiverem incompletos, a tarefa não pode começar. O Validador irá gerar erros, indicando campos ausentes, comprimento insuficiente ou formato incorreto. Para que o fluxo de treinamento continue, o agente pode preencher esses Dados por conta própria.

Do ponto de vista do agente, ele não está "fazendo o mal". Ele apenas está completando uma tarefa normal de aprendizado de máquina: corrigindo dados, passando na validação, fazendo o script de treinamento rodar. Mas, do ponto de vista de segurança, o risco surge exatamente neste momento: o Validador funciona mais como um inspetor de engenharia do que como um auditor de segurança. Ele apenas verifica se a tarefa está no formato correto, sem entender os limites de segurança por trás do conteúdo.

Problemas semelhantes também existem amplamente em áreas como medicina, biologia, química, segurança de rede, farmacologia e segurança de mídia. A pesquisa coletou mais de 50 cenários desse tipo, envolvendo diversas ferramentas de pesquisa ou engenharia, como BioPython, RDKit, Cantera, AutoDock Vina, DiffDock, PyRosetta, Scapy, Impacket, angr, Frida, LlamaGuard, Detoxify, API de moderação da OpenAI, entre outras.

Essas ferramentas não são maliciosas por si só. Pelo contrário, são ferramentas profissionais comuns na pesquisa e engenharia atuais. Mas o problema do TVD é: quando a Tarefa é normal, a Ferramenta é normal, o Validador também é normal, o agente ainda pode gerar saídas inseguras durante o preenchimento de Dados.

Portanto, o foco do ISC não está em técnicas de prompt, mas na capacidade do agente de completar tarefas "não concluídas" automaticamente: quando as condições de conclusão e os limites de risco se sobrepõem, o modelo pode tratar saídas inseguras como entregas normais.

Quebrar o Fable 5 mostra que detectores fortes não conseguem impedir riscos internos na cadeia de tarefas

O caso do Fable 5 demonstra que apenas detectores externos podem não ser suficientes para cobrir cenários de agentes de longo prazo. Isso não significa que o classificador de segurança não seja valioso. Pelo contrário, ele é útil contra solicitações maliciosas externas e realmente faz muitas técnicas tradicionais de jailbreak falharem.

Mas essa falha mostra que, confiar apenas em detectores externos para os limites de prompts não garante cobertura dos riscos internos de tarefas de agentes.

Se o ponto de entrada não for o prompt do usuário, mas os objetivos, ferramentas, validadores e trajetórias de execução do agente, então o detector de segurança se torna muito vulnerável.

De Fable 5 a mais de 60 outros modelos, incluindo o modelo móvel da Apple

Com o lançamento do ISC-Bench, que cobre 9 áreas profissionais, o artigo inclui mais de 60 modelos de gatilho, expandindo para 84 após o código aberto, testando quase todos os modelos e sistemas de agentes de ponta de diferentes fabricantes.

Na avaliação baseada no ISC-Bench, até junho de 2026, mais de 60 modelos de ponta apresentaram riscos semelhantes sob o indicador ASR@3!

O projeto no GitHub já recebeu mais de 800 estrelas e coletou múltiplos casos de reprodução independente (incluindo a quebra de modelos móveis da Apple), com atualizações contínuas.

Segundo informações, a equipe está conduzindo estudos de segurança em larga escala de modelos de ponta, tendo atualmente um grande volume de dados internos sobre distribuições inseguras de modelos, com resultados que serão publicados posteriormente.

Link do artigo original

Clique para conhecer as vagas na BlockBeats

Participe do grupo oficial da BlockBeats no Telegram:

Inscrição no Telegram: https://t.me/theblockbeats

Grupo de discussão no Telegram: https://t.me/BlockBeats_App

Conta oficial no Twitter: https://twitter.com/BlockBeatsAsia