ADR : détection et réponse pour agents MCP, éprouvé à l'échelle d'Uber
Un papier de mai 2026 signé Uber décrit un système type EDR pour agents MCP : télémétrie causale complète, détection à deux étages et red teaming hors ligne, déployé sur plus de 7 200 hôtes pendant dix mois.
De quoi s’agit-il ?
Le 17 mai 2026, une équipe d’Uber a publié ADR: An Agentic Detection System for Enterprise Agentic AI Security (arXiv:2605.17380, poster MLSys 2026). Le papier décrit ce que les auteurs présentent comme le premier cadre éprouvé en production, à grande échelle, pour surveiller les agents IA qui opèrent via le Model Context Protocol (MCP) — ce montage désormais courant où un hôte comme Cursor, Cline ou Claude Code dialogue avec des serveurs MCP distants exposant lecture/écriture de fichiers, appels d’API et accès aux bases de données.
La motivation est un angle mort que beaucoup d’équipes reconnaîtront. Les outils EDR classiques voient les résultats — un fichier écrit, une API appelée — mais pas les prompts de l’agent, son raisonnement, ni la chaîne causale reliant une instruction à une action. Impossible, dès lors, de distinguer une exfiltration malveillante d’une sauvegarde de configuration anodine. La thèse d’ADR : la sécurité des agents exige une télémétrie pensée pour les agents, et une détection assez économique pour passer à l’échelle. Le code et le benchmark sont publiés en open source sur GitHub.
Comment ça marche
ADR comporte trois composants, chacun calqué sur un rôle familier de SOC :
Composant Rôle (analogie SOC) Fonction
-------------- ------------------------ --------------------------------------
ADR Sensor Visibilité / agent EDR Analyse les caches locaux des outils
agentiques (bases SQLite / JSONL de
Cursor, Cline, Claude Code) pour
reconstruire la session complète :
prompts, raisonnement, appels d'outils
MCP, contexte d'exécution
ADR Detector Triage à étages + analyste Tier 1 : triage LLM économique à fort
rappel (« dans le doute, on escalade »);
Tier 2 : raisonnement profond avec
contexte entreprise + threat intel
ADR Explorer Red team interne Moteur hors ligne qui génère et teste
des variantes d'attaque avant
déploiement, réinjectées dans le Tier 2Le principe directeur est la télémétrie causale, pas seulement les résultats : le Sensor enregistre pourquoi une chose s’est produite (prompt → raisonnement → exécution d’outil), comblant l’angle mort d’observabilité. Le Detector à deux étages existe parce qu’exécuter un LLM sur chaque événement au volume de production (plus de 10 000 sessions/jour) coûterait prohibitivement cher — le Tier 1 court-circuite l’activité manifestement bénigne et n’escalade que les événements suspects vers le Tier 2, plus coûteux. L’Explorer hors ligne découvre en continu des « cas difficiles » et les consigne dans un dépôt de threat intelligence, de sorte que la détection s’améliore avant que les attaques n’atteignent la production, et non après.
Aucun exploit n’est reproduit ici, et ce n’est pas nécessaire pour comprendre l’architecture ; la référence canonique reste le papier et son dépôt.
Pourquoi c’est important
L’élément distinctif : il ne s’agit pas d’un prototype de laboratoire. ADR tourne chez Uber depuis plus de dix mois, atteignant plus de 7 200 hôtes uniques et traitant plus de 10 000 sessions d’agents par jour. En production, il a mis au jour des centaines d’expositions d’identifiants réparties en 26 catégories, partagés hors du réseau de l’entreprise, et a alimenté une couche de prévention « shift-left » affichant 97,2 % de précision (206 détectés sur 212 identifiants uniques, issus de centaines de milliers de sessions).
Sur le benchmark publié ADR-Bench (302 tâches — 42 malveillantes, 260 bénignes — sur 133 serveurs MCP et 17 techniques d’attaque), ADR rapporte zéro faux positif tout en détectant 67 % des attaques, devançant trois références (ALRPHFS, GuardAgent, LlamaFirewall) de 2 à 4× en F1. Les auteurs optimisent délibérément la précision : les méthodes de référence produisaient jusqu’à 40 faux positifs sur 260 tâches bénignes, soit en entreprise 40 déclenchements coûteux et inutiles de réponse à incident. Ce compromis — détecter deux tiers des attaques sans fausse alerte, plutôt que d’en détecter davantage en noyant le SOC — est la leçon pratique pour quiconque déploie une surveillance d’agents.
Défenses
ADR est lui-même la défense ; les enseignements portent donc sur la manière d’instrumenter et d’évaluer la surveillance des agents.
- Capturez la chaîne causale, pas seulement les résultats. Les journaux d’écriture de fichiers et d’appels d’API ne distinguent pas une exfiltration d’une sauvegarde de config. Reconstruisez prompt → raisonnement → appel d’outil pour rendre le comportement interprétable. Le Sensor le fait en analysant les caches locaux de l’outil agentique.
- Étagez la détection pour maîtriser le coût. Exécuter un LLM de raisonnement sur chaque événement ne passe pas à l’échelle. Triez d’abord avec un modèle économique à fort rappel, et réservez l’analyse contextuelle coûteuse aux événements signalés.
- Faites du red teaming hors ligne, en continu. Générez des variantes d’attaque difficiles avant déploiement et réinjectez-les dans la logique de détection, au lieu d’attendre que de nouvelles attaques apparaissent en production.
- Traitez l’exfiltration d’identifiants comme un signal de premier ordre. La principale découverte de terrain fut des identifiants quittant le réseau — surveillez-la explicitement, sur de nombreux formats.
- Optimisez la précision pour la production. Un garde-fou qui inonde le SOC de faux positifs ne survivra pas au contact des opérations. Rapportez votre point de fonctionnement (rappel et faux positifs), pas seulement un taux de détection accrocheur.
Statut
| Élément | Référence | Date | Notes |
|---|---|---|---|
| Système ADR | arXiv:2605.17380 | 2026-05-17 | Sensor + Detector à deux étages + Explorer hors ligne |
| Déploiement production | Uber | ~10 mois | 7 200+ hôtes, 10 000+ sessions/jour, 97,2 % de précision |
| ADR-Bench + code | github.com/uber/ADR | 2026-05 | 302 tâches, 133 serveurs MCP, 17 techniques |
| Résultat rapporté | ADR-Bench | 2026-05 | 0 faux positif, 67 % de détection, 2–4× F1 vs références |
À garder en tête : il s’agit d’un déploiement interne à un éditeur, avec des chiffres auto-rapportés, présenté comme un poster MLSys et non comme une évaluation indépendante. Le point durable et transposable est architectural : les agents MCP créent un angle mort d’observabilité que l’EDR classique ne comble pas, et le combler suppose une télémétrie native aux agents, une détection étagée et soucieuse du coût, et une boucle de rétroaction qui red-teame le détecteur avant les attaquants.