Um novo survey sobre segurança agentic AI nomeia quatro padrões de ataque concretos contra agentes de operações baseados em LLM que têm acesso real à produção. Injeção de prompt: instruções maliciosas embutidas em um ticket Jira ou página wiki direcionam o agente para uma ação insegura. Envenenamento de retrieval: runbooks e históricos de incidentes corrompidos enviesam os diagnósticos do agente em direção aos objetivos do atacante. Jamming de retrieval: inundar bases de conhecimento com documentos bloqueadores dispara loops de recusa, estagnando a resposta a incidentes — um denial-of-service contra o loop de decisão do agente. Manipulação de telemetria: atacantes influenciam métricas e logs para direcionar decisões de mitigação sem tocar no modelo. Fio comum: o problema confused-deputy. O agente tem acesso API legítimo, mas os artefatos que moldam suas decisões — tickets, logs, transcripts, páginas wiki, documentos recuperados — são exatamente as superfícies que atacantes podem comprometer.
A defesa proposta é arquitetural ao invés de a nível de modelo. Divisão proposta vs execução: o modelo de linguagem raciocina, recupera evidência, redige propostas de mudança — e não pode executar escritas. Todas as mudanças de produção passam por portões não-bypaseáveis que aplicam verificações de política, verificação de invariantes, aprovação humana onde a mudança merece, e rollback escalonado. O escalonamento de risco onde o survey aterrissa: assistência de somente-leitura é baixo-risco; execução limitada com portões fortes é defensável; auto-cura aberta sem andaime de verificação é a alegação de alto-risco que merece ceticismo. A lacuna de avaliação é a parte a que a maioria dos builders deveria prestar atenção: os benchmarks atuais perdem traços de tool-call, taxas de violação de portão, comportamento de entrada adversarial, taxas de tempestade-de-recusa sob jamming, completude de rollback. Sistemas que performam bem em incidentes limpos podem colapsar sob tickets Jira hostis e a suite de eval nunca saberia.
Contexto do ecossistema. Este é o lado threat-model do que a Anthropic enviou esta semana com Managed Agents e MCP Tunnels. As primitivas arquiteturais que permitem aos agentes alcançar sistemas de produção são também onde a classe de ataque confused-deputy se abre. O screening de ação destrutiva do Modo Auto da Anthropic (anunciado em Code With Claude) é uma forma do portão que este survey pede; a pergunta mais ampla é qual conjunto de portões é suficiente para qual nível de risco. A lacuna do panorama atual de eval é estrutural: SWE-bench Verified, MMLU, e os benchmarks de agente incidente-limpo medem capacidade sob entradas cooperantes. A robustez adversarial — taxas de tempestade-de-recusa, taxas de violação de portão, resistência a injeção de prompt — está em grande parte sem medida a nível benchmark. A narrativa Capability Curve da Anthropic (62 a 87% no SWE-bench Verified) mede um eixo; o enquadramento deste survey mostra que o eixo ortogonal é onde os agentes grau-produção realmente vivem ou morrem. Para os builders do ecossistema wrapper (LangGraph, AutoGen, CrewAI), o enquadramento confused-deputy tem implicações de design: as camadas de gestão de estado e roteamento de tool-call são onde os portões precisam viver, não no modelo em si.
Segunda-feira: se você envia agentes com acesso de produção (runners CI, resposta a incidentes, automação de infraestrutura, automação de ticketing de suporte), audite seu stack contra os quatro padrões esta semana. Ações concretas. Primeiro, liste cada entrada que o agente trata como confiável — tickets, wiki, telemetria, threads de Slack, documentos recuperados — e assuma que cada um pode ser hostil; a ameaça é conteúdo injetado por um atacante, não jailbreak de modelo. Segundo, implemente a divisão proposta-execução: o agente redige, um portão não-bypaseável (verificação de política, verificar invariante, aprovação humana opcional) executa. O portão é onde a revisão de segurança se concentra, não o prompt do modelo. Terceiro, adicione evals para entradas adversariais — no mínimo, tickets com prompt-injetado, contextos de retrieval envenenados, e cenários de tempestade-de-recusa. Quarto, observe as taxas de tempestade-de-recusa como métrica explícita. Um agente que "não age sob entradas hostis" parece seguro em isolamento mas estagna a resposta a incidentes real sob jamming — ambos os modos de falha precisam de orçamentos separados. A armadilha do benchmark de eval limpo é real. A robustez adversarial é o próximo eixo de eval depois da capacidade crua, e a maioria dos deploys de agentes de produção não a mede ainda.