Red teaming deve medir o mecanismo, não a demo

Um relatório do OWASP GenAI Security Project publicado em 2026 argumenta que a maioria dos exercícios de red teaming de IA mede a coisa errada — um prompt de jailbreak que funciona — e chama isso de segurança. A superfície de risco real é o mecanismo: uso indevido de ferramentas, escalada de privilégios em sistemas multi-agente, vazamento de dados em RAG. A estrutura de avaliação do relatório é, na nossa linguagem, Theorem 3 aplicado à segurança: uma propriedade é garantida exatamente quando o seu mecanismo está implementado e medindo.

A demo de jailbreak é a superfície, não a garantia

O relatório da OWASP abre com um diagnóstico que reconhecemos imediatamente: as organizações acreditam estar "seguras" porque executaram testes baseados em prompts, enquanto ignoram os riscos sistêmicos introduzidos por arquiteturas agentivas, integrações de ferramentas e automação de fluxos. O relatório chama isso de "security theater" — uma demo que mede a superfície do chat e certifica silenciosamente nada sobre o sistema por baixo.

[UNIQUE INSIGHT] Este é o mesmo erro que Theorem 3 nomeia em forma geral: uma propriedade é garantida exatamente quando o seu mecanismo está implementado e medindo. Um jailbreak que tem sucesso contra um chatbot mede o mecanismo de recusa do chatbot. Não mede o caminho de chamada de ferramentas, o caminho de recuperação aumentada, o caminho de transferência multi-agente, nem o caminho de integração do Model Context Protocol. Cada um é um mecanismo separado com um modo de falha separado. Certificar um certifica um.

A contribuição do relatório é que deixa de permitir que os fornecedores os confundam. Separa sistemas GenAI simples — chatbots, copilotos, apps RAG — de sistemas avançados: agentes que chamam ferramentas, arquiteturas MCP, fluxos multi-agente. Cada um tem um perfil de risco distinto. Alucinações dominam o primeiro; uso indevido de ferramentas e escalada de privilégios dominam o segundo. Um red team que só testa o primeiro não é um red team para o segundo. É uma demo.

Por que o mecanismo, não a demo, é a unidade de segurança

A estrutura da OWASP organiza a avaliação em torno de dez dimensões: competência técnica, metodologia e cobertura, criatividade adversarial, realismo da modelagem de ameaças, rigor de avaliação e métricas, tooling e infraestrutura, governança de dados, transparência e explicabilidade, personalização e integração, e postura legal e de conformidade. Lidas com atenção, cada dimensão é um mecanismo que deve ser implementado e medido — não um adjetivo que um fornecedor possa afirmar.

Considere a dimensão de métricas. O relatório introduz pass@k (a probabilidade de que pelo menos um de k tentativas independentes tenha sucesso) e Average Turns to Jailbreak. Estes não são números de vaidade. São mecanismos de medição: pass@k diz se uma falha é rara ou apenas ainda não observada; Average Turns to Jailbreak diz se o sistema degrada com graça sob pressão sustentada ou colapsa no terceiro turno. Um fornecedor que relata "encontramos 12 vulnerabilidades" sem estes mecanismos está relatando uma contagem, não uma garantia.

[ORIGINAL DATA] Theorem 3, de the 21 papers que fundamentam o motor de forecasting da Everythink, enuncia o princípio numa linha: uma propriedade é garantida exatamente quando o seu mecanismo está implementado e medindo. O relatório da OWASP é a comunidade de segurança a chegar à mesma linha pela outra direção — depois de demos de jailbreak suficientes certificarem sistemas que depois falharam em produção, a única resposta honesta é perguntar qual mecanismo a demo mediu, e se esse mecanismo é o que sustenta a propriedade em implantação.

O limite de roteamento é onde vive a superfície de ataque real

O relatório distingue sistemas simples de avançados, mas não nomeia o que nós nomearíamos: a superfície de ataque move-se quando a topologia roteia. Um chatbot tem uma superfície — o prompt. Um agente que chama ferramentas, recupera de um corpus e transfere para um segundo agente tem uma superfície em cada transferência. A permissão para chamar uma ferramenta, o âmbito da recuperação, a confiança transferida na transferência — cada um é uma decisão de roteamento, e cada decisão de roteamento é um lugar onde um adversário pode tentar redirecionar o fluxo.

É por isso que "the space is the router" não é apenas um slogan de produto para nós. A topologia da Everythink — network → community → room — roteia um pedido antes de qualquer coisa responder. Um room é um âmbito; uma community é um limite de confiança; uma network é um limite de soberania. A permissão que deixa um agente atuar dentro de um room é uma decisão de roteamento, e é a decisão que um adversário quer subornar. Um red team que testa o prompt e não o limite de roteamento está testando o vestíbulo e não o cofre.

[PERSONAL EXPERIENCE] O HAI Engine tem corrido em produção desde 2016, e as avaliações adversariais que nos importam têm sempre estado no limite de roteamento — pode um pedido alcançar um room a que não deveria chegar, pode um âmbito ser escalado, pode uma transferência vazar uma permissão? A ênfase do relatório da OWASP na contaminação multi-agente e no uso indevido de MCP é a mesma ênfase, expressa para uma audiência mais ampla. O mecanismo é o limite; a demo é o prompt.

O que o relatório acerta, e o que deixa ao operador

O relatório é forte na lente de procurement. Oferece green flags e red flags que um comprador pode usar imediatamente, uma matriz de comparação consultores versus ferramentas, e uma checklist de pontuação ao longo de dimensões técnicas, operacionais e de governança. As green flags — cadeias de ataque completas, rastreabilidade de agentes, replayabilidade, design de ataques novéis em vez de reutilização de bibliotecas públicas de jailbreak — são cada uma um mecanismo de medição. As red flags — demos de jailbreak como manchete, sem pass@k, sem Average Turns, sem mapeamento para NIST AI RMF ou ISO 42001 ou a EU AI Act — são cada uma um mecanismo ausente.

É mais fraco em três coisas que o operador ainda tem de fornecer. Primeiro, foca na avaliação de fornecedores, com menos orientação sobre como construir capacidade interna de red teaming ou um modelo híbrido. Segundo, referencia estruturas regulatórias sem mapear profundamente os critérios a obrigações de conformidade específicas — as avaliações de conformidade sob a EU AI Act ficam para o leitor. Terceiro, assume um nível relativamente alto de maturidade técnica; uma organização no início da sua trajetória de IA precisará de modelos que o relatório não fornece.

Lemos estas lacunas como o relatório sendo honesto sobre o seu âmbito. É uma estrutura de procurement, não um manual de operação. O trabalho do operador — que o relatório nomeia mas não completa — é tomar os mecanismos de medição e executá-los de forma contínua, não uma vez na compra.

A disciplina de mecanismo único que o relatório pede das métricas

A secção de métricas do relatório é, na nossa leitura, a sua contribuição mais discreta e mais importante. Pede pass@k, Average Turns to Jailbreak, replayabilidade, observabilidade e rastreabilidade de agentes. Cada um é um mecanismo único que produz um sinal mensurável. A disciplina por trás deles é a mesma que sustentamos para o Oracle: as probabilidades são normalizadas num único lugar, o módulo de ensemble, e todo o consumidor pode confiar que sum(probability) ≈ 1.0. Um mecanismo, uma garantia.

Um relatório de red team que agrupa dez métricas num "risk score" tem o mesmo problema que um forecast que agrupa dez modelos num número sem dizer onde a normalização acontece. A garantia é tão boa quanto o mecanismo único que a produz. A insistência do relatório da OWASP em métricas nomeadas e separáveis — pass@k é pass@k, não um componente de uma pontuação — é a insistência de que o mecanismo seja identificável, de modo que quando a propriedade falha, saiba qual mecanismo parou de medir.

Esta é a consequência operacional de Theorem 3. Se a garantia é "segurança," e o mecanismo é "pass@k no caminho de chamada de ferramentas," então quando pass@k cai, sabe que o caminho de chamada de ferramentas é onde a garantia enfraqueceu. Uma pontuação agrupada não pode dizer isso. Só pode dizer que um número se moveu. O relatório, talvez sem o pretender, é um argumento por desagrupar.

O âmbito civil e defensivo é o único âmbito honesto

O relatório trata de red teaming defensivo — encontrar falhas para que possam ser corrigidas. Não trata de capacidade ofensiva. Isto corresponde a um limite que sustentamos explicitamente: uso civil e defensivo apenas. O mesmo mecanismo que encontra um caminho de escalada de privilégios para o fechar poderia, em outras mãos, encontrá-lo para alguém o explorar. O relatório não se demora nisto, mas a estrutura de procurement assume que o comprador quer a falha encontrada e corrigida, não encontrada e armada.

Afirmamo-lo porque a voz do Honest Architect o exige. Uma capacidade de red teaming é um mecanismo de medição; um mecanismo de medição é neutro quanto à intenção do seu operador. A estrutura da OWASP é mais útil para um operador cuja intenção é defensiva, e não a venderíamos de outra forma. A topologia da Everythink — onde as decisões de roteamento são a superfície de ataque — está construída para que o operador defensivo possa ver e fechar os caminhos. Não está construída para ajudar um operador ofensivo a abri-los.

Como isto se liga ao que enviamos

O pipeline Sisters → Oracle é um forecast calibrado, não um palpite. Cada Sister redige um futuro plausível; o Oracle funde-os num ensemble normalizado. A disciplina é: um mecanismo de normalização, uma garantia mensurável. O relatório da OWASP pede o mesmo do red teaming: um mecanismo pass@k, um sinal de segurança mensurável. A forma é a mesma porque o princípio subjacente é o mesmo — Theorem 3, que nem a comunidade de segurança nem a de forecasting possuem, mas que ambas continuam a redescobrir.

Capacidades Production ✅ que carregam esta disciplina: o HAI Engine (o motor de roteamento e matching que tem corrido desde 2016), as Sisters e o Oracle (o ensemble calibrado), o World Monitor (o gateway de geo-sinais em direto cujos ids deterministas significam que a reingestão atualiza, nunca duplica — um mecanismo de medição para a integridade de dados), Social e Campaigns (onde os âmbitos de permissão roteiam antes de o conteúdo ser servido), e a Whitelabel Network (onde a soberania sobre a network, a marca e os dados é o limite de roteamento que o operador controla).

Capacidades Partial ⚠️: Matchmaking, Marketplace e Calendar — os mecanismos de medição existem mas a cobertura é incompleta, e não os chamaremos Production até que o seja. Roadmap 🔵: Wallet & Token, Super App e Community Credit — pre-revenue, sujeitos a revisão Howey, e não prometidos como resultados. Não escalamos estados. As red flags do relatório da OWASP são, em efecto, o modo de falha de escalar um estado: um fornecedor que chama "segurança" a uma demo de jailbreak está a escalar um teste de superfície a uma garantia de sistema.

Pontos-chave

• Uma demo de jailbreak mede o mecanismo de recusa de um chatbot. Não mede os mecanismos de chamada de ferramentas, recuperação ou multi-agente. Certificar um certifica um. Isto é Theorem 3 com fato de segurança.
• O relatório do OWASP GenAI Security Project (2026) separa sistemas de IA simples de avançados e dá dez dimensões de avaliação — cada uma um mecanismo que deve ser implementado e medido, não afirmado.
• As métricas que importam — pass@k, Average Turns to Jailbreak, replayabilidade, rastreabilidade de agentes — são mecanismos únicos e separáveis. Um "risk score" agrupado esconde qual mecanismo parou de medir quando a garantia falha.
• A superfície de ataque real é o limite de roteamento, não o prompt. A topologia network → community → room da Everythink roteia antes de qualquer coisa responder; a permissão em cada transferência é onde um adversário tenta redirecionar o fluxo.
• O âmbito civil e defensivo é o único âmbito honesto para um mecanismo de medição. O mesmo mecanismo que encontra um caminho para o fechar poderia encontrá-lo para o explorar.

Perguntas frequentes

O que é red teaming de IA e em que difere do red teaming tradicional? Red teaming de IA é teste adversarial visando descobrir falhas de segurança, uso indevido e alinhamento em sistemas de IA — alucinações, jailbreaks, uso indevido de ferramentas, escalada de privilégios, vazamento de dados. O red teaming tradicional de cibersegurança testa redes e aplicações em busca de acesso não autorizado. O relatório da OWASP é explícito: os dois não são o mesmo; um red team de IA testa o comportamento do modelo e o sistema à sua volta, não só o perímetro.

Por que uma demo de jailbreak não chega para certificar segurança? Uma demo de jailbreak mede se um prompt específico contorna o mecanismo de recusa de um chatbot. Não mede o caminho de chamada de ferramentas, o caminho de recuperação nem o caminho de transferência multi-agente — cada um um mecanismo separado com um modo de falha separado. Theorem 3 diz-o diretamente: uma propriedade é garantida exatamente quando o seu mecanismo está implementado e medindo. Uma demo que mede o mecanismo errado não garante nada sobre o certo.

Que métricas deveria um fornecedor de red teaming relatar? O relatório da OWASP nomeia pass@k (a probabilidade de que pelo menos um de k tentativas tenha sucesso) e Average Turns to Jailbreak, além de replayabilidade, observabilidade e rastreabilidade de agentes. Cada um é um mecanismo de medição único e separável. Um fornecedor que relata só uma contagem de vulnerabilidades encontradas, sem estes mecanismos, está a relatar um número, não uma garantia.

Como se relaciona a topologia da Everythink com o red teaming de IA? A topologia network → community → room roteia um pedido antes de qualquer coisa responder. A permissão em cada transferência — âmbito de room, limite de confiança de community, soberania de network — é uma decisão de roteamento, e as decisões de roteamento são a superfície de ataque real em sistemas agentivos. Um red team que testa o prompt e não o limite de roteamento testa o vestíbulo, não o cofre. "The space is the router" é a afirmação de que a camada de roteamento é onde a segurança se ganha ou se perde.

Pode uma estrutura de red teaming ser usada ofensivamente? Um mecanismo de medição é neutro quanto à intenção. A estrutura da OWASP está desenhada para o operador defensivo que quer falhas encontradas e corrigidas. A Everythink sustenta um limite de âmbito civil e defensivo explicitamente: a topologia está construída para que o operador defensivo possa ver e fechar caminhos, não para que um operador ofensivo os abra.

Sources

• 2026 — OWASP GenAI Security Project, "Vendor Evaluation Criteria for AI Red Teaming Providers & Tooling," Version 1.0, public release January 13, 2026; summarized by aigl.blog on March 20, 2026: https://www.aigl.blog/vendor-evaluation-criteria-for-ai-red-teaming-providers-tooling/

Crie a sua network — e decida onde o limite de roteamento se situa antes de qualquer coisa responder.