O melhor detector de agentes em produção captura 67%. Planeje para o resto.

Na semana passada, duas das organizações de engenharia mais fortes desta indústria abriram o código-fonte de suas pilhas de segurança de agentes com três dias de diferença. A Uber lançou o ADR, o sistema de detecção e resposta que está em produção há dez meses. A Perplexity lançou o Numbat, um conjunto de segurança de agentes sob a licença Apache-2.0, já implantado em milhares de seus próprios pontos finais. Ambos são softwares reais, em funcionamento e bem construídos, e se você opera agentes em qualquer escala, deve ler ambos esta semana.

Depois, leia o artigo do ADR, porque ele contém um número que quase ninguém que cita o lançamento repetiu. No ADR-Bench, o próprio benchmark da Uber de 302 tarefas, 17 técnicas de ataque e 133 servidores MCP extraídos de telemetria real, o ADR detecta 67% dos ataques sem falsos positivos. Esse resultado supera o ALRPHFS, GuardAgent e LlamaFirewall de duas a quatro vezes em F1. É, até onde os registros públicos vão, a melhor detecção de ataque agente que alguém já publicou.

Estado da arte, dez meses em produção, avaliado contra sua própria telemetria do mundo real, e aproximadamente um ataque em três passa despercebido.

67% não é uma falha. É o teto.

Quero ser preciso sobre o elogio aqui, porque isso importa. A Uber publicou esse número. Eles construíram o benchmark que expõe seu próprio limite, colocaram em um artigo, colocaram o sensor e o detector e o benchmark no GitHub, e deixaram você conferir. Isso é prova em vez de promessas, e é mais raro do que deveria ser.

O número não é uma acusação ao ADR. É uma propriedade da categoria. Um detector é uma aposta nos ataques que você pensou. O ADR-Bench codifica 17 técnicas, que são 17 mais do que a maioria das equipes enumerou, e a leitura honesta de 67% é que mesmo um excelente detector, ajustado contra tráfego real por uma equipe com cicatrizes de produção, não consegue fechar o conjunto. O residual não é descuido que você pode eliminar com regras melhores. É a parte do espaço de ameaça que não estava na distribuição de treinamento, e existirá em todas as versões deste produto para sempre.

Portanto, a questão operacional não é como chegamos a 100%. É o que você tem quando o detector não dispara?

Se a resposta forem seus logs, você não tem muito. Os logs são escritos pelo host, no host, e podem ser editados por quem acabou de assumir o controle do host. A forma mais comum de um incidente sério é que o registro do incidente é controlado pela parte que você está investigando.

A detecção é uma probabilidade. A evidência é um registro. Você precisa de ambos, e apenas um deles ainda funciona depois que você perde.

Os controles atuam apenas à esquerda do teto. O registro é desenhado de forma indivisível porque não depende da classificação.

RufRoot é como parece o outro terço

Enquanto esses dois lançamentos estavam acontecendo, o ecossistema de agentes produziu uma ilustração quase perfeita.

CVE-2026–59726, que a Noma Security nomeou de RufRoot, é um CVSS 10.0 no Ruflo, um meta-harness de agente em uso muito amplo. Cada versão anterior à 3.16.3 enviou uma ponte MCP não autenticada, aberta para a rede por padrão, expondo 233 ferramentas, incluindo execução de shell, operações de banco de dados, gerenciamento de agentes e armazenamento de memória. Um único pedido HTTP não autenticado obtém execução remota de código. Foi divulgado em 30 de junho e, para o crédito do mantenedor, corrigido em 24 horas.

Aqui está a parte que deve mudar a forma como você pensa sobre sua própria implantação. A orientação de remediação não para na atualização. Ela diz para você girar cada chave de API LLM, fechar as portas 3001 e 27017, inspecionar o MongoDB em busca de adulterações e auditar o padrão de armazenamento do AgentDB em busca de entradas maliciosas, porque uma simples atualização não desfaz a contaminação.

Leia isso novamente como um operador. Os pesquisadores demonstraram a escrita de entradas controladas por atacantes na memória persistente do agente, de modo que futuras respostas incorporem instruções do atacante. Você atualiza para 3.16.3. Seu scanner fica verde. Seu relatório de dependências está limpo. E seu agente ainda está comprometido, porque a contaminação não está mais no código. Está no estado.

A detecção não pegou isso, porque não havia nada anômalo para pegar: uma ferramenta autorizada escreveu em um armazenamento autorizado. A correção não limpou isso. E nada na pilha ordinária pode lhe dizer se esse armazenamento é o que você começou.

A nova implantação substitui a imagem medida e nunca alcança o armazenamento de padrões, então a entrada contaminada sobrevive à correção.

Não medido não é vazio

O erro subjacente a tudo isso é tratar a memória do agente como um cache.

Se a memória fosse recuperação, o RufRoot seria um incômodo e você limparia e seguiria em frente. Mas a memória do agente é um estado acumulado que muda o comportamento futuro, o que torna sua integridade uma propriedade de segurança do sistema em execução, exatamente como um pacote de políticas ou um catálogo de ferramentas. Já aceitamos isso para o código. Ninguém envia um contêiner sem um digest. Então, entregamos ao mesmo agente um armazenamento persistente que molda cada decisão subsequente, e não medimos nada.

Um armazenamento que você nunca mediu não é um armazenamento limpo, e não é um armazenamento corrompido. É um armazenamento sobre o qual você não pode dizer nada.

É por isso que "nenhuma evidência de adulteração" é uma declaração sobre sua instrumentação, em vez de sobre seu agente. A correção não é exótica e não é um novo pensamento. É o que fazemos em todos os outros lugares: medir o estado, vincular a medição ao hardware e fazer uma mudança que ninguém registrou detectável em vez de invisível. Se o digest do armazenamento de padrões for medido em uma atestação e ancorado em um registro de apenas anexação, um atacante que o contamina deixa uma entrada que você pode encontrar ou quebra uma cadeia que você pode verificar. A contaminação deixa de ser um não-evento silencioso.

O que a atestação não faz

Este boletim é chamado de Prova, não Promessas, então aqui está a parte que vai contra mim.

A atestação não para a ação. O hook de pré-ação do Numbat faz algo que um registro assinado fundamentalmente não pode: ele avalia um comando proposto antes que ele chegue ao sistema operacional e o recusa. Cinquenta e duas regras em onze categorias de comportamento, expressas em CEL, rodando em um binário Go no endpoint. Isso é um não em tempo real. A evidência chega depois, e depois nem sempre é bom o suficiente. Qualquer um que lhe diga que a atestação substitui os controles está vendendo algo.

As duas camadas fazem trabalhos diferentes e você quer ambas. Os controles reduzem a probabilidade. A evidência remove a deniabilidade. O ADR e o Numbat são trabalhos fortes na primeira categoria. O que estou argumentando é que o segundo não é.