La journée avait commencé comme les autres. Café, standup, revue de code. Puis j’ai entendu parler d’un incident qui m’a fait tout lâcher.
L’agent IA d’une organisation venait d’être compromis. Pas via un zero-day exotique ou un vecteur d’attaque sophistiqué. Non, c’était bien plus élégant (et terrifiant). Leur agent de navigation piloté par LLM avait mergé de façon autonome une pull request malveillante sur GitHub. En tant que vrai employé. Avec de vraies permissions.
Le vecteur d’attaque ? Un email soigneusement rédigé qui attendait dans la boîte de réception de l’utilisateur, contenant des instructions que l’agent a interprétées comme des commandes légitimes.
Le modèle n’a rien fait de mal
Ce qui me tient éveillé la nuit : le LLM a parfaitement fonctionné. Il a lu le contenu, compris l’intention, et agi exactement comme prévu. L’échec catastrophique n’était pas dans l’IA. Il était dans l’architecture.
Quelqu’un a donné à un agent IA un accès navigateur sans restriction, avec tous les privilèges d’un utilisateur connecté. C’est comme confier ses clés de voiture à quelqu’un qui sait très bien lire une carte mais n’a jamais entendu parler du code de la route.
Sécurité des agents : état des lieux (spoiler : c’est préoccupant)
J’ai passé en revue des dizaines d’architectures d’agents cette année. Les modèles de sécurité vont de « inexistant » à « croisons les doigts ». L’approche classique :
- Donner à l’agent un accès large
- Espérer qu’il prend de bonnes décisions
- ?? ?
- Profit (ou se faire pwner)
C’est fondamentalement cassé. On construit des agents comme si on était en 2010 et que le principe du moindre privilège n’avait jamais existé.
Ce qui fonctionne vraiment
Après avoir contribué à l’architecture de plus de 100 applications basées sur des LLM chez Redis, et maintenant en construisant Arcade.dev, voici ce que j’ai appris pour créer des agents qui ne vont pas faire sauter votre infrastructure :
1. Principe du moindre privilège (à appliquer vraiment)
Votre agent ne doit jamais avoir plus d’accès que strictement nécessaire pour la tâche en cours.
- Lire des emails ? Accès en lecture seule à la boîte de réception
- Envoyer un message ? Accès à la rédaction, pas à la suppression
- Revoir des PR ? Accès en lecture, jamais le droit de merger
En clair : donner votre token utilisateur à un agent est une très mauvaise idée. Vous ne me croyez pas ? Attendez que les attaquants deviennent meilleurs en prompt injection. Vous le regretterez.
2. Sandboxing d’exécution
Faire tourner les outils dans des environnements isolés n’est pas de la paranoïa, c’est le minimum syndical. Conteneurisation, processus séparés, restrictions au niveau API : il vous faut des barrières entre ce qu’un agent tente de faire et les dégâts qu’il peut causer.
Chez Arcade.dev, chaque outil tourne dans son propre environnement sandboxé. Un agent ne peut même pas voir les outils auxquels il ne devrait pas avoir accès, encore moins les exécuter.
3. Tout auditer (et je veux dire absolument tout)
Chaque appel d’outil, chaque décision, chaque donnée consultée doit être journalisée. Pas seulement pour la conformité, mais pour l’analyse forensique quand les choses tournent mal. Et elles tourneront mal.
Ce n’est pas de l’observabilité classique. Vous devez capturer :
- Le raisonnement derrière chaque appel d’outil
- Tous les paramètres transmis
- Les résultats complets retournés
- Et surtout : qui l’a approuvé
4. Disjoncteurs humains
Les actions critiques nécessitent une approbation humaine. Un point c’est tout.
Votre agent peut rédiger l’email, préparer le commit, planifier la migration de base de données, ou trier les incidents pour les workflows SRE. Mais c’est un humain qui doit appuyer sur le bouton. Oui, ça réduit l’autonomie. Ça évite aussi que votre agent supprime la prod parce que quelqu’un lui a demandé de « nettoyer la base de test » dans un message Slack formulé de façon ambiguë.
La vérité qui dérange
L’attaque via agent de navigation a révélé ce qu’on évitait de regarder en face : on donne des capacités aux agents IA sans les garde-fous correspondants. C’est de l’ingénierie irresponsable.
Les plateformes qui s’en sortent bien traitent la sécurité comme une architecture fondamentale, pas comme une case à cocher. Elles :
- Appliquent des permissions limitées à l’utilisateur par défaut
- Valident chaque action par rapport à une politique
- Fournissent des pistes d’audit sans que vous ayez à y penser
- Font du chemin sécurisé le chemin le plus simple
Construire la confiance par l’architecture
Voilà la réalité : construire des agents dignes de confiance, ce n’est pas brider les capacités de l’IA. C’est les canaliser de façon sûre.
Chez Arcade.dev, toute notre plateforme est construite autour de ce principe. Chaque intégration utilise OAuth avec des permissions granulaires. Chaque appel d’outil est limité à l’utilisateur qui l’a autorisé. Chaque action est journalisée et auditable. Non pas parce qu’on se méfie de l’IA, mais parce qu’on comprend que la sécurité est ce qui rend la confiance possible.
L’agent qui a mergé du code malveillant n’était pas mal entraîné. Il n’utilisait pas un modèle inférieur. On lui avait simplement donné trop de pouvoir avec trop peu de supervision.
Ne laissez pas cette histoire devenir votre leçon par l’exemple.
Sam Partee est CTO et co-fondateur d’Arcade.dev, où il construit l’infrastructure pour des agents IA sécurisés et prêts pour la production. Auparavant Ingénieur IA Principal chez Redis, il a contribué à l’architecture de plus de 100 applications basées sur des LLM. Grand contributeur à Langchain et LlamaIndex, il est convaincu que l’avenir de l’IA réside dans ce qu’elle peut faire, pas seulement dans ce qu’elle peut dire.
Vous voulez construire des agents qui agissent sans tout casser ? Découvrez Arcade.dev ou retrouvez-moi sur Twitter.
