Les agents de développement par IA ne sont plus seulement des essais individuels. Ils entrent dans les environnements de travail des entreprises, et le dépôt ADR ouvert par Uber est intéressant pour cette raison. Il ne traite pas Claude Code, Cursor, OpenAI Codex CLI, Cline, Claude Desktop, Warp Terminal ou opencode comme de simples éditeurs avec autocomplétion. Ce sont des systèmes qui lisent des prompts, observent des dépôts, choisissent des outils, lancent un shell, modifient des fichiers, utilisent des serveurs MCP et croisent parfois des données proches de secrets. Cette chaîne reste trop peu visible si la sécurité ne regarde que les processus et les fichiers.

Console de sécurité suivant les actions d’agents de développement IA

Ce qu’Uber a publié

ADR signifie ici Agentic Detection and Response, pas l’acronyme habituel des décisions d’architecture. Le dépôt le présente comme un système de sécurité d’entreprise pour agents IA et indique qu’il a été déployé chez Uber. Au moment de la publication, il était sous licence Apache-2.0, principalement en Python, avec environ 1 334 étoiles et 112 forks, et une mise à jour le 10 août 2026. Les chiffres ne suffisent pas, mais ils montrent l’intérêt du sujet.

Le projet n’est pas un scanner magique. Il articule observabilité, benchmark, détection et prévention. La publication open source contient le sensor, ADR-Bench et le detector. La prévention et une partie des outils internes d’exploration ne sont pas incluses. Cette limite compte: le dépôt peut servir d’architecture de référence, pas de contrôle SOC prêt à l’emploi.

L’article accepté à MLSys 2026 Industry Track donne le contexte le plus solide. Son résumé cite trois difficultés: observabilité limitée, robustesse insuffisante et coût élevé de la détection. Il indique aussi plus de dix mois d’exploitation chez Uber, plus de 7 200 hôtes uniques et plus de 10 000 sessions d’agents par jour. Ce sont des résultats déclarés par Uber, pas une garantie universelle.

Pourquoi EDR et SIEM ne suffisent pas

Un EDR classique sait dire quel processus a écrit un fichier, quel binaire a ouvert une connexion, quel hôte a contacté un domaine suspect. Cela reste indispensable. Mais un agent ajoute une couche entre l’intention humaine et l’événement système. Une commande shell peut sembler normale et devenir risquée si elle provient d’une injection dans une issue, un document ou une réponse MCP.

La question utile devient plus large: qu’a demandé l’utilisateur, quel contexte le modèle a-t-il lu, quel plan a-t-il exposé, quels tool calls ont été proposés et exécutés, quelle politique s’appliquait, quel résultat a suivi? Sans cette chaîne de session, le SOC voit le symptôme mais pas la cause.

Le Sensor README décrit des parsers pour Claude Code, Cursor IDE, Cline, Claude Desktop, OpenAI Codex CLI, Warp Terminal et opencode, avec des différences selon macOS, Linux et Windows. Les événements sont normalisés avec session ID, timestamp, chat history, tools, model, project path et session context. C’est précisément le vocabulaire qui manque souvent à l’EDR.

Le risque des outils et de MCP

La puissance d’un agent vient de la frontière des outils. Il devient opérationnel lorsqu’il peut lire un dépôt, appeler git, lancer des tests, consulter une documentation interne, modifier un ticket, utiliser un helper de déploiement ou joindre un serveur MCP. Chaque connecteur peut être légitime; ensemble ils forment un graphe de droits difficile à voir.

ADR-Bench traite ce graphe comme une surface de détection. La documentation mentionne environ trois cents scénarios, dont 303 dans le README Detection, avec 261 bénins, 42 malveillants, 17 techniques d’attaque et 133 serveurs MCP. L’essentiel est le type d’épreuve: des agents confrontés à des instructions hostiles, des secrets synthétiques et des services vulnérables dans des flux proches du travail réel.

Les notes open source préviennent aussi que le benchmark inclut du matériel d’attaque synthétique et des dépendances fixées avec des CVE connus pour la reproductibilité. Il faut l’exécuter dans un environnement isolé, pas en production.

Ce que les équipes doivent changer

Pour un CTO, un CISO ou une équipe plateforme, la réponse n’est ni l’interdiction générale ni l’installation aveugle d’un dépôt. Il faut d’abord inventorier les agents autorisés, leurs journaux, les systèmes couverts, les dépôts accessibles et les actions qu’ils peuvent exécuter sans revue humaine permanente.

Ensuite vient le moindre privilège. Un agent ne devrait pas hériter automatiquement de toutes les clés, permissions shell et sessions navigateur du développeur. Gateways de secrets, tokens courts, permissions limitées au dépôt, comptes de développement dédiés et règles explicites pour MCP deviennent des bases.

L’auditabilité est la troisième pièce. Les logs doivent relier prompt, tool call et résultat. Mais tout enregistrer serait dangereux: la télémétrie peut contenir code, tickets internes, données client ou chaînes ressemblant à des secrets. Un programme de type ADR doit donc prévoir rétention limitée, masquage, contrôle d’accès, chiffrement et export SIEM prudent.

Ce que cela change pour la sécurité

Une session d’agent suspecte ne ressemble pas forcément à un malware. Elle peut être une machine de développement normale, un éditeur normal et un terminal légitime. L’anomalie peut être une séquence d’outils, un motif de prompt, une lecture soudaine d’emplacements de secrets, un script généré qui sort du réseau attendu ou un serveur MCP qui transforme une consultation en action.

Les règles doivent combiner le contexte. La télémétrie de processus est trop pauvre, le scan de prompts trop fragile et la seule sortie du modèle ne prouve pas l’exécution. L’unité utile est la session: entrées, contexte, outils, effets sur fichiers et réseau, décisions de politique. Les équipes mûres demanderont des détections capables d’expliquer le risque.

Le marché va suivre. IDE, workspaces cloud, terminaux, frameworks d’agents et plateformes MCP devront fournir des logs structurés et exportables. Sans format exploitable, l’adoption en entreprise et la réponse à incident resteront coûteuses.

Le signal plus large

Le fil Hacker News directement consacré à ADR était modeste, mais les discussions voisines sur agents cloud, gateways de credentials et sandboxes ont été plus animées. Elles posent toutes la même question: où l’agent s’exécute-t-il, quels secrets voit-il, quelle isolation existe, qui répond lorsqu’une automatisation dépasse la limite?

ADR s’inscrit donc dans un mouvement vers une infrastructure d’agents gérée. Comme le cloud avant lui, l’usage commence souvent par les équipes, puis appelle identité, journalisation, politique, contrôle des coûts et réponse à incident. Les agents commencent dans le terminal du développeur, mais le risque appartient à l’entreprise.

Une organisation peut commencer simplement: carte des outils approuvés, réduction des secrets ambiants, collecte des journaux disponibles, corrélation avec Git, pull requests et CI, puis tests dans un dépôt isolé avec secrets synthétiques. Si l’équipe ne peut pas voir qu’un agent a lu un fichier sensible, suivi une instruction hostile ou modifié du code hors périmètre, le backlog de sécurité est déjà clair.

La conclusion est nette: les agents de code ne sont ni de simples éditeurs ni des employés. Ce sont des systèmes délégués qui transforment prompts et contexte en actions. Le prochain stade de l’IA en entreprise dépendra de la capacité à rendre ces actions observables, bornées, revues et récupérables.