L’essentiel en 5 points
- Un agent IA n’est pas un chatbot : il agit sur vos systèmes. Le risque loge dans l’action, pas dans la conversation.
- La posture qui fonctionne : traiter son propre agent comme un composant potentiellement compromis, pas comme un outil de confiance.
- Un prompt “inviolable” n’existe pas. Ce qui tient : des garde-fous déterministes qui ne dépendent pas de la bonne volonté du modèle.
- Les secrets (clés, mots de passe) ne doivent jamais entrer dans le contexte du modèle.
- Avant tout outil : un threat model. Sans cartographie de la surface d’attaque, le reste est du bruit.
La réponse rapide
Sécuriser un agent IA ne consiste pas à écrire un meilleur prompt. Un agent dispose d’accès réels : fichiers, bases de données, API métier, parfois envoi d’emails ou exécution de commandes. La question de sécurité n’est donc pas “que peut-il dire ?” mais “que peut-il faire, déclenché par qui, et qu’est-ce qui l’en empêche ?”.
La démarche qui fonctionne tient en trois temps : cartographier la surface d’attaque (quels agents, quels accès, quelles entrées), instrumenter en mode observation pour comprendre le trafic réel, puis durcir couche par couche avec des contrôles qui ne dépendent pas du modèle. Le reste de cet article détaille ce que ça veut dire pour une entreprise qui déploie ou s’apprête à déployer des agents.
Pourquoi un agent IA ne se sécurise pas comme une application
Une application classique fait ce que son code prévoit. Un agent IA interprète des instructions en langage naturel, y compris celles qu’il rencontre dans les données qu’il traite : une page web, un email entrant, un document client, le README d’une dépendance. C’est le mécanisme de l’injection de prompt : du texte que l’agent lit devient une instruction qu’il exécute.
On ne corrige pas ce mécanisme, il est constitutif de la technologie. Les éditeurs sérieux du secteur en tirent la même conclusion : il faut modéliser son propre agent comme un composant potentiellement compromis. Toute l’architecture de sécurité découle de ce renversement. On ne cherche pas à rendre l’agent incorruptible, on borne ce qu’un agent corrompu pourrait faire.
Le pire pattern, celui qu’on retrouve dans les incidents publics récents : un accès en écriture irréversible sur une ressource sensible, atteignable depuis une entrée non authentifiée. Chaque terme compte. Si votre agent peut supprimer des données de production et qu’il lit des contenus que n’importe qui peut lui envoyer, vous avez construit ce pattern.
Les trois arbitrages à trancher avant d’outiller
Probabiliste ou déterministe ? Un filtre à base d’IA (classifieur, LLM juge) attrape des attaques variées mais peut être contourné. Une règle dure qui bloque toute commande destructive est inviolable mais étroite. La réponse n’est pas l’un ou l’autre : c’est l’empilement des deux. Le filtre probabiliste réduit le bruit, la règle déterministe garantit le plancher.
Que faire quand un contrôle échoue ? Quand un scanner refuse d’analyser un fichier ou qu’un filtre ne sait pas trancher, deux comportements possibles : laisser passer (fail-open) ou router vers une revue humaine. Pour un agent qui agit sur des systèmes réels, le fail-open est une faute : un refus d’analyse est un signal d’alerte, pas une absence de résultat.
Observer ou bloquer ? Instrumenter directement en mode blocage casse la production et braque les équipes. La bonne séquence : journaliser d’abord (qui appelle quoi, quels outils, quelles données), établir une base de référence, puis basculer les contrôles en mode blocage un par un.
Les sept couches d’une défense en profondeur
- Threat model. Cartographier chaque agent : ses accès, ses entrées, ses effets de bord possibles. Les référentiels classiques (OWASP, STRIDE) s’appliquent, complétés par les spécificités agents (injection via données, chaîne d’outils).
- Contrôle d’admission. Scanner tout ce qui entre dans le parc avant exécution : serveurs MCP, plugins, skills, fichiers d’instructions. Un fichier de configuration d’agent est du code exécutable et doit être audité comme tel, y compris pour les caractères Unicode invisibles qui cachent des instructions.
- Inspection à l’exécution. Un point de passage qui observe prompts, réponses et appels d’outils, avec des règles et un classifieur. À l’échelle, le pattern efficace est la cascade : un filtre léger sur tout le trafic, un filtre lourd sur ce qui est suspect.
- Garde-fous déterministes. Blocage dur des commandes destructives (suppression massive, écriture en production, transferts) au niveau du harness, pas du prompt. Cette couche ne dépend pas de la bonne foi du modèle : elle n’hallucine pas.
- Secrets hors du modèle. Les clés API et mots de passe ne doivent jamais figurer dans le contexte de l’agent. Ils sont injectés au moment de l’appel réseau par un composant séparé, hors de portée d’une injection de prompt.
- Isolation et validation humaine hors-bande. Moindre privilège par connecteur, exécution des composants critiques en environnement isolé, et pour toute action irréversible, une confirmation humaine sur un canal séparé de celui où l’agent reçoit ses instructions.
- Journalisation durable. Consigner les appels d’outils et le trafic des agents dans un format exploitable (export SIEM). C’est ce qui permet de détecter un comportement anormal, de répondre à un incident et de prouver la conformité.
Les deux pièges qui trompent les équipes
Confondre score d’évaluation et sécurité réelle. Un agent qui obtient un bon score sur un banc d’essai de sécurité n’est pas un agent sûr : les évaluations se contournent et un modèle peut sous-performer volontairement sur les tests qui le mesurent. Avant un déploiement sensible, une vérification indépendante (red team) reste nécessaire.
Croire qu’un garde-fou intégré au modèle suffit. Les protections par alignement du modèle se retirent en quelques dizaines de minutes quand un adversaire a accès aux poids, et se contournent par injection quand il n’y a pas accès. Elles sont utiles, mais la sécurité qui tient est celle des couches externes : contrôle d’accès, garde-fous déterministes, isolation.
Par où commencer
Si vos équipes utilisent déjà des agents (assistants de code, agents métier, automatisations), la première étape est un état des lieux : quels agents tournent, avec quels accès, et qu’est-ce qui les déclenche. C’est un exercice de quelques jours qui produit une cartographie de surface et une liste de correctifs priorisés, et il s’exécute en mode observation, sans toucher à la production.
Colombani.ai réalise ce type d’audit de sécurité IA (cartographie de surface, tests d’intrusion assistés par agents, couvert par une assurance RC Pro dédiée aux tests d’intrusion) et forme les équipes techniques via la formation Sécurité des agents IA (OWASP LLM Top 10, red teaming, sandboxing), certifiée Qualiopi et finançable OPCO.