Un nouveau survey sur la sécurité agentic AI nomme quatre patterns d'attaque concrets contre les agents d'opérations LLM-based qui tiennent un vrai accès production. Prompt injection : des instructions malicieuses embedded dans un ticket Jira ou une page wiki steer l'agent vers une action unsafe. Retrieval poisoning : des runbooks et historiques d'incident corrompus biaisent les diagnostics de l'agent vers les objectifs de l'attaquant. Retrieval jamming : flooder les knowledge bases avec des documents blocker trigger des refusal loops, stalling l'incident response — un denial-of-service contre la decision loop de l'agent. Manipulation de télémétrie : les attaquants influencent les metrics et logs pour steer les décisions de mitigation sans toucher au modèle lui-même. Thread commun : le problème confused-deputy. L'agent a un accès API légitime, mais les artefacts qui shapent ses décisions — tickets, logs, transcripts, pages wiki, documents retrieved — sont exactement les surfaces que les attaquants peuvent compromettre.
La défense proposée est architecturale plutôt que model-level. Split proposition vs exécution : le language model reason, retrieve evidence, draft des change proposals — et peut pas executer des writes. Tous les changements production passent à travers des gates non-bypassables qui enforcent des policy checks, invariant verification, approval humain où le change le warrant, et staged rollback. Le risk tiering sur lequel le survey land : read-only assistance c'est low-risk ; bounded execution avec strong gates c'est défendable ; open-ended self-healing sans verification scaffolding c'est le claim higher-risk qui mérite du skepticism. Le gap d'évaluation c'est la partie à laquelle la plupart des builders devraient porter attention : les benchmarks current manquent les tool-call traces, gate-violation rates, comportement adversarial input, refusal-storm rates sous jamming, completeness du rollback. Des systèmes qui performent bien sur des incidents clean peuvent collapser sous des Jira tickets hostiles et la eval suite le saurait jamais.
Contexte écosystème. C'est le côté threat-model de ce qu'Anthropic a shippé cette semaine avec Managed Agents et MCP Tunnels. Les primitives architecturales qui permettent aux agents de reach les systèmes production sont aussi où la classe d'attaque confused-deputy s'ouvre. Le screening destructive-action d'Auto Mode d'Anthropic (annoncé à Code With Claude) c'est une forme du gate que ce survey appelle ; la question plus large c'est quel set de gates est suffisant pour quel risk tier. Le gap du eval landscape current est structurel : SWE-bench Verified, MMLU, et les benchmarks agent clean-incident mesurent la capability sous des inputs qui coopèrent. La robustness adversariale — refusal-storm rates, gate-violation rates, résistance prompt-injection — est largement unmeasured au niveau benchmark. La narrative Capability Curve d'Anthropic (62 à 87% sur SWE-bench Verified) mesure un axe ; le cadrage de ce survey montre que l'axe orthogonal c'est où les agents production-grade vivent ou meurent vraiment. Pour les builders de l'écosystème wrapper (LangGraph, AutoGen, CrewAI), le cadrage confused-deputy a des implications de design : les layers state management et tool-call routing sont où les gates ont besoin de vivre, pas dans le modèle lui-même.
Lundi matin : si tu shippes des agents avec accès production (CI runners, incident response, infra automation, ticketing support automation), audite ton stack contre les quatre patterns cette semaine. Actions concrètes. Premièrement, liste chaque input que l'agent traite comme trusted — tickets, wiki, telemetry, threads Slack, documents retrieved — et assume que chacun peut être hostile ; la menace c'est du contenu injecté par un attaquant, pas du jailbreak de modèle. Deuxièmement, implémente le split proposal-execution : l'agent draft, une gate non-bypassable (policy check, invariant verify, approval humain optionnel) exécute. La gate c'est là que la security review se concentre, pas le prompt du modèle. Troisièmement, ajoute des evals pour les inputs adversariaux — au minimum, des tickets prompt-injectés, des contextes de retrieval poisoned, et des scenarios refusal-storm. Quatrièmement, watch les refusal-storm rates comme metric explicite. Un agent qui « refuse d'agir sous des inputs hostiles » a l'air safe en isolation mais stall l'incident response réelle sous jamming — les deux failure modes need des budgets séparés. Le trap clean-eval-benchmark est réel. La robustness adversariale c'est le prochain axe d'eval après la capability raw, et la plupart des déploiements d'agents production ne la mesurent pas encore.