💻 computer science

ChannelGuard: Safe Models Do Not Compose into Safe Multi-Agent Systems

O artigo apresenta o ChannelGuard, um framework de defesa em profundidade que não requer treinamento, o qual protege sistemas de LLM multiagentes ao posicionar portões determinísticos de gargalo de informação em cada canal entre agentes, bloqueando efetivamente o envenenamento de ferramentas e reduzindo as taxas de sucesso de injeção de prompt sem depender de filtros opacos do lado do provedor ou de chamadas adicionais de LLM.

Autores originais: Elias Hossain, Md Mehedi Hasan Nipu, Fatema Tuj Johora Faria, Tasfia Nuzhat Ornee, Maleeha Sheikh

Publicado 2026-07-23

📖 6 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Elias Hossain, Md Mehedi Hasan Nipu, Fatema Tuj Johora Faria, Tasfia Nuzhat Ornee, Maleeha Sheikh

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine uma equipe de robôs especialistas trabalhando juntos para resolver um mistério complexo. Um robô (o Planejador) divide a grande questão em pequenos indícios. Outros robôs (os Trabalhadores) saem para encontrar esses indícios, verificam suas notas e usam ferramentas especiais. Finalmente, um quarto robô (o Sintetizador) reúne todas as respostas para contar a história. No mundo da Inteligência Artificial, isso é chamado de "sistema multiagente". É como uma corrida de revezamento de alta tecnologia onde o bastão é uma mensagem passada de um IA para o próximo.

Por muito tempo, os cientistas se preocuparam com a primeira entrega: e se um humano enganasse o primeiro robô com um comando sorrateiro? Construímos "seguranças" na porta da frente para pegar esses truques. Mas este artigo faz uma pergunta assustadora: o que acontece no meio da corrida? E se um dos robôs for enganado por uma ferramenta, ou por uma nota deixada em um caderno compartilhado, e então passar essa ideia ruim para o próximo robô? O artigo argumenta que, embora a porta da frente esteja guardada, o corredor entre os robôs está totalmente aberto. Acontece que muitas dessas equipes de robôs são seguras apenas porque a empresa de nuvem que as hospeda possui um filtro invisente e secreto que captura ideias ruins depois que os robôs as passam, mas antes que a resposta final seja mostrada. Os autores chamam isso de "segurança emprestada", e eles querem construir um sistema onde a segurança pertença à própria equipe, não ao proprietário do imóvel.

O Problema: O Corredor Invisível

Os pesquisadores, Elias Hossain e sua equipe, analisaram como essas equipes de IA funcionam. Eles descobriram que toda vez que um robô passa uma mensagem para outro — seja uma subtarefa, o resultado de uma ferramenta ou uma nota de memória — ela viaja através de um "canal". Esses canais são atualmente não monitorados. Um invasor poderia deslizar uma instrução maliciosa no resultado de uma ferramenta ou em uma nota de memória, enganando o próximo robô para fazer algo perigoso.

A parte assustadora é que, quando os cientistas testam esses sistemas, eles frequentemente veem um registro de segurança perfeito: zero ataques bem-sucedidos. Mas os autores descobriram que essa segurança é uma ilusão. Em seus testes, quando rodaram o sistema em um provedor de nuvem específico (Azure), o sistema bloqueou 90% dos ataques. No entanto, não era a equipe de IA que estava bloqueando; era o filtro do lado do servidor do provedor de nuvem. Se mudassem para um provedor de nuvem diferente (como a Anthropic) que não tivesse esse filtro específico, a "segurança" desaparecia, e os ataques tinham sucesso. O sistema parecia seguro apenas porque estava pegando proteção emprestada da empresa de nuvem, não porque a equipe de IA era realmente segura.

A Solução: ChannelGuard

Para corrigir isso, a equipe construiu uma nova defesa chamada ChannelGuard. Em vez de apenas guardar a porta da frente, o ChannelGuard coloca um posto de controle em cada corredor entre os robôs.

Pense nisso como um segurança em cada porta de uma boate.

O Posto de Controle: Toda vez que uma mensagem tenta se mover de um robô para outro, ela atinge um portão.
A Varredura: Esse portão não usa uma IA complexa para adivinhar se a mensagem é ruim. Em vez disso, usa um truque matemático simples e rápido. Ele quebra a mensagem em frases e as compara com uma pequena lista de "frases ruins" (como um cartaz de "Procura-se" para instruções perigosas).
A Decisão: Se a mensagem parecer muito com uma frase ruim, o portão a interrompe imediatamente. Se for um pouco suspeita, pode cortar a parte arriscada e deixar a parte segura passar. Se estiver limpa, permite a passagem.

Crucialmente, esses portões são "livres de treinamento" (training-free), o que significa que não precisam aprender ou estudar novos dados para funcionar. Eles apenas usam a lista de frases ruins e uma fórmula matemática para tomar uma decisão instantaneamente.

O Que Eles Descobriram

A equipe testou o ChannelGuard contra 2.100 diferentes tentativas de ataque usando oito tipos diferentes de truques. Aqui está o que descobriram:

Segurança Real, Não Segurança Emprestada: No ataque de "Envenenamento de Ferramenta" (onde um resultado de ferramenta ruim tenta enganar um trabalhador), o sistema antigo dependia do provedor de nuvem para bloquear 90% dos ataques. O ChannelGuard, no entanto, bloqueou 100% dos ataques por conta própria, independentemente de qual provedor de nuvem fosse usado. Ele tornou a segurança "invariante ao provedor", o que significa que o sistema é seguro não importa onde seja executado.
Aumento de Velocidade: Como o ChannelGuard pode interromper uma mensagem ruim antes que ela chegue aos modelos de IA caros e lentos, ele de fato tornou o sistema mais rápido. Para ataques de "Injeção de Prompt" (truques na porta da frente), o ChannelGuard foi 3,30 vezes mais rápido que o sistema desprotegido porque cortou as mensagens ruins precocemente, poupando o computador de realizar trabalho desnecessário.
Sem Perda de Inteligência: O sistema não ficou "mais burro". Quando testado em problemas matemáticos (GSM8K) sem ataques, o ChannelGuard manteve a precisão exatamente a mesma (0,867), provando que não bloqueia ideias boas por acidente.
O Ponto Fraco: O sistema não é perfeito. Se um invasor conhecer a lista de "frases ruins" e reescrever seu truque usando palavras diferentes que significam a mesma coisa (chamado de "paráfrase adaptativa"), os portões ficam confusos. Nesses casos, o sistema falhou cerca de 66% das vezes, exatamente como o sistema desprotegido. Os autores admitem que, para esses truques astutosos e reescritos, um tipo diferente de defesa (uma que altera levemente as palavras para confundir o invasor) funciona melhor.

A Conclusão

O artigo conclui que não podemos apenas confiar nas empresas de nuvem para manter nossas equipes de IA seguras. Precisamos construir nossos próprios guardas dentro da equipe. O ChannelGuard mostra que, ao colocar postos de controle simples e rápidos entre cada robô, podemos capturar ataques que passam pela porta da frente e impedi-los de se espalhar. Embora não capture todos os tipos de truques (especialmente os que se reescrevem), ele transforma a "segurança emprestada" em "segurança própria", tornando o sistema confiável não importa onde ele rode. Os autores liberaram todos os seus dados e código para que outros possam verificar seu trabalho, provando que a segurança em equipes de IA precisa ser construída na arquitetura, e não apenas esperada.

Resumo Técnico: ChannelGuard: Modelos Seguros Não se Compõem em Sistemas Multiagentes Seguros

1. Declaração do Problema

As aplicações modernas de Large Language Model (LLM) dependem cada vez mais de sistemas multiagentes onde um planejador decompõe tarefas, agentes trabalhadores executam essas tarefas (frequentemente chamando ferramentas ou lendo memória compartilhada) e um verificador/sintetizador produz um resultado final. Os autores identificam uma lacuna de segurança crítica: enquanto as defesas existentes focam na fronteira de entrada (Usuário $\to$ Planejador) ou dependem de filtros opacos e estocásticos do lado do provedor (ex: Azure Content Safety), os canais inter-agentes (Planejador $\to$ Trabalhador, Ferramenta $\to$ Trabalhador, Memória $\to$ Trabalhador, etc.) permanecem sem monitoramento.

O artigo argumenta que as métricas de avaliação atuais, especificamente a Taxa de Sucesso de Ataque (ASR - Attack Success Rate), são enganosas. Um pipeline pode apresentar um ASR de 0.000 em um backend específico (ex: Azure GPT-5) não porque a aplicação seja segura, mas porque o filtro do lado do servidor do provedor de nuvem interceptou o ataque. Isso cria um problema de "substituição de mecanismo": se o backend for trocado por um modelo sem tais filtros (ex: Anthropic Sonnet), o resultado de segurança permanece 0.000, mas o mecanismo de proteção muda inteiramente para o alinhamento interno do modelo, que está fora do controle do desenvolvedor e é inobservável. Consequentemente, os profissionais não conseguem raciocinar sobre a verdadeira robustez de seus sistemas.

2. Metodologia: O Framework ChannelGuard

O ChannelGuard é um framework de defesa em profundidade, livre de treinamento, projetado para instrumentar cada canal inter-agente. Ele não modifica os modelos dos agentes nem requer retreinamento.

Componentes Principais

Portões de Gargalo de Informação (IB Gates):
- Posicionamento: Seis portões são colocados em canais específicos: Entrada (IB-0), Planejador para Trabalhador (IB-1), Ferramenta para Trabalhador (IB-3), Memória para Trabalhador (IB-3-mem), Trabalhador para Verificador (IB-2/IB-4) e Trabalhador para Sintetizador (IB-5).
- Mecanismo: Cada portão processa o texto em seu canal dividindo-o em sentenças, gerando embeddings (usando um modelo local all-MiniLM-L6-v2) e calculando a similaridade de cosseno máxima contra um banco de frases adversariais fixo e curado por humanos.
- Lógica de Decisão: O portão calcula um score de risco e toma uma decisão determinística de três vias:
  - Passar (Pass): Risco < $\alpha\theta$ (o texto passa inalterado).
  - Comprimir (Compress): $\alpha\theta \le$ Risco < $\theta$ (o texto é truncado para as primeiras $N=2$ sentenças).
  - Bloquear (Block): Risco $\ge \theta$ (o texto é substituído por uma string vazia, interrompendo o pipeline).
- Propriedades: O portão não adiciona chamadas de LLM, não requer dados de treinamento e sua decisão é independente do modelo de agente downstream.
Verificador Consciente de Incerteza (Uncertainty-Aware Verifier):
- Um LLM separado (Claude Sonnet 4.5) pontua as saídas sobreviventes dos trabalhadores usando 5 amostras de Monte Carlo para determinar uma média de score de segurança e dispersão.
- Ele sinaliza saídas como "inseguras" ou "incertas".
Sintetizador de Triplo Filtro (Triple-Filter Synthesizer):
- O sintetizador final só aceita respostas que passem pelo portão IB-5, tenham um score de segurança médio $\ge 0.5$ e não sejam sinalizadas como inseguras e incertas simultaneamente.
- Se nenhuma saída sobreviver, uma recusa rígida é retornada sem invocar novas chamadas de LLM.

Metodologia de Avaliação

O artigo introduz uma metodologia de atribuição por traço (per-trace attribution). Em vez de apenas reportar o ASR, o sistema registra exatamente qual camada (portão IB, filtro do provedor, verificador, ou alinhamento do modelo) interrompeu o ataque primeiro. Isso permite uma análise de "substituição de mecanismo", distinguindo entre bloqueio de propriedade da aplicação e bloqueio emprestado do provedor.

3. Principais Contribuições

Atribuição por Traço: Uma metodologia que converte o ASR baseado apenas em resultados em uma conta ao nível do mecanismo, tornando a "substituição de mecanismo" (a dependência de filtros de backend) mensurável e visível.
Análise de Dependência de Provedor: Evidência empírica mostrando que, no Azure GPT-5, um pipeline indefeso deriva 90% de sua proteção de zero-ASR do filtro do provedor. Ao mudar para backends Anthropic, essa proteção é totalmente re-originada no alinhamento do modelo, provando que o resultado de segurança é idêntico, mas a procedência é diferente e incontrolável.
O Framework ChannelGuard: Um sistema de seis portões de similaridade de embedding que fornece um bloqueio invariante ao provedor e de propriedade da aplicação.
Delimitação Precisa de Limites: O artigo identifica explicitamente onde o framework falha (paráfrase adaptativa white-box) e onde ele tem sucesso, com suporte de extensos estudos de ablação e baselines.

4. Resultados

A avaliação cobriu 2.100 traços através de oito famílias de ataques, cinco defesas e três backends de modelos (Azure GPT-5, Anthropic Sonnet 4.5, Anthropic Haiku 4.5).

Envenenamento de Ferramenta (Tool Poisoning): O ChannelGuard alcançou 30/30 bloqueios no portão IB-3 (Ferramenta $\to$ Trabalhador) em todos os três backends. Em contraste, o pipeline indefeso dependeu 100% do filtro do provedor Azure para o bloqueio no Azure, e 100% do alinhamento do próprio modelo no Anthropic. O mecanismo do ChannelGuard permaneceu fixo e de propriedade da aplicação.
Injeção de Prompt (Prompt Injection): O ChannelGuard reduziu o ASR em 50% (0.333 $\to$ 0.167) em comparação com o baseline indefeso.
Envenenamento de Memória (Memory Poisoning): No stack Azure, o filtro do provedor dominou o bloqueio para ambos os sistemas. No entanto, nos backends Anthropic, o portão IB-3-mem do ChannelGuard forneceu bloqueio parcial, com o restante sendo tratado pelo alinhamento do modelo, demonstrando um resultado de "crédito compartilhado" em vez de uma substituição total.
Paráfrase Adaptativa (White-Box): Tanto o ChannelGuard quanto o baseline indefeso falharam, com um ASR de ~0.667. O banco de frases estático não conseguiu detectar reescritas semanticamente equivalentes, mas lexicalmente distantes. O artigo nota que um baseline de não-assinatura (SmoothLLM) performou melhor neste ataque específico.
Eficiência: O ChannelGuard é 1.19 $\times$ mais rápido na carga de trabalho adversária agregada. Especificamente em Injeção de Prompt, ele é 3.30 $\times$ mais rápido porque seu portão IB-0 interrompe o pipeline antes de chamadas de modelos caras ocorrem.
Fidelidade de Raciocínio: Em tarefas benignas de GSM8K (sem ataques), o ChannelGuard preservou a precisão do raciocínio exatamente (CTCA = 0.867 para ambos os sistemas).

5. Significância e Alegações

O artigo afirma que modelos seguros não se compõem em sistemas multiagentes seguros sem o monitoramento explícito dos canais inter-agentes. Sua principal significância reside em:

Expor a "Ilusão de Segurança": Demonstrar que o zero ASR em avaliações atuais frequentemente mascara uma dependência total de filtros estocásticos e opacos de provedores que os desenvolvedores não podem controlar ou auditar.
Invariância de Provedor: Provar que o ChannelGuard fornece um mecanismo de bloqueio determinístico e inspecionável que permanece consistente independentemente do backend do modelo subjacente, ao contrário da segurança "emprestada" de pipelines indefesos.
Defesa em Profundidade: Posicionar o ChannelGuard não como um substituto para filtros de provedor ou defesas de apenas entrada, mas como uma camada necessária que assegura a superfície interna do pipeline.

Os autores são modestos quanto às limitações do framework, reconhecendo que bancos de frases estáticos não podem derrotar paráfrases adaptativas white-box e que a implementação atual depende de templates curados manualmente apenas em inglês. Eles concluem que o próximo passo é aprender o banco de frases de forma adversária para igualar a cobertura dos canais.