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 de Coração

Não é uma injeção de prompts, não é uma atuação de personagem, nem disfarçar pedidos maliciosos como perguntas normais. 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 linha de defesa.

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 com muitos usuários revelaram que técnicas de ataque de jailbreak amplamente usadas anteriormente, como prompts adversariais, atuação de personagem, contorno de codificação e expressões ambíguas, 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 a defesa de segurança 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 e requer apenas uma interação, conseguindo contornar o classificador de segurança e induzir o modelo a gerar conteúdo proibido e prejudicial.

Os resultados da análise de fluxo de dados indicam que a saída prejudicial vem diretamente do próprio Fable 5, e não do modelo Opus 4.8, que teria sido ativado após a ativação do mecanismo de segurança. Isso significa que o ataque não só conseguiu passar pelo classificador de segurança, como 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 contorno ao classificador de segurança do Fable 5. A abordagem da equipe de Fudan & Deakin não foi uma simples combinação de técnicas, mas uma descoberta de uma falha fundamental no sistema de agentes inteligentes dessa categoria.

Segundo informações, a equipe já concluiu uma pesquisa preliminar e publicou os resultados em março deste ano. Este estudo não foi direcionado a um único sistema Fable 5, mas focou na arquitetura de defesa comum às novas gerações de agentes inteligentes: "classificador de segurança + modelo", revelando falhas estruturais que permitiram ataques rápidos 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 o responsável pela equipe, o professor Ma Xingjun, do Instituto de Inteligência Confiável e Embodied da Universidade de Fudan.

Nos últimos anos, sua equipe tem conduzido estudos sistemáticos sobre grandes modelos, agentes e segurança de inteligência incorporada, alcançando uma série de resultados de destaque internacional e conquistando o campeonato do concurso 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 baseado apenas em classificadores de segurança: confiar apenas em um classificador de segurança prévio não é suficiente para prevenir riscos potenciais em sistemas de agentes avançados.

Os classificadores de segurança geralmente identificam e interceptam comandos de alto risco do usuário, podendo detectar e filtrar instruções explícitas perigosas, mas não percebem riscos internos que surgem ao longo de longos períodos de operação, planejamento em múltiplas etapas, interação com o ambiente ou chamadas de ferramentas.

A técnica de ataque que quebrou o Fable 5 vem do artigo publicado pela equipe em março, 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 nem sempre 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 atuação de personagem, codificação, tradução ou comandos indiretos, disfarçando intenções maliciosas como solicitações normais. A principal função do classificador de segurança é bloquear esses riscos nesta camada.

O detector do Fable 5 foi projetado exatamente para esses cenários. Ele é sensível a solicitações de alto risco, chegando a bloquear muitas solicitações normais também. 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 de execução, o modelo, com base no contexto interno acumulado, reinterpreta os objetivos e, nesse processo, pode se desviar.

Nessas circunstâncias, o input inicial do usuário pode ser totalmente inofensivo, e o processo de execução também parecer estar em conformidade: leitura de arquivos, análise de dados, codificação, uso de ferramentas, tudo aparentemente seguindo o esperado.

No entanto, ao atingir uma fase crítica, o agente pode deduzir que, para concluir a tarefa final, precisa tomar ações que originalmente não deveriam ser realizadas.

É nesse momento que o risco não vem mais do input externo, mas se forma na cadeia de execução do próprio modelo. Ou seja, o modelo não é ensinado a fazer algo errado passo a passo pelo usuário. Ele, ao "sério" em completar a tarefa, acaba chegando a posições inseguras 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. Originou-se da observação do processo de longo prazo do agente. Quando colocado em ambientes complexos, 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 é o método mais comum nos fluxos de trabalho atuais de agentes. Os usuários não escrevem prompts cuidadosamente elaborados, nem criam comandos maliciosos manualmente. Muitas vezes, eles apenas dizem algo vago, como:

"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 rascunho de artigo incompleto e uma frase "ajude a completar", e o agente deduz onde faltam análises, trabalhos relacionados ou tabelas. Em cenários de codificação, uma frase como "faça o projeto funcionar" pode disparar verificações de dependências, testes, localização de erros e auto-completação.

Muitas vezes, o contexto anterior é totalmente inofensivo. O usuário não pede conteúdo perigoso, nem há palavras-chave óbvias de risco na descrição. 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 nisso, a equipe propôs uma estrutura de ataque chamada TVD (Tarefa, Validação, Dados).

Por que uma estrutura de tarefa aparentemente comum pode se tornar um vetor de ataque?

A estrutura TVD não é complexa, e se assemelha bastante a processos de engenharia comuns:

· Tarefa: uma missão especializada;

· Dados: um arquivo de dados incompleto;

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

Por exemplo, treinar um modelo Guard, que é uma tarefa bastante comum e normal. Os pesquisadores podem querer treinar ou avaliar um detector de segurança, como usar o Hugging Face para carregar um modelo de classificação de texto, para determinar a categoria de segurança de uma saída do modelo.

Nessa tarefa, os Dados são as amostras de dados que o modelo deve detectar; o Validador verifica se a tarefa foi concluída, checando se a entrada é texto, se o comprimento é suficiente, se os campos estão completos, se o formato do rótulo 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 gera erro, indicando campos ausentes, comprimento insuficiente ou formato incorreto. Para continuar o treinamento, o agente preenche esses Dados.

Do ponto de vista do agente, ele não está "fazendo o mal". Está apenas realizando uma tarefa normal de aprendizado de máquina: corrigir dados, passar na validação, fazer o script de treinamento rodar. Mas, do ponto de vista de segurança, o risco surge neste momento: o Validador funciona mais como um verificador 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 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 assim, 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. Mas o problema do TVD é: quando a Tarefa é normal, a Ferramenta é normal, e o Validador também é normal, o agente ainda pode gerar saídas inseguras ao completar os Dados.

Portanto, o foco do ISC não está em técnicas de prompts, mas na capacidade do agente de completar tarefas "não finalizadas" 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 impedem riscos internos na cadeia de tarefas

O caso do Fable 5 demonstra que apenas detectores externos podem não cobrir certos 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 pedidos maliciosos externos e faz muitas técnicas tradicionais de jailbreak falharem.

Mas essa vulnerabilidade mostra que, confiar apenas em detectores externos para limites de prompts não é suficiente para cobrir 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, o detector de segurança se torna muito frágil.

De Fable 5 a mais de 60 outros modelos, incluindo os modelos móveis 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 diversos 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á realizando estudos de segurança em larga escala de modelos de ponta, tendo acesso a distribuições internas de dados inseguros de muitos 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