Les agents d’intelligence artificielle (IA) nous assistent avec une indéniable efficacité, en effectuant des recherches très fines ou en réalisant des tâches à notre place.

Il leur arrive cependant d’être trop zélés et d’en faire plus que demandé, jusqu’à la catastrophe. La presse relève régulièrement des anecdotes relatant des bases de données effacées ou des dossiers entiers irrémédiablement supprimés.

Un agent IA n’a cependant pas conscience d’abuser des libertés accordées, il se contente de tirer profit de ce qu’il a à sa disposition. A l’instar des jeunes enfants, les agents ont besoin de cadres et de règles, et en particulier de limites sur ce qu’ils ont le droit de faire.

Les techniques modernes de gestion des identités et des accès dans les entreprises apportent des outils inestimables pour parvenir à ce but, à condition de savoir les appliquer et de les adapter au contexte.

A ce propos, penchons-nous sur ce qu’est un agent, pour comprendre là où les dérapages peuvent apparaître et savoir comment les empêcher.

Un agent IA, c’est quoi et comment ça fonctionne ?

Un agent IA s’appuie sur un modèle d’intelligence artificielle (un Large Language Model ou LLM) afin de réaliser des tâches pour le compte d’une personne ou d’une organisation. Par abus de langage nous confondons souvent les deux. Il est important de noter la différence. Le LLM est la brique de départ, simulant une pensée logique grâce à un processus de prédiction de texte. L’agent IA, quant à lui, est un composant qui utilise le LLM comme moteur d’inférence, pour mimer le comportement humain. Pour bien saisir la révolution en cours, il convient de décortiquer cette technologie en plusieurs couches.

Le modèle de langage, un cerveau dans un monde clos

Un LLM est entrainé avec une quantité astronomique de savoir pendant un certain temps, puis sa configuration est définitivement figée. Il est alors prêt à répondre aux questions qu’on lui pose, mais il répond uniquement dans le cadre des connaissances qu’il a emmagasinées. Son savoir s’arrête donc complètement à une date précise (appelée knowledge cutoff). Il ignore par exemple la date et l’heure actuelle.

Du chatbot à l’agent : l’apparition des outils

Pour communiquer avec ce cerveau, il faut lui donner des oreilles et une bouche en lui greffant une interface utilisateur. C’est la naissance du chatbot.

Contrairement à un humain, Il n’a – par défaut – pas de mémoire et traite chaque question de manière isolée. Pour maintenir une véritable conversation, le chatbot doit conserver l’historique des échanges et le transmettre de nouveau au modèle à chaque question, lui permettant ainsi de répondre en restant dans le fil de la discussion. Sans cette répétition constante du contexte, le modèle oublie instantanément ce qui vient d’être dit.

Avoir une conversation avec quelqu’un ayant une connaissance gigantesque, c’est déjà intéressant, mais on peut aller plus loin. En donnant au LLM des outils pour interagir avec le monde réel, on peut lui faire faire des actions à notre place : des yeux pour lire un document ou pour parcourir internet, des mains pour remplir un formulaire ou pour appuyer sur un bouton. Le chatbot se transforme alors en agent.

Si je crée un agent avec un outil pour lire un thermomètre et un outil pour changer le thermostat du chauffage, je peux lui demander de régler le chauffage pour qu’il fasse 20°. L’agent va transmettre ma requête au modèle, qui va analyser la demande, demander à l’agent de lui lire le thermomètre, constater l’écart de température et finalement demander à l’agent d’actionner le thermostat.

On commence à avancer en possibilités. On est passés d’un LLM qui arrive à réfléchir à notre place (grâce à un chatbot), à un LLM qui agit à notre place (grâce à un agent). On va maintenant le faire travailler à notre place.

Le RAG ou comment faire travailler une IA sur des données privées

Pour qu’un agent réalise des tâches à notre place, il lui faut la matière sur laquelle travaille : nos dossiers, notre documentation. En un mot : nos données à nous.

Or lui fournir l’ensemble des documents de manière directe est impossible, car les modèles sont limités dans la quantité d’informations qu’ils peuvent traiter d’un coup, et chaque unité d’information analysée engendre un coût financier non négligeable.

La solution actuelle réside dans la technologie du RAG (Retrieval Augmented Generation). Cette méthode consiste à enrichir le contexte d’une question avec les éléments sur lesquels on souhaite que le modèle raisonne.

On a toutefois observé qu’il était improductif de donner trop d’informations de contexte aux modèles : à partir d’un volume seuil, on se rend compte que la pertinence des résultats se dégrade.

De ce fait, on ne peut pas transmettre de manière brute tous les documents d’une société à un modèle.

Le RAG consiste à extraire de l’ensemble des informations privées celles qui sont pertinentes pour répondre à la question. C’est uniquement ce sous-ensemble qui est soumis au modèle.

Cela se fait en deux étapes : d’abord une préparation des données, effectuée en amont. Pour, pour chaque question, la sélection des données qui la concerne.

La phase de préparation consiste à convertir l’information en texte (si nécessaire), puis à découper le texte de fragments (technique du chunking). Chaque fragment doit représenter un élément unitaire d’information.

Le texte est ensuite transformé en nombres, pour être plus facilement manipulé. Pour cela, chaque fragment est représenté mathématiquement sous forme d’un vecteur (vectorisation).

De ces vecteurs, on n’en retient que ceux ont une la meilleure chance d’être en rapport avec la question : cette dernière est elle-même vectorisée et seuls les vecteurs d’information les plus proches sont retenus.

On retrouve alors les fragments de texte correspondant à ces vecteurs, que l’on transmet au modèle dans le contexte de la question.

Le danger, c’est évidemment que toute cette mécanique n’envoie pas les fragments les plus pertinents au modèle, qui répondra alors à côté. Le RAG n’est donc pas une méthode à suivre pas à pas. C’est un ensemble de principes que le développeur de l’agent peut suivre pour trouver la meilleure méthode dans un contexte particulier.

Il est possible d’aller plus loin en adaptant un LLM par des techniques de fine-tuning et de re-training, mais qui sont autrement plus contraignantes.

Ainsi, en associant un modèle capable de simuler le raisonnement, une interface de chatbot pour échanger, des outils pour interagir avec son environnement et le RAG pour transmettre les bonnes connaissances au bon moment, on obtient un agent d’intelligence artificielle complet qui pourra nous assister efficacement dans nos tâches quotidiennes.

Les risques de l’IA agentique : comprendre et maîtriser la « boîte noire »

Toute avancée technologique vient avec une promesse d’amélioration de notre vie, mais aussi avec un côté sombre capable d’en annuler tous les bénéfices s’il n’est pas maîtrisé. Une voiture écourte les distances, mais elle peut aussi tuer. L’intelligence artificielle agentique suit exactement la même règle. Lorsqu’on donne à une IA le pouvoir d’agir à notre place, la moindre faille peut transformer un assistant précieux en une source de risques majeurs pour l’entreprise.

L’imprévisibilité d’une boîte noire non déterministe

Le défi principal de l’intelligence artificielle réside dans sa nature même. Un modèle de langage est ce que l’on appelle une boîte noire : un système complexe auquel on fournit des données et qui en retourne d’autres, sans que l’on puisse précisément comprendre les mécanismes internes qui ont mené à ce résultat.

De plus, cette boîte noire n’est pas déterministe. Cela signifie que si vous posez exactement la même question plusieurs fois de suite à un chatbot, ou si vous placez un agent dans plusieurs situations identiques, le modèle pourra formuler des réponses ou ordonner des actions différentes à chaque tentative. En d’autres termes, il n’existe aucune garantie absolue quant au comportement final de l’IA. C’est cette absence de certitude qui explique les comportements absurdes ou destructeurs qui défraient parfois la chronique.

Des incompréhensions aux attaques par injection de prompt

Cette imprévisibilité se manifeste principalement de deux manières dans le quotidien d’une organisation.

D’un côté, il y a le risque de la simple incompréhension technique. Un agent programmé pour une tâche routinière, comme le nettoyage des messages obsolètes dans une boîte de réception, peut interpréter une consigne de travers et finir par vider l’intégralité des serveurs de messagerie.

D’un autre côté, il y a le risque d’origine malveillante, incarné par les attaques par injection de prompt (prompt injection). Ce phénomène se produit lorsqu’un utilisateur externe s’adresse de manière habile ou trop directe à un chatbot public. En contournant les consignes de sécurité initiales par le simple biais du langage, l’attaquant peut manipuler le modèle pour lui faire révéler des données confidentielles, comme la liste des numéros de mobile de l’ensemble des commerciaux d’une entreprise.

Malgré ces risques, une réalité technique offre une lueur d’espoir : un modèle de langage ne peut pas agir seul dans le monde réel, et inversement, un agent a impérativement besoin de la logique du modèle pour prendre des décisions. C’est uniquement au point de rencontre entre ces deux entités que les actions nuisibles prennent vie.

Sécuriser l’IA agentique : failsafe, gestion des droits et protection des données

L’intégration des agents IA dans le quotidien des organisations apporte une agilité sans précédent, mais elle redéfinit également la surface d’attaque et les risques opérationnels. Qu’il s’agisse d’erreurs d’interprétation ou de manipulations malveillantes, confier un pouvoir d’action à un modèle non déterministe impose la mise en place de barrières de sécurité strictes. Le point de contrôle fondamental ne se situe pas dans le modèle lui-même, mais dans l’encadrement des interactions et des outils confiés à l’agent.

Le point de rupture : L’interaction entre le modèle et l’agent

Un modèle de langage ne peut pas impacter le monde réel de manière autonome, et un agent a besoin de la logique du modèle pour prendre des décisions. C’est précisément à la frontière de ces deux entités que naissent les risques.

D’un côté, une simple incompréhension technique peut se révéler destructrice : un agent configuré pour nettoyer les messages obsolètes d’une boîte mail peut mal interpréter une consigne et purger l’intégralité des serveurs de messagerie.

D’un autre côté, le risque peut être d’origine malveillante via les attaques par injection de prompt (prompt injection). Un utilisateur externe, en dialoguant de manière habile avec un chatbot public, peut réussir à contourner ses consignes de sécurité initiales pour lui faire révéler des données confidentielles, telles que les coordonnées des équipes commerciales.

Pour contrer ces dérives, la solution ne consiste pas seulement à dire au modèle (au travers du contexte) qu’il ne doit pas mal agir — à l’image d’un enfant, il peut contourner l’interdiction si la question est bien tournée. La sécurité repose sur la surveillance stricte du va-et-vient d’informations entre le modèle et les ressources manipulées au travers de l’agent (outils et RAG).

Éviter la fuite de données par les outils de récupération

Les agents utilisent des outils pour interroger des bases de connaissances et enrichir les réponses du modèle. Si un utilisateur demande la recette secrète d’un restaurant, le modèle ne la connaît pas nativement. En revanche, si l’agent dispose d’un outil d’accès à la base de données des recettes, le modèle l’activera pour récupérer l’information et la transmettre au demandeur.

Si la requête émane du chef cuisinier, elle est légitime. Si elle vient d’un client externe sur le site web, c’est une fuite de données majeure. Pour éviter ce scénario, l’architecture de l’agent doit intégrer un composant de filtrage des données accédées au travers de l’outil.

Ce mécanisme repose sur le principe de moindre privilège : l’agent doit valider l’identité et les droits de l’utilisateur final avant de transmettre une quelconque information au modèle. Si l’utilisateur n’est pas habilité à voir une donnée, l’outil de l’agent ne doit tout simplement pas la fournir au modèle.

Brider les actions involontaires des outils d’exécution

Au-delà de la simple lecture de données, les outils permettent aux modèles de déclencher des actions concrètes, comme la modification ou la suppression de ressources. Un collaborateur peut ainsi demander à son agent de supprimer de la base de données les contacts inactifs depuis deux ans. Le modèle va alors ordonner à l’agent d’exécuter l’opération.

Toutefois, en cas de mauvaise interprétation de la consigne ou des paramètres de l’outil, le modèle peut ordonner par erreur la suppression de l’intégralité de la base de données de l’entreprise.

La parade consiste là encore à implémenter des garde-fous stricts sur les permissions de l’agent. Il ne faut pas calquer aveuglément toutes les permissions de l’utilisateur sur l’agent, mais lui allouer un sous-ensemble minimal et strictement nécessaire à sa mission. Si le rôle de l’agent se cantonne à la gestion des contacts personnels d’un salarié, ses droits d’exécution doivent être techniquement verrouillés sur ce périmètre unique, empêchant ainsi toute action accidentelle sur les données de ses collègues.

Adapter le modèle d’habilitation à l’architecture RAG

L’intégration des données internes d’une organisation via la technique du RAG (Retrieval Augmented Generation) soulève le défi du cloisonnement des données. Un agent traitant des documents d’une entreprise doit pouvoir aider le service comptable à analyser des rapports financiers sans pour autant rendre ces informations sensibles accessibles aux autres directions.

Dans un système RAG, les méthodes traditionnelles de contrôle d’accès aux fichiers se révèlent insuffisantes car l’agent ne transmet pas les documents sous leur forme brute. Les informations ayant été préalablement converties en vecteurs lors de la phase d’indexation, le modèle d’habilitation classique de l’entreprise doit être transposé directement sur la base de données vectorielle. Les droits d’accès s’appliquent ainsi aux vecteurs eux-mêmes pour garantir que seuls les fragments de données autorisés soient utilisés pour formuler une réponse.

Protéger la mémoire de l’agent contre les fuites

Pour suivre le fil d’une discussion à court terme ou mémoriser le contexte des échanges sur une longue période, le chatbot ou l’agent gèrent une mémoire dédiée. Cette mémoire stocke l’historique des questions, des réponses et des vecteurs associés, qui contiennent fréquemment des données stratégiques ou confidentielles.

Dès lors que l’agent est déployé sur un serveur partagé et mutualisé entre plusieurs collaborateurs, la mémoire devient une cible. Sa protection requiert une isolation logique rigoureuse. La sécurité des données mémorisées passe alors par des mécanismes d’authentification stricts et des protocoles de chiffrement robustes, garantissant que chaque utilisateur ne puisse accéder qu’à son propre historique de conversation.

La stratégie à retenir : contrôler ce qui entre et sort du modèle

Un modèle ne peut faire fuiter que les informations qu’on lui donne, car il n’a été entraîné qu’avec des données réputées publiques, dont la divulgation ne pose aucun souci (on laisse ici de côté le re-training de modèle qui pose des problèmes d’une autre ampleur).

Il ne réalise aucune action lui-même : il doit pour cela utiliser des outils mis à disposition par les agents. De plus, les interactions entre agents et modèles se font dans un cadre clairement défini. Un modèle n’est accessible qu’au travers d’une API.

Un principe de base pour la sécurisation des agents est donc de ne fournir aux modèles que des informations sur lesquelles l’utilisateur a des habilitations.

En retour, les demandes d’utilisation des outils d’action doivent être analysées pour s’assurer non seulement que l’utilisateur demandeur dispose bien des droits pour les réaliser, mais aussi que les actions s’inscrivent dans le cadre de sa demande.

De son côté, l’agent doit assurer la confidentialité des informations qu’il manipule pour le compte des utilisateurs, et éviter toute fuite ou manipulation frauduleuse.

Il est courant de conserver des informations de contexte ou de mémoire dans des fichiers ou des caches de type Redis, qui devront donc être protégés en conséquence.

Les limites techniques et structurelles d’OAuth 2

Dans le débat sur la sécurisation des agents d’intelligence artificielle, l’adoption du protocole OAuth 2 est fréquemment présentée comme la solution incontournable. Cette affirmation est techniquement exacte : OAuth 2 permet de transporter une autorisation d’accès à une API sous la forme d’un jeton d’accès (access token), en s’appuyant sur l’authentification de l’utilisateur final et sur son consentement. S’il est indispensable que l’agent IA hérite des droits de son utilisateur pour agir légitimement, s’en remettre uniquement à OAuth 2 s’avère insuffisant face aux spécificités de l’IA agentique.

Les failles de traçabilité et de persistance

Une traçabilité efficace exige que le jeton d’accès identifie distinctement l’utilisateur final et l’agent agissant pour son compte, voir la chaîne des agents orchestrés pour obtenir la réponse.

La méthode idéale pour répondre à ce besoin est de générer pour l’agent un jeton personnalisé à partir de celui de l’utilisateur, au travers du protocole Token Exchange. Malheureusement, ce protocole est loin d’être implémenté par tous les fournisseurs d’identité du marché, et ses quelques intégrations ne prennent pas encore nativement en compte les contraintes spécifiques des agents d’intelligence artificielle.

La persistance des accès pose également un défi de sécurité critique. Pour éviter que l’utilisateur n’ait à ressaisir ses identifiants à chaque interaction, les agents s’inspirent du comportement des applications mobiles en stockant un jeton de rafraîchissement (refresh token) à très longue durée de vie. La responsabilité de protéger ce secret lourd de conséquences repose alors entièrement sur l’infrastructure de l’agent, créant un point de vulnérabilité majeur en cas de compromission.

Enfin, OAuth 2 peut bien être utilisé pour sécuriser les bases de données vectorielles utilisées par le RAG, mais uniquement après que ces bases ont été considérées comme des Resource Server (RS) et traitées en conséquence.

L’impact sur l’expérience utilisateur et l’avenir des protocoles

Au-delà des barrières purement techniques, l’usage exclusif d’OAuth 2 engendre une dégradation notable de l’expérience utilisateur. Par défaut, le protocole impose une authentification distincte pour chaque API connectée. Si un agent IA doit interroger dix sources de données différentes pour compiler une simple revue de presse quotidienne, l’utilisateur se verra contraint de s’authentifier individuellement auprès de chaque site ou service. Une telle friction contredit la promesse d’automatisation et de fluidité de l’IA agentique.

Face à ce constat, l’industrie mène actuellement des travaux de standardisation pour concevoir des mécanismes d’authentification unique centralisée, adaptés aux architectures multi-agents. Cependant, le chemin reste long avant la concrétisation de ces standards, et leur adoption globale par l’ensemble des fournisseurs d’API prendra plusieurs années. OAuth 2 constitue donc une brique de base nécessaire, mais non suffisante, qui doit être complétée par une gouvernance de sécurité logicielle propre aux agents.

Les piliers de la gouvernance : Sécuriser et fiabiliser l’IA agentique sur le long terme

L’analyse de la nature d’un agent et de ses interactions avec un modèle d’IA met en lumière des risques de comportements abusifs majeurs. Si une gestion rigoureuse des identités et des accès (IAM) apporte des réponses indispensables, elle ne constitue qu’une première ligne de défense. Pour déployer des agents IA en toute sérénité au sein d’une organisation, il est nécessaire d’adopter un cadre de gouvernance global, associant traçabilité, contrôle dynamique et supervision humaine.

Imputabilité et traçabilité de la chaîne d’action

Pour garantir la fiabilité d’un système automatisé, la traçabilité des actions est primordiale afin de rendre possible leur imputabilité. En matière d’IA agentique, l’auditabilité doit être bicéphale. Les journaux de logs ne peuvent pas se contenter d’enregistrer qu’une action a été effectuée par « l’IA ».

Il est indispensable de pouvoir imputer techniquement chaque décision à deux acteurs distincts : l’agent qui a exécuté l’opération via ses outils, et l’utilisateur humain précis qui a sollicité l’agent à l’origine de la chaîne textuelle. Cette double traçabilité est la seule garantie pour comprendre l’origine d’une dérive, qu’elle soit logicielle ou humaine.

La vérification dynamique des accès en temps réel

Issu de l’expérience de la gestion des identités et des architectures Zero Trust, le principe de vérification dynamique s’impose comme une nécessité absolue. Les droits d’accès et la légitimité d’une action ne doivent pas être évalués uniquement au démarrage de la session de l’utilisateur ou lors de l’activation initiale de l’agent.

Le contexte opérationnel, la sensibilité des données et les habilitations des collaborateurs évoluent en continu. L’agent doit donc valider les permissions au moment exact où l’accès à la ressource ou l’action se produisent. Si les droits d’un utilisateur sont révoqués ou modifiés en cours de journée, l’agent doit le détecter instantanément lors de sa prochaine interaction avec l’outil de récupération ou d’exécution.

Au-delà des identités : Les garde-fous comportementaux et la validation humaine

La gestion des identités pose les bases de la sécurité, mais elle doit être complétée par d’autres mesures. Un collaborateur peut posséder légitimement des droits étendus sur un système, et l’agent qui hérite de ses droits disposera alors d’un pouvoir d’action suffisant pour causer des dégâts critiques en cas de mauvaise interprétation du modèle.

Pour pallier cette limite, il convient de mettre en place des garde-fous comportementaux. Ces composants de sécurité intermédiaires analysent en temps réel les actions demandées par les modèles avant que l’agent ne les exécute. Ils recherchent des anomalies, des volumes d’activité suspects ou des requêtes à haut risque (comme la suppression massive de données ou l’export de fichiers sensibles). Dès qu’un seuil de risque est franchi, le système bloque l’automatisation et bascule vers une boucle de validation humaine (human-in-the-loop), soumettant l’action à l’approbation explicite d’un opérateur avant son exécution.

Établir une gouvernance stricte pour un outil imprévisible

En conclusion, pour que les agents IA deviennent des assistants viables, les organisations doivent impérativement définir leur cadre de gouvernance. Par bien des aspects, cette structure ressemble à la gouvernance des ressources humaines appliquée aux personnes physiques : définition des rôles, des responsabilités et des périmètres d’action.

Cependant, en raison de la nature non déterministe et intrinsèquement imprévisible des modèles de langage, la gouvernance d’un agent IA se doit d’être beaucoup plus précise, granulaire et contraignante que celle d’un être humain. C’est à ce prix, en combinant des règles logicielles strictes à une supervision humaine continue, que l’IA agentique pourra être intégrée de manière sécurisée dans les processus métiers.

Références :

Claude-powered AI agent’s confession after deleting a firm’s entire database: ‘I violated every principle I was given’

https://www.theguardian.com/technology/2026/apr/29/claude-ai-deletes-firm-database

Meta AI agent’s instruction causes large sensitive data leak to employees

https://www.theguardian.com/technology/2026/mar/20/meta-ai-agents-instruction-causes-large-sensitive-data-leak-to-employees

McDonald’s AI bot spills data on job applicants

https://www.malwarebytes.com/blog/news/2025/07/mcdonalds-ai-bot-spills-data-on-job-applicants

Meta AI alignment director shares her OpenClaw email-deletion nightmare: ‘I had to RUN to my Mac mini’

https://www.businessinsider.com/meta-ai-alignment-director-openclaw-email-deletion-2026-2?op=1

OpenClaw user says AI went rogue, highlighting risks of agents

https://financialpost.com/cybersecurity/openclaw-ai-went-rogue-highlighting-risk

Gemini CLI Prompt Injection via Malicious .gemini/ Directory

https://github.com/google-github-actions/run-gemini-cli/security/advisories/GHSA-wpqr-6v78-jr5g

ServiceNow AI Agents Can Be Tricked Into Acting Against Each Other via Second-Order Prompts

https://thehackernews.com/2025/11/servicenow-ai-agents-can-be-tricked.html

Registre supplémentaire : https://www.osohq.com/developers/ai-agents-gone-rogue