Un collaborateur demande à son assistant IA interne : “Pourrais-tu me retrouver la grille des salaires ?”
La scène paraît assez banale. L’utilisateur est bien connecté. L’agent sait utiliser l’outil documentaire de l’entreprise. L’agent comprend la demande faite par le collaborateur. Techniquement, tout semble prêt pour fonctionner.
Toutefois, il manque une question indispensable : cet utilisateur a-t-il réellement le droit de consulter cette ressource ?
C’est précisément ici que la sécurité des agents IA change de nature. Un chatbot répond. Un agent agit. Il peut lire un fichier, appeler une API, interroger un dépôt documentaire, déclencher un workflow, préparer une modification ou transmettre une information à un autre outil. Le risque ne se limite donc plus à ce que l’IA écrit dans une fenêtre de conversation. Il concerne ce qu’elle peut faire dans le système d’information.
L’OWASP a publié un Top 10 dédié aux risques de l’IA agentique, justement parce que ces systèmes ne produisent plus seulement du texte : ils planifient, utilisent des outils, appellent des API et peuvent déclencher des actions. Parmi les scénarios identifiés figurent le détournement d’objectif, l’usage abusif d’outils, l’abus de privilèges, l’exécution de code inattendue ou encore les agents devenus incontrôlables (OWASP GenAI Security Project).
Prenons un cas concret. Une entreprise déploie un assistant interne connecté à plusieurs espaces documentaires : documents communs, fichiers techniques, informations RH. Un profil métier peut consulter les documents communs. Un profil technique peut accéder aux documents communs et techniques. Un administrateur dispose de droits plus larges.
Le problème n’est pas que l’agent utilise un outil légitime. Le problème est plus fin : quelle action demande-t-on à l’agent, sur quelle ressource, pour quel utilisateur et dans quel contexte ?
Un outil peut être autorisé, mais mal utilisé. Un utilisateur peut être authentifié, mais demander une action qui dépasse son périmètre. Un agent peut avoir accès à une API, mais l’appeler avec des paramètres dangereux. Un script peut sembler utile, mais tenter de lire des secrets ou d’ouvrir une connexion sortante non prévue.
C’est pour cela que la sécurité agentique ne peut pas reposer sur un seul contrôle. Face à une tentative d’accès à un dossier RH, la réponse attendue est un refus catégorique, fondé sur les droits de l’utilisateur et la sensibilité de la ressource. Face à une injection de prompt dans un document, le système doit détecter l’instruction malveillante, mais aussi empêcher l’accès aux données interdites si l’instruction passe la première barrière. Face à une exécution de code non prévue, il faut pouvoir limiter ce que le runtime autorise réellement : fichiers accessibles, processus, réseau, secrets, environnement d’exécution.
Cette défense en profondeur est essentielle. Un filtre de prompt peut réduire certains risques, mais il ne suffit pas à lui seul. Une politique d’autorisation peut bloquer une action illégitime, mais elle doit être appliquée au bon endroit. Un contrôle runtime peut empêcher une fuite ou une exécution dangereuse, mais il doit être alimenté par une compréhension claire de ce que l’agent est censé faire.
La vraie question devient donc très opérationnelle : l’agent peut-il lire ce fichier précis ? Peut-il exporter cette donnée ? Peut-il appeler cet outil avec ces paramètres ? Peut-il modifier directement une ressource, ou seulement proposer une demande de modification ? Peut-il exécuter du code ? Et si l’action est refusée, l’entreprise peut-elle expliquer pourquoi ?
Cette logique rejoint les principes du Zero Trust appliqués aux agents IA : ne pas considérer qu’une identité valide, un token valide ou un outil approuvé suffit à autoriser toutes les actions possibles. Le NIST insiste également sur la nécessité de gouverner les usages de l’IA générative, de surveiller les comportements et d’adapter les contrôles au niveau de risque (NIST AI RMF Generative AI Profile).
La sécurité agentique repose ainsi sur quatre capacités très concrètes : découvrir ce que l’agent peut atteindre, décider si l’action est légitime, empêcher l’exécution dangereuse et conserver une preuve exploitable. C’est cette chaîne complète qui permet de passer d’une IA utile à une IA réellement maîtrisée.
Pour structurer ces enjeux, le site dédié à la sécurité des agents IA propose une lecture spécifique de cette nouvelle surface de risque. Il ne traite pas seulement des prompts ou des modèles, mais de l’ensemble du chemin d’action d’un agent : identité, outils appelés, permissions, contexte d’exécution, contrôles runtime et preuves disponibles après coup. Cette approche par couches permet de mieux comprendre où placer les garde-fous lorsque l’IA commence à interagir avec des données, des API ou des outils métiers.
À mesure que les agents IA entrent dans les workflows métiers, la question ne sera plus seulement de savoir si l’IA répond juste. Elle sera de savoir ce qu’elle a le droit de faire, dans quelles conditions, avec quelles limites et avec quelles preuves en cas d’audit.
