Lire les emails, modifier un fichier, interroger une base clients, exécuter du code ou déclencher un paiement : les agents IA en entreprise ne se contentent plus de répondre à des questions. Ils peuvent agir directement dans les systèmes informatiques. Cette autonomie promet d’importants gains de productivité, mais transforme une erreur ou une instruction malveillante en véritable incident de sécurité.
Le NIST avertit justement que les protections conçues pour les modèles d’IA classiques ne suffisent pas toujours aux agents. Avant de leur ouvrir les outils internes, quelques règles deviennent donc indispensables.
Un agent IA ne doit jamais recevoir les mêmes droits qu’un salarié
La première règle consiste à appliquer le principe du moindre privilège. Un agent chargé de résumer des factures n’a aucune raison de pouvoir les supprimer. Celui qui consulte un agenda n’a pas nécessairement besoin d’envoyer des emails.
OWASP recommande d’attribuer uniquement les outils indispensables à chaque mission et de distinguer clairement les droits de lecture et d’écriture. Les autorisations doivent également être contrôlées par les systèmes informatiques eux-mêmes, et non simplement inscrites dans le prompt de l’agent.
Chaque agent devrait aussi posséder sa propre identité numérique. Il devient alors possible de savoir précisément lequel a consulté un document, utilisé une API ou modifié une donnée.
Le NIST travaille justement sur cette question. L’organisme estime que l’identification et l’autorisation des agents deviennent essentielles dès qu’ils accèdent à plusieurs applications et ensembles de données.
Une entreprise devrait donc pouvoir répondre immédiatement à quatre questions : quel agent agit, pour quel utilisateur, avec quelles autorisations et pendant combien de temps ?
Paiements, suppressions, emails : garder un humain devant le bouton
L’autonomie doit ensuite dépendre du niveau de risque.
Un agent peut rechercher automatiquement une information ou classer des documents. En revanche, supprimer une base de données, envoyer un contrat, modifier des droits administrateur ou effectuer un paiement ne devrait pas suivre la même logique.
OWASP recommande une validation humaine explicite pour les opérations à fort impact. L’utilisateur doit pouvoir visualiser l’action prévue avant son exécution.
Cette validation doit porter sur l’opération exacte. Autoriser un agent à effectuer un virement de 500 euros vers un bénéficiaire précis ne devrait pas lui donner une permission générale d’effectuer d’autres paiements.
Un mécanisme d’arrêt constitue également une protection essentielle. L’entreprise doit pouvoir couper rapidement l’accès d’un agent à ses outils ou à Internet lorsqu’un comportement anormal apparaît.
Enfin, toutes les actions sensibles doivent laisser des traces. Sans journaux détaillés, comprendre après coup pourquoi un agent a envoyé un fichier confidentiel ou modifié une configuration devient beaucoup plus difficile.
La checklist avant de connecter un agent aux données de l’entreprise
Avant tout déploiement, une entreprise peut vérifier ces dix points :
- chaque agent possède une identité distincte ;
- ses autorisations sont limitées au strict nécessaire ;
- les droits de lecture et d’écriture sont séparés ;
- les accès sensibles utilisent des autorisations temporaires ;
- les paiements, suppressions et modifications critiques nécessitent une validation humaine ;
- les documents, emails et pages Web externes sont considérés comme potentiellement malveillants ;
- l’exécution de code s’effectue dans un environnement isolé ;
- toutes les actions importantes sont journalisées ;
- des limites existent sur les coûts, tentatives, boucles et appels d’outils ;
- l’agent peut être désactivé immédiatement en cas d’incident.
Ces précautions répondent notamment aux principales menaces identifiées par OWASP : injection de prompt, détournement d’objectif, fuite de données, abus d’outils, empoisonnement de mémoire ou propagation d’une attaque entre plusieurs agents.
Les tests doivent enfin précéder le passage en production. OWASP recommande notamment de simuler des tentatives d’escalade de privilèges, de fuite de données ou de contournement des validations humaines. Ces tests doivent être répétés après une modification importante du modèle, des outils ou de la mémoire.
La question n’est donc pas de savoir si un agent IA est suffisamment intelligent pour travailler seul. Il faut déterminer jusqu’où l’entreprise peut le laisser agir lorsque quelque chose tourne mal.
Un bon agent n’est pas celui auquel on donne toutes les clés. C’est celui qui peut accomplir sa mission avec le minimum de clés possible.
