Sécuriser des agents IA en entreprise

L’essentiel en 5 points

• Un agent IA n’est pas un chatbot : il agit sur vos systèmes. Le risque tient à ce qu’il fait, non à ce qu’il dit.
• La bonne approche consiste à considérer votre propre agent comme un composant potentiellement compromis, et non comme un outil de confiance.
• Un prompt “inviolable” n’existe pas. Seuls des garde-fous déterministes, indépendants de la bonne volonté du modèle, résistent à une attaque.
• 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, les outils ajoutent des alertes sans réduire le risque.

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 ?”.

Une démarche efficace comporte 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. La suite de cet article détaille ce que cela implique pour une entreprise qui déploie des agents ou s’apprête à le faire.

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.

Ce mécanisme ne se corrige pas : il est inhérent à 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. Il ne s’agit pas de rendre l’agent incorruptible, mais de limiter ce qu’un agent corrompu pourrait faire.

La configuration la plus dangereuse, observée 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. Les trois conditions sont nécessaires. Si votre agent peut supprimer des données de production et lit des contenus que n’importe qui peut lui envoyer, vous êtes exactement dans cette situation.

Les trois questions à trancher avant de choisir des outils

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 écarte une grande partie des attaques, la règle déterministe garantit un niveau minimal de protection.

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 ? Activer d’emblée le mode blocage perturbe 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

1. 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).
2. 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.
3. Inspection à l’exécution. Un point de passage qui observe prompts, réponses et appels d’outils, avec des règles et un classifieur. Lorsque le trafic est important, la méthode efficace est la cascade : un filtre léger sur l’ensemble du trafic, un filtre lourd sur ce qui paraît suspect.
4. Garde-fous déterministes. Blocage des commandes destructives (suppression massive, écriture en production, transferts) dans l’environnement d’exécution de l’agent, et non dans le prompt. Cette couche ne dépend pas de la bonne foi du modèle : elle n’hallucine pas.
5. 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.
6. 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.
7. 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 les plus fréquents

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 obtenir volontairement de moins bons résultats aux 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 protection réelle vient 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. Cet exercice de quelques jours aboutit à une cartographie de la surface d’attaque et à une liste de correctifs classés par priorité ; il se mène 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), dispensée par un organisme certifié Qualiopi, finançable par votre OPCO.

Sources

• OWASP, Top 10 des risques pour les applications LLM
• NIST, AI Risk Management Framework
• Anthropic, concevoir des agents fiables