ChannelGuard revela que a seguranca de pipelines multi-agente depende de filtros que ninguem media
Um estudo com 2.100 execucoes de ataque mostra que pipelines multi-agente que pareciam totalmente seguros em relatorios padrao (0% de sucesso de ataque) na verdade devem quase toda essa protecao a um filtro server-side do provedor de nuvem, e nao a defesas da propria aplicacao. Os autores propoem o ChannelGuard, portoes de information bottleneck colocados em cada canal entre agentes, para fechar essa lacuna sem depender de um unico ponto de filtragem opaco.
Sistemas multi-agente com LLMs encadeiam um planejador, agentes de trabalho, um verificador e um sintetizador, e cada salto entre esses agentes e, na pratica, um canal nao monitorado pelo qual um adversario pode contrabandear instrucoes -- por exemplo, atraves de saidas de ferramentas envenenadas ou de memoria compartilhada manipulada. As defesas existentes (IBProtector, Llama Guard, filtros de perplexidade, SmoothLLM) protegem apenas a fronteira de entrada do sistema, deixando esses canais internos sem inspecao.
O achado mais importante do paper e metodologico: ao rodar 2.100 traces cobrindo oito familias de ataque, cinco defesas e tres backends de modelo, os autores descobrem que um pipeline sem qualquer defesa aplicativa aparecia como completamente seguro (0% de sucesso de ataque em envenenamento de ferramenta e de memoria) quando rodado sobre Azure GPT-5 -- mas essa seguranca vinha quase inteiramente de um filtro server-side do provedor de nuvem (54 de 60 bloqueios). Ao trocar para um backend sem esse filtro, a mesma aplicacao "sem defesas" perde a protecao quase por completo, dependendo entao apenas do alinhamento intrinseco do modelo. Relatorios de taxa de sucesso que nao decompoe onde o bloqueio ocorreu escondem essa dependencia critica e podem levar equipes a superestimar a robustez real de sua propria aplicacao.
O ChannelGuard, a defesa proposta, coloca portoes de information bottleneck em cada canal entre agentes, sem exigir treinamento nem chamadas adicionais a LLM: cada portao pontua o texto do canal por similaridade de embedding contra um banco de frases adversariais e decide deterministicamente entre deixar passar, comprimir ou bloquear, registrando qual camada interrompeu cada ataque. O resultado e uma defesa que funciona de forma identica independentemente do backend de nuvem usado (30 de 30 bloqueios de envenenamento de ferramenta em Azure GPT-5, Anthropic Sonnet 4.5 e Haiku 4.5), reduz pela metade o sucesso de injecao de prompt (de 0.333 para 0.167) e preserva a acuracia em tarefas benignas. Uma limitacao relevante e que ataques de parafraseamento adaptativo em modo white-box conseguem evadir todos os portoes baseados em embedding, indicando que a defesa protege contra adversarios que nao conhecem o filtro, mas nao contra quem pode otimizar diretamente contra ele.
Na pratica, o trabalho e um alerta para qualquer equipe que opera agentes de IA encadeados: a seguranca "medida" de um pipeline pode ser, na verdade, a seguranca de um servico de nuvem terceirizado e opaco, que pode mudar de comportamento, ser desligado ou nao estar disponivel em outro provedor. Isso reforca a necessidade de defesa em profundidade dentro da propria aplicacao, em vez de depender implicitamente de filtros externos cuja existencia e eficacia raramente sao auditadas.