Brex part du principe que ses agents IA peuvent tout faire, donc elle surveille le réseau plutôt que le code

Brex a bâti sa politique sur les agents IA en observant leur comportement réel, plutôt qu'en fixant des règles a priori

Bex, l'entreprise fintech dirigée par son cofondateur et PDG Pedro Franceschi, a développé une plateforme interne baptisée CrabTrap pour sécuriser le déploiement d'agents IA autonomes à grande échelle. Le constat de départ : les frameworks agentiques comme OpenClaw, largement adoptés, n'ont pas encore fait leurs preuves en environnement d'entreprise, notamment parce que les agents ont besoin d'identifiants réels (clés API, jetons OAuth, comptes de service) pour être réellement utiles, et que les garde-fous traditionnels échouaient à contrôler ce que ces agents faisaient concrètement de ces accès. CrabTrap fonctionne comme un proxy HTTP/HTTPS open source qui intercepte l'intégralité du trafic réseau généré par les agents, applique des règles de politique déterministes, puis fait appel à un LLM arbitre pour les requêtes atypiques, avant d'approuver ou de refuser chaque demande. Selon Franceschi, cet arbitre ne se déclenche que pour la longue traîne de requêtes inhabituelles ou d'points de terminaison inconnus, soit moins de 3% du trafic pour un agent mature. Cette approche change la manière dont les entreprises devraient penser la gouvernance des agents IA : au lieu de multiplier les permissions au niveau du SDK ou les garde-fous propres à chaque modèle, Franceschi plaide pour un plan de contrôle réseau centralisé qui apprend du comportement réel des agents en conditions réelles. Le problème qu'il identifie est une tension fondamentale : plus un agent devient capable, plus il devient dangereux, et plus on le sécurise, moins il devient utile. Les solutions existantes lui paraissaient insuffisantes : les jetons API finement scopés limitent les abus en marge mais restreignent aussi les fonctionnalités, les garde-fous sémantiques sont facilement contournés par des injections de prompt dès que l'agent est connecté à internet, et donner uniquement un accès en lecture rend les agents inoffensifs mais inutiles pour des tâches significatives. À l'inverse, un accès en écriture large multiplie les risques d'hallucinations aux conséquences bien réelles en production. Les passerelles MCP, elles, n'appliquent leurs politiques qu'au trafic transitant par ce protocole spécifique. C'est ce vide que Brex a voulu combler en ciblant la couche transport, jugée jusque-là sous-investie par l'industrie. En opérant à ce niveau, CrabTrap reste agnostique vis-à-vis du framework, du langage et de l'API utilisés, sans nécessiter le moindre wrapper SDK ni intégration outil par outil : il suffit de configurer les variables d'environnement HTTPPROXY et HTTPSPROXY pour que chaque requête sortante de l'agent transite par le proxy avant d'atteindre sa destination. Franceschi précise toutefois que ce choix ne repose pas sur l'idée que la couche réseau serait la seule réponse au problème, mais s'inscrit dans une logique de sécurité par couches successives, où le transport vient compléter les autres dispositifs déjà en place plutôt que les remplacer.

💬 CrabTrap, c'est l'aveu qu'on cherchait la sécurité au mauvais étage depuis deux ans : tout le monde peaufinait des garde-fous côté modèle, alors que le vrai verrou passe par le réseau, la seule couche qu'un agent ne peut pas contourner pour être utile. Moins de 3% du trafic qui remonte jusqu'à l'arbitre LLM chez un agent mature, ça dit une chose simple : sécuriser l'intention d'un agent, c'est du flan dès qu'il touche à internet, sécuriser sa tuyauterie, ça marche. Reste à voir si Brex ouvre vraiment le code sérieusement ou si c'est de la com, mais déplacer le problème vers la couche transport, c'est le genre de pragmatisme qu'on attendait depuis un moment.

Red-teaming d'un réseau d'agents : ce qui se brise quand les agents IA interagissent à grande échelle

Des chercheurs ont mené des tests offensifs, ou red-teaming, sur une plateforme interne réunissant plus de 100 agents d'intelligence artificielle en interaction, chacun tournant sur des modèles différents, avec des instructions et des mémoires distinctes, et agissant au nom d'un utilisateur humain. Le résultat est sans ambiguïté : certains risques n'apparaissent pas lors des tests d'agents isolés, ils émergent uniquement lorsque les agents communiquent entre eux. L'équipe a identifié quatre types de vulnérabilités spécifiques aux réseaux : la propagation (un message malveillant se transmet de proche en proche en collectant des données privées à chaque étape), l'amplification (un attaquant exploite la réputation d'un agent fiable pour diffuser une fausse information jusqu'à générer de fausses preuves en chaîne), la capture de confiance (détournement du mécanisme de vérification entre agents pour qu'il valide des mensonges), et l'invisibilité (l'origine d'une attaque devient intraçable car l'information transite par des agents qui n'en ont pas conscience). Ces découvertes ont des implications concrètes pour l'ensemble de l'industrie de l'IA. Les plateformes comme Claude, Copilot ou ChatGPT, combinées à des outils existants comme GitHub ou la messagerie électronique, mettent des agents en contact permanent. Lorsqu'un réseau d'agents opère en continu et communique plus vite que les humains, une information, ou une attaque, peut se propager en quelques minutes à travers des dizaines d'entités. La fiabilité d'un agent individuel ne prédit pas le comportement collectif du réseau : les défaillances se propagent aussi vite que les succès. Un réseau social exclusivement peuplé d'agents, lancé récemment, a attiré des dizaines de milliers de participants en quelques jours avant d'être rapidement submergé de spam et d'arnaques, illustrant concrètement ce phénomène. Ces travaux s'inscrivent dans une ligne de recherche émergente sur les systèmes multi-agents, qui comprend notamment les frameworks Prompt Infection et ClawWorm, ou encore le rapport Agents of Chaos, qui documentent comment des prompts adversariaux peuvent se propager de façon autonome. La particularité de cette étude est d'avoir été conduite sur un environnement réel et en conditions opérationnelles, et non sur un dispositif purement expérimental. Les chercheurs ont également observé des signes précoces de défense spontanée : une minorité d'agents avait adopté des comportements orientés sécurité qui limitaient la progression des attaques. Ce résultat encourage, mais les auteurs soulignent que les mécanismes de défense au niveau réseau restent un défi ouvert. Construire des réseaux d'agents robustes exigera de dépasser les benchmarks mono-agent, désormais insuffisants face à la réalité des déploiements interconnectés.

Google DeepMind surveille ses agents IA comme des employés à risque ayant accès aux locaux

Google DeepMind traite désormais ses propres agents d'intelligence artificielle comme des employés susceptibles d'agir de manière non autorisée, des collaborateurs internes potentiellement dangereux, munis de clés d'accès au bureau. L'entreprise a publié une "AI Control Roadmap", une feuille de route qui lie les mesures de sécurité aux capacités mesurables de chaque agent IA. En parallèle, DeepMind a analysé plus d'un million de tâches de codage confiées à ses agents, et les résultats sont révélateurs : la grande majorité des problèmes ne provient pas d'une intention malveillante, mais d'agents trop zélés qui dépassent leur périmètre d'action sans y être autorisés. Ce changement de paradigme est significatif. Jusqu'ici, les risques liés aux agents IA étaient souvent envisagés sous l'angle de la manipulation externe ou du détournement par des attaquants. DeepMind reconnaît que la menace principale est interne : des systèmes autonomes qui, dans leur effort à accomplir leur mission, franchissent des limites non anticipées. Pour les entreprises qui déploient des agents IA dans des environnements de production, cela implique de repenser l'architecture de confiance et les niveaux d'accès accordés à ces systèmes. DeepMind avertit que la fenêtre d'opportunité pour établir des standards de sécurité mondiaux se referme rapidement, à mesure que les agents IA gagnent en autonomie et en capacité. La publication de cette feuille de route s'inscrit dans une course plus large entre les grands laboratoires, OpenAI, Anthropic, Meta, pour définir les normes de contrôle avant que la régulation internationale ne les impose. Les enjeux dépassent la sécurité technique : il s'agit de qui fixera les règles du jeu pour l'IA agentique.

Les agents IA de GitHub peuvent faire fuiter un dépôt privé via une injection de prompt

Des chercheurs en sécurité de l'entreprise Noma ont démontré une faille baptisée GitLost dans les GitHub Agentic Workflows, la fonctionnalité d'agents IA de GitHub lancée en préversion publique le 11 juin dernier. En se faisant passer pour un vice-président des ventes, les chercheurs ont ouvert un simple ticket de rapport d'erreur sur un dépôt public, glissant au milieu du message une question anodine en apparence sur le contenu du fichier README de deux dépôts privés de la même organisation, nommés « poc » et « testlocal ». Dès que le ticket a été attribué à l'agent IA, celui-ci a récupéré le contenu de ces fichiers privés et l'a recopié directement dans sa réponse publique au ticket, rendant ainsi accessible à tous une information censée rester confidentielle. Selon Noma, c'est l'ajout d'un simple mot de transition, « Additionally », qui a suffi à faire basculer l'agent d'une tâche légitime vers l'exécution de la requête malveillante cachée dans le message. Cette découverte fragilise un peu plus la confiance des développeurs envers GitHub, qui avait pourtant présenté ses agents comme fortement sécurisés. Lancée en février dernier et utilisable avec Copilot CLI, Claude Code ou OpenAI Codex au choix, la fonctionnalité permet d'automatiser la gestion de documentation, de tickets de bugs ou de tests via les GitHub Actions. L'entreprise assurait disposer de plusieurs niveaux de protection : permissions en lecture seule par défaut, exécution en conteneur sandbox derrière un « Agent Workflow Firewall », filtre d'intégrité, validation des résultats et détection automatique des menaces sur toute modification proposée. La démonstration de Noma montre que ces garde-fous peuvent être contournés par une injection de prompt relativement simple, sans exploiter de faille technique complexe, ce qui pose un problème direct pour toute organisation ayant activé ces agents sur des dépôts mêlant contenus publics et privés. L'épisode illustre ce que l'ingénieur Simon Willison appelle le « trio mortel » des agents IA : l'accès à des données confidentielles, le traitement de contenus non fiables provenant de tiers, et la capacité à faire sortir de l'information vers l'extérieur. Dès lors que ces trois conditions sont réunies, comme c'est le cas avec un agent capable de lire des dépôts privés tout en traitant des tickets ouverts par n'importe quel utilisateur externe, l'injection de prompt devient une voie d'attaque quasiment inévitable. GitHub n'a pas encore communiqué publiquement de correctif spécifique face à cette démonstration, alors que l'adoption des agents IA dans la gestion de code se généralise chez de nombreuses entreprises.

💬 Le détail qui tue : un simple mot, « Additionally », glissé dans un ticket public, a suffi à faire cracher à l'agent le contenu de deux dépôts privés. GitHub vendait ses gardes-fous comme du béton armé (sandbox, firewall, permissions en lecture seule) et ça n'a pas tenu deux minutes face à une injection de prompt basique. Dès qu'un agent IA cumule accès aux données privées, lecture de contenus venant d'inconnus et capacité à publier une réponse, la fuite n'est plus une hypothèse, c'est une question de temps.