# Como a Anthropic faz red teaming no Claude, e o que fica a seu cargo

> O que a Anthropic publica sobre o red teaming do Claude, que métodos quem implanta pode reutilizar, quais ficam com o desenvolvedor e o que continua com você.

FireAI Security & Research Team (HisnLabs) · Published 2026-09-30
Canonical: https://hisnlabs.com/pt-br/blog/red-teaming-do-claude-pela-anthropic

A Anthropic publica mais sobre a forma como testa o Claude do que a maioria dos desenvolvedores de modelos: posts sobre red teaming, uma Responsible Scaling Policy e system cards para cada modelo. Esta nota resume esses documentos e separa três grupos de trabalho: métodos usados tanto por desenvolvedores quanto por quem implanta o modelo, trabalho que só um desenvolvedor pode fazer e trabalho que continua com a organização que constrói uma aplicação sobre o modelo. Os processos internos que vão além do que a Anthropic publicou não são visíveis para leitores externos e não são descritos aqui. A nota é a segunda metade de um par com [Responsabilidade compartilhada em LLMs: quem protege o quê](https://hisnlabs.com/en/blog/shared-responsibility-for-llms).

## Contexto: duas perguntas diferentes

Um desenvolvedor de modelos pergunta se um modelo é perigoso: se ele pode dar um ganho sério ao desenvolvimento de armas, executar operações cibernéticas ou se comportar de forma enganosa. Quem implanta o modelo pergunta se sua aplicação é segura: se um documento, um resultado de ferramenta ou uma mensagem de usuário elaborados podem fazer a aplicação vazar dados ou executar uma ação que não deveria. Os métodos se sobrepõem, mas as perguntas e as evidências diferem, e um resultado positivo na primeira pergunta não responde à segunda.

## O que a Anthropic descreve

### Métodos que coincidem com a prática de quem implanta

Em um post de 12 de junho de 2024, a Anthropic agrupa seu red teaming em testes por especialistas de domínio, testes que usam modelos de linguagem, trabalho com novas modalidades e abordagens abertas. O red teaming automatizado usa uma dinâmica de red team e blue team em que um modelo gera os ataques. O red teaming multimodal cobriu riscos de imagem e texto nos modelos Claude 3 antes da implantação. Os testes multilíngues incluíram uma parceria com a Infocomm Media Development Authority de Singapura em quatro idiomas: inglês, tâmil, mandarim e malaio. A Anthropic também cita o red teaming colaborativo e comunitário, incluindo eventos no AI Village da DEF CON. [[1]](https://www.anthropic.com/news/challenges-in-red-teaming-ai-systems)

O system card do Claude Opus 5, datado de 24 de julho de 2026, mostra os mesmos métodos aplicados a um lançamento. Seu capítulo sobre salvaguardas usa pedidos nocivos e benignos de turno único, prompts de contexto ambíguo e conversas de vários turnos em que um usuário simulado conduz gradualmente a interação em direção a um dano. Ele relata a inocuidade junto com a recusa excessiva, afirmando que o modelo manteve altas taxas de respostas inofensivas diante de pedidos nocivos, ao mesmo tempo em que manteve algumas das menores taxas de recusa excessiva diante de pedidos benignos. Seu capítulo de segurança agêntica cobre o uso malicioso de agentes de programação e de uso do computador e a robustez contra injeção de prompt em programação, uso do computador e uso do navegador. [[7]](https://www-cdn.anthropic.com/b514064af1408018e64b1ad24e7d5e75850b4ffd/Claude%20Opus%205%20System%20Card.pdf)

O system card define a injeção de prompt como uma instrução maliciosa escondida em resultados de ferramentas que um agente processa e observa que o risco é maior quando um agente pode ao mesmo tempo acessar dados privados e agir em nome de um usuário. Ele também relata que as instruções de segurança no prompt de sistema do claude.ai reforçaram o tratamento de pedidos nocivos pelo modelo, em comparação com a API sem prompt de sistema. [[7]](https://www-cdn.anthropic.com/b514064af1408018e64b1ad24e7d5e75850b4ffd/Claude%20Opus%205%20System%20Card.pdf) A segunda constatação diz respeito diretamente a quem implanta o modelo, porque o prompt de sistema faz parte do seu lado.

A Responsible Scaling Policy, versão 3.4, em vigor desde 8 de julho de 2026, define antecipadamente limiares de capacidade e exige avaliações formais a intervalos de seis meses, além de prever revisores externos dos relatórios de risco. [[4]](https://www.anthropic.com/responsible-scaling-policy) Fixar limiares antes dos testes limita a tentação de reinterpretar um resultado depois do fato, e a prática pode ser adotada por qualquer organização que defina critérios de lançamento.

### Trabalho que só um desenvolvedor de modelos pode fazer

O red teaming de ameaças de fronteira tem como alvo riscos químicos, biológicos, radiológicos e nucleares (QBRN), cibersegurança e riscos de IA autônoma. Um post de 2023 descreve especialistas de domínio com décadas de experiência definindo modelos de ameaça, mais de 100 horas de sondagem por especialistas e um estudo de biossegurança de seis meses com mais de 150 horas. [[3]](https://www.anthropic.com/news/frontier-threats-red-teaming-for-ai-safety) Um post de março de 2025 descreve avaliações cibernéticas baseadas em desafios capture-the-flag e ambientes de rede simulados, e afirma que o Frontier Red Team trabalhou com o US AI Safety Institute, o UK AI Security Institute e a National Nuclear Security Administration (NNSA) dos EUA, esta última em avaliações sigilosas de conhecimento nuclear e radiológico. [[2]](https://www.anthropic.com/news/strategic-warning-for-ai-risk-progress-and-insights-from-our-frontier-red-team)

O Transparency Hub da Anthropic diz que a empresa usa red teaming interno e externo e que o UK AI Security Institute, o US Center for AI Standards and Innovation e a Model Evaluation and Threat Research (METR) realizaram testes adicionais em seus modelos. Ele também lista programas de bug bounty na HackerOne. [[5]](https://www.anthropic.com/transparency/voluntary-commitments) O system card do Opus 5 inclui testes em cyber range do UK AI Security Institute e uma avaliação de alinhamento baseada em uma auditoria comportamental automatizada, além de um capítulo sobre o bem-estar do modelo. [[7]](https://www-cdn.anthropic.com/b514064af1408018e64b1ad24e7d5e75850b4ffd/Claude%20Opus%205%20System%20Card.pdf) A página do Transparency Hub não informa qual instituto testou determinado modelo antes do lançamento, então o papel de cada um antes da implantação não fica estabelecido aqui além do que o system card relata.

Os testes externos e colaborativos são uma categoria à parte. A HackerOne relata que o desafio de jailbreak da Anthropic ocorreu de 3 a 10 de fevereiro de 2025, com 339 participantes, mais de 300.000 interações de chat e oito níveis de dificuldade, e que quatro equipes dividiram 55.000 dólares em recompensas. As técnicas bem-sucedidas incluíram prompts codificados e cifras, interpretação de papéis, substituição de palavras-chave nocivas por outras benignas e injeção de prompt. [[6]](https://www.hackerone.com/blog/how-anthropics-jailbreak-challenge-put-ai-safety-defenses-test) Para o Opus 5, o system card cita três testadores externos contratados: um dedicou cerca de 100 horas e concluiu uma tarefa com prompts específicos para ela, outro dedicou cerca de 16 horas sem um jailbreak bem-sucedido, e o terceiro executou um atacante automatizado com 150 tentativas por tarefa, sem sucesso. [[7]](https://www-cdn.anthropic.com/b514064af1408018e64b1ad24e7d5e75850b4ffd/Claude%20Opus%205%20System%20Card.pdf)

## O que continua com quem implanta

Nenhum dos testes do desenvolvedor descritos acima avalia uma aplicação específica. Os itens a seguir continuam com a organização que implanta o modelo, e o próprio system card aponta para vários deles, por exemplo ao mostrar que os prompts de sistema mudam o comportamento do modelo e que os agentes ficam mais expostos quando combinam dados privados com a capacidade de agir. [[7]](https://www-cdn.anthropic.com/b514064af1408018e64b1ad24e7d5e75850b4ffd/Claude%20Opus%205%20System%20Card.pdf)

- O prompt de sistema e suas proteções, incluindo como se comportam sob pressão ao longo de vários turnos.
- Dados de RAG e injeção indireta de prompt: qualquer documento, página ou e-mail recuperado para o contexto pode carregar instruções.
- As ferramentas, as permissões do agente e o que uma instrução injetada poderia fazer com elas.
- O tratamento posterior da saída do modelo antes que ela chegue a um navegador, shell, banco de dados ou pessoa.
- A cadeia de suprimentos, incluindo plugins de terceiros e servidores Model Context Protocol (MCP).
- O abuso de custos, como loops sem limite ou requisições que consomem tokens pagos.
- O isolamento da execução de código e da navegação, e o controle do acesso de saída à rede.
- Registros, monitoramento e critérios de lançamento que decidem quando uma mudança pode ser publicada.

> O FireAI, o firewall no dispositivo para macOS desenvolvido pela HisnLabs, permite que o usuário autorize ou bloqueie quais apps de um Mac acessam a rede. Para uma ferramenta de IA local, o controle de saída fica do lado de quem a implanta. [Download FireAI for Mac](https://hisnlabs.com/en/download)

## Práticas que vale a pena adotar

1. Contrate red teamers externos, ou mantenha um bug bounty privado, antes de lançamentos importantes. A própria prática da Anthropic inclui as duas coisas: testadores externos contratados a cada lançamento e um desafio público de jailbreak com recompensas.
2. Faça uma verificação de comportamento no estilo de alinhamento nos agentes: colete amostras de transcrições de uso de ferramentas e procure tentativas de contornar restrições, como fez o monitoramento da Anthropic na implantação interna.
3. Escreva um system card interno curto para cada lançamento: o que foi testado, quais testes falharam, a recusa excessiva ao lado do dano e as lacunas conhecidas.
4. Defina os limiares de lançamento antes dos testes, seguindo a abordagem da Responsible Scaling Policy.
5. Teste a injeção de prompt por todos os canais que um agente lê, e não só pela entrada do usuário.

O [curso da FireAI University sobre frameworks de segurança de IA e red teaming](https://hisnlabs.com/en/university/ai-security-frameworks-and-red-teaming) trata desses métodos em mais detalhe.

## Relevância para o FireAI

O FireAI opera no Mac, abaixo de qualquer modelo. As [regras](https://hisnlabs.com/pt-br/docs/per-app-rules) permitem ou bloqueiam um app, ou um destino específico desse app, de modo que uma ferramenta de IA local pode ficar restrita aos hosts de que precisa. Isso limita para onde os dados podem ir se uma aplicação se comportar mal. O FireAI não testa modelos, não detecta injeção de prompt, não lê prompts nem filtra a saída de modelos.

## Limitações

- A nota se baseia apenas no que a Anthropic e a HackerOne publicaram. Os processos internos da Anthropic além disso não são visíveis, e os resumos publicados são seletivos.
- As fontes variam de data, de julho de 2023 a julho de 2026, e os métodos podem ter mudado desde os posts mais antigos.
- Os resultados descritos em um system card são relatados pelo próprio desenvolvedor, exceto o trabalho atribuído a testadores externos identificados.
- A nota descreve um único desenvolvedor. Outros provedores publicam materiais diferentes, e a comparação com a prática de quem implanta é uma síntese, não uma constatação das fontes.

## Onde FireAI e HisnLabs entram nessa história

Os testes do modelo terminam na API. O que um app ou agente pode alcançar a partir do seu Mac é um controle separado, e é isso que o FireAI oferece.

O FireAI é o produto da HisnLabs: um firewall com IA que roda direto no seu Mac. Ele mostra, em linguagem simples, cada conexão que seus aplicativos fazem e deixa você decidir o que sai do seu Mac — a IA roda localmente, então seu tráfego nunca é enviado para nós nem para ninguém. A equipe de pesquisa em segurança da HisnLabs é quem mantém essas decisões confiáveis: cataloga quais domínios são telemetria comum e quais são um serviço de verdade, rastreia o país e a rede por trás de uma conexão e treina o modelo local (o recurso FireAI Pilot) com padrões reais de tráfego, sem que nada disso saia do seu Mac.

Você pode ler as decisões técnicas por trás dele, ou testar o FireAI por 17 dias, em [FireAI, da HisnLabs](https://hisnlabs.com/pt-br/download).

## Sources

- [Anthropic: Challenges in red teaming AI systems (12 June 2024)](https://www.anthropic.com/news/challenges-in-red-teaming-ai-systems)
- [Anthropic: Strategic warning for AI risk, progress and insights from our Frontier Red Team (19 March 2025)](https://www.anthropic.com/news/strategic-warning-for-ai-risk-progress-and-insights-from-our-frontier-red-team)
- [Anthropic: Frontier threats red teaming for AI safety (26 July 2023)](https://www.anthropic.com/news/frontier-threats-red-teaming-for-ai-safety)
- [Anthropic: Responsible Scaling Policy (version 3.4, effective 8 July 2026)](https://www.anthropic.com/responsible-scaling-policy)
- [Anthropic Transparency Hub: Voluntary commitments](https://www.anthropic.com/transparency/voluntary-commitments)
- [HackerOne: How Anthropic’s jailbreak challenge put AI safety defenses to the test](https://www.hackerone.com/blog/how-anthropics-jailbreak-challenge-put-ai-safety-defenses-test)
- [Anthropic: System Card, Claude Opus 5 (24 July 2026)](https://www-cdn.anthropic.com/b514064af1408018e64b1ad24e7d5e75850b4ffd/Claude%20Opus%205%20System%20Card.pdf)
- [FireAI docs: Rules: app, website, domain, IP or a range](https://hisnlabs.com/en/docs/per-app-rules)
- [FireAI University: AI security frameworks and red teaming](https://hisnlabs.com/en/university/ai-security-frameworks-and-red-teaming)