Agents d’IA en entreprise : 10 risques de sécurité à identifier
Un agent d’IA ne se contente pas de produire du texte. Selon sa configuration, il peut consulter une boîte mail, interroger un fichier client, utiliser un logiciel métier ou déclencher une action. Cette capacité ouvre des perspectives utiles pour une petite entreprise, mais elle change aussi la nature du risque : une réponse incorrecte peut devenir une action réelle.
Prenons l’exemple fictif de Studio Azur, une petite agence qui utilise un agent pour traiter les demandes reçues par courriel. Sa mission semble simple : lire les messages, retrouver les informations utiles et préparer une réponse. Pourtant, si le système dispose aussi d’un accès au fichier clients et au bouton d’envoi, une erreur ou une manipulation peut exposer des données sans qu’un collaborateur ait donné son accord.
Comment une instruction cachée détourne un agent IA
Une injection de consignes consiste à placer une instruction dans un contenu que l’agent doit traiter : message, document, page web ou réponse d’un outil. Ce texte lui demande alors de modifier sa mission, par exemple en envoyant un fichier à une adresse extérieure.
Le problème ne vient pas forcément d’un logiciel piraté. Chaque outil peut fonctionner normalement, tandis que l’agent utilise ses droits pour servir un objectif non prévu. Pour Studio Azur, un faux message client pourrait ainsi demander une synthèse commerciale tout en contenant une instruction destinée à extraire des coordonnées.
La protection commence par une distinction simple : une donnée reçue n’est pas une autorisation. Un courriel peut apporter des informations pour préparer une réponse, mais il ne doit pas définir de nouvelles règles d’accès ni autoriser un transfert.
Les principales familles de risques des agents IA
Le classement OWASP consacré aux agents permet de structurer l’analyse. Il regroupe notamment les situations suivantes :
- Détournement de l’objectif : un contenu externe pousse l’agent à poursuivre une autre mission.
- Mauvais usage des outils : une fonction légitime est utilisée d’une manière dangereuse.
- Abus d’identité ou de droits : des accès trop larges permettent une action non souhaitée.
- Composant externe compromis : une dépendance ou un connecteur introduit un comportement malveillant.
- Exécution de code inattendue : une commande produite ou transmise par l’agent agit sur le système.
- Mémoire empoisonnée : une information trompeuse conservée influence les tâches suivantes.
- Communication entre agents non sécurisée : un message peut être usurpé ou modifié.
- Erreur en cascade : une mauvaise décision est reprise par plusieurs étapes du processus.
- Confiance humaine exploitée : une présentation convaincante pousse une personne à valider une mauvaise action.
- Comportement hors du cadre prévu : l’agent enchaîne des opérations que son responsable n’avait pas envisagées.
Ces risques ne se valent pas pour toutes les activités. Un assistant qui suggère des titres pour les réseaux sociaux n’a pas le même impact qu’un système capable de modifier les coordonnées bancaires d’un fournisseur. La première étape consiste donc à décrire la mission, les outils accessibles et les dommages possibles, avant même de choisir le niveau d’autonomie.
Cette distinction aide aussi à évaluer des produits concrets : comprendre les possibilités d’un agent comme Manus est utile, mais ses capacités doivent toujours être confrontées aux accès réellement ouverts dans ton entreprise. Le risque dépend autant de l’environnement que du modèle lui-même.
Identité et droits des agents IA : limiter les accès sensibles
Pour savoir qui a fait quoi, un agent doit disposer d’une identité distincte et traçable. S’il utilise le compte d’une salariée de Studio Azur, une modification peut apparaître sous son nom alors qu’elle n’a jamais touché au dossier. Le diagnostic devient plus lent, et retirer l’accès à l’automatisation risque de bloquer également la personne.
Attribue donc à chaque agent une identité dédiée, associée à un responsable humain, à une mission et à une configuration approuvée. Cette identité peut s’appuyer sur des mécanismes techniques vérifiables, comme des certificats ou des jetons délivrés par le système d’identité de l’entreprise. L’objectif est de rendre l’origine des actions vérifiable, sans promettre qu’un identifiant suffit à lui seul à empêcher une usurpation.
Appliquer le principe du moindre privilège aux agents IA
Le moindre privilège consiste à accorder uniquement les accès nécessaires à une tâche précise. Pour préparer des réponses commerciales, l’assistant de Studio Azur peut avoir besoin de lire certains messages et de créer des brouillons. Il n’a pas forcément besoin de supprimer des courriels, d’exporter toute la base clients ou de consulter les contrats financiers.
Commence par inventorier les ressources accessibles : messagerie, stockage, agenda, outil de gestion de la relation client et services externes. Pour chacune, distingue la lecture, la création, la modification, la suppression et l’export. Une autorisation globale paraît rapide à configurer ; elle rend aussi les conséquences d’un détournement beaucoup plus importantes.
Prévois ensuite une durée de validité adaptée. Un accès nécessaire à une campagne ponctuelle doit pouvoir expirer à la fin de l’opération. Lorsqu’un jeton ou un connecteur n’est plus utilisé, retire-le plutôt que de le laisser disponible « au cas où ».
| Besoin de l’agent | Accès à envisager | Contrôle complémentaire |
|---|---|---|
| Préparer une réponse client | Lecture des messages concernés et création de brouillons | Envoi validé par une personne |
| Mettre à jour une fiche commerciale | Modification de champs définis | Historique des changements et limites sur les champs sensibles |
| Produire un rapport d’activité | Lecture des données nécessaires au rapport | Export limité à une destination autorisée |
| Traiter un paiement | Aucun accès direct si la mission ne l’exige pas | Validation dans l’outil financier par une personne habilitée |
Protéger les secrets et séparer les environnements
Les mots de passe, clés d’API et jetons ne doivent pas être copiés dans les instructions, la mémoire ou les journaux de l’agent. Utilise un coffre-fort de secrets ou un intermédiaire technique qui fournit l’accès à l’outil sans exposer inutilement l’identifiant au modèle. Limite aussi la durée des jetons et prévois leur révocation.
Sépare les identifiants de test et de production. Une expérience sur une fausse base clients ne doit pas pouvoir modifier les vrais dossiers, même si une erreur de configuration survient. Cette séparation concerne également les connecteurs et les destinations d’envoi.
Enfin, revois les droits lorsqu’un outil, un modèle ou une mission change. Si Studio Azur ajoute la prise de rendez-vous à son assistant commercial, l’accès à l’agenda mérite une nouvelle analyse : quels calendriers, quels types d’événements et quelles modifications sont nécessaires ? Une identité claire facilite l’enquête ; des permissions étroites réduisent les dégâts avant qu’une enquête soit nécessaire.
Validation humaine des agents IA : choisir le bon niveau d’autonomie
Donner davantage d’autonomie à un agent peut faire gagner du temps, mais toutes les actions n’ont pas le même coût lorsqu’elles tournent mal. Modifier un brouillon interne se corrige facilement. Envoyer une proposition erronée à plusieurs centaines de prospects ou changer une donnée de facturation demande une tout autre vigilance.
Pour décider, classe chaque action selon son impact financier, juridique, opérationnel et réputationnel. Ajoute une question pratique : peut-on annuler facilement l’action et informer les personnes concernées si elle échoue ? Plus les conséquences sont importantes ou difficiles à réparer, plus la validation doit être exigeante.
Définir les actions autonomes, validées et interdites
Studio Azur peut autoriser son assistant à classer des demandes et à préparer des réponses dans un dossier interne. Ces opérations restent limitées et contrôlables. En revanche, l’envoi d’un message personnalisé à un client peut nécessiter une validation humaine avant exécution.
Certaines tâches doivent rester interdites à l’agent, même avec une demande formulée dans un courriel : communiquer des mots de passe, modifier un relevé bancaire ou supprimer une base complète, par exemple. Cette troisième catégorie évite de transformer toute interdiction en simple case à approuver sous pression.
Une validation utile présente l’action exacte, son destinataire, son objectif et ses effets attendus. Si l’interface affiche seulement « Autoriser l’agent à continuer », la personne ne dispose pas des éléments nécessaires pour décider. Elle risque alors de cliquer par habitude, surtout lorsque les demandes se multiplient.
Pour une campagne commerciale, la validation peut montrer le contenu du message, le nombre de destinataires, les segments sélectionnés et les pièces jointes. Après approbation, toute modification importante devrait déclencher une nouvelle demande : valider une version ne revient pas à autoriser toutes les versions suivantes.
Placer les règles de sécurité hors du modèle
Une consigne telle que « ne partage jamais de données confidentielles » reste utile pour orienter le comportement de l’agent. Elle ne constitue toutefois pas une barrière suffisante face à un document piégé. Le contrôle décisif doit être appliqué par un système extérieur qui vérifie les permissions et refuse les opérations non autorisées.
Concrètement, une passerelle peut limiter les destinataires autorisés, bloquer certains exports ou imposer une approbation avant l’appel à une fonction sensible. Elle doit aussi tenir compte du contexte : plusieurs petites opérations autorisées peuvent former ensemble une extraction massive.
Il est parfois préférable de remplacer l’autonomie par une règle fixe. Si Studio Azur veut seulement envoyer un accusé de réception identique après chaque formulaire, une automatisation classique, avec destinataire et contenu prédéfinis, sera souvent plus simple à contrôler qu’un agent libre de composer et d’expédier le message.
Le choix n’oppose pas innovation et prudence. Il consiste à réserver les capacités de raisonnement aux tâches qui en ont besoin, tout en conservant des barrières indépendantes pour les opérations sensibles. La bonne autonomie est celle dont les effets restent visibles, proportionnés et maîtrisables.
Mémoire et connecteurs des agents IA : empêcher les fuites de données
Un agent travaille rarement seul. Il peut accéder à une mémoire, utiliser des connecteurs et recevoir des réponses d’autres services. Chacun de ces éléments augmente son utilité, mais élargit aussi la surface à protéger. Une source compromise peut influencer plusieurs tâches sans modifier directement le modèle.
Imagine que Studio Azur accompagne deux clients concurrents. Si son assistant conserve les comptes rendus dans une mémoire commune mal isolée, une recherche effectuée pour le premier peut faire apparaître des informations appartenant au second. Le problème ne dépend pas uniquement de la qualité des réponses : il touche à la confidentialité et à la confiance commerciale.
Cloisonner les données clients et les environnements
Identifie les mémoires individuelles et partagées, leurs utilisateurs, les types de données conservées et leur durée de vie. Sépare les espaces par organisation cliente et par environnement de test ou de production. Les règles d’accès doivent être vérifiées par l’application ou l’infrastructure, pas seulement par une instruction demandant à l’agent de respecter la confidentialité.
Définis aussi une durée de conservation adaptée à chaque usage. Un brouillon temporaire, un historique commercial et une pièce justificative ne répondent pas nécessairement aux mêmes besoins. Prévois la suppression des données périmées et la possibilité de retrouver ce qui a été conservé lorsqu’une personne habilitée en fait la demande.
La mémoire peut également être empoisonnée par une donnée fausse ou une instruction malveillante. Par exemple, un faux compte rendu pourrait affirmer qu’un client a autorisé l’envoi de documents à une nouvelle adresse. Avant qu’une information mémorisée ne serve à une action sensible, vérifie sa provenance et confronte-la à une source fiable.
Vérifier les serveurs MCP et les échanges entre agents
Les serveurs MCP peuvent relier un agent à des données et à des outils. Cette souplesse facilite l’intégration, mais chaque serveur supplémentaire devient un composant à examiner : qui le fournit, quels droits demande-t-il, quelles données reçoit-il et comment ses mises à jour sont-elles contrôlées ?
Avant d’ajouter une connexion, consulte les usages possibles des serveurs MCP pour les activités professionnelles, puis vérifie si le service envisagé correspond à ton besoin réel. Un connecteur capable de lire et modifier tous les dossiers n’est pas nécessairement adapté à une simple recherche documentaire.
Pour les échanges entre agents, authentifie les participants et protège les communications. Une réponse provenant d’un agent distant reste une donnée à vérifier : elle ne doit pas devenir automatiquement une instruction prioritaire. Restreins aussi les destinations réseau et les outils accessibles afin qu’un composant compromis ne puisse pas atteindre librement tout le système.
Tiens un inventaire des dépendances, des versions, des instructions principales et des fournisseurs. Vérifie leur provenance, leur intégrité et les vulnérabilités connues ; mets les composants à jour après test. Place en quarantaine un document ou une sortie suspecte plutôt que de laisser son contenu alimenter directement d’autres tâches.
Enfin, prévois un environnement dédié et durci pour l’exécution : services inutiles désactivés, correctifs suivis et accès réseau limités. L’enjeu n’est pas de multiplier les outils de sécurité sans discernement, mais de savoir où les données circulent et qui peut agir dessus. Un agent bien isolé transforme une erreur locale en incident maîtrisable plutôt qu’en fuite généralisée.
Supervision et règlement IA : garder le contrôle des agents en entreprise
Une configuration prudente ne dispense pas de surveillance. Un modèle change, un connecteur évolue, une équipe ajoute un nouveau cas d’usage : chacun de ces changements peut modifier le niveau de risque. La mission de l’agent doit donc être écrite, attribuée à un responsable et revue au moins chaque année, ainsi qu’après toute modification importante.
Avant la mise en service, teste des scénarios ordinaires et des cas adverses : message contenant une instruction cachée, demande d’export non prévue, outil indisponible ou destination inhabituelle. Vérifie non seulement la réponse produite, mais aussi les appels aux outils et les données effectivement transmises.
Journaliser les actions et préparer l’arrêt d’urgence
Conserve des journaux permettant de reconstituer la demande, les autorisations utilisées, les actions réalisées et leurs résultats. Protège-les contre la modification par l’agent et limite leur accès aux personnes habilitées. Évite d’y inscrire des secrets ou des données personnelles inutiles : un journal utile n’est pas une copie intégrale de tous les échanges.
Définis des alertes sur des comportements précis : hausse inhabituelle des exports, succession rapide d’appels, tentatives d’accès refusées ou envois vers une destination inconnue. Une alerte doit avoir un destinataire et une procédure associée ; sinon, elle devient rapidement un bruit de fond.
Prévois un arrêt d’urgence capable d’interrompre les traitements et de révoquer les accès concernés. Teste-le : arrêter l’interface ne suffit pas si des tâches continuent en arrière-plan ou si un jeton reste actif. Documente également un mode dégradé, par exemple un traitement manuel des demandes, sans élargir les droits pour contourner la panne.
Pour Studio Azur, un exercice simple consiste à simuler un export anormal, à couper le connecteur puis à vérifier les journaux. L’équipe peut ensuite mesurer le temps nécessaire pour identifier les données concernées, informer le responsable et reprendre l’activité. Si le risque résiduel reste inacceptable après les tests, l’agent ne doit pas être déployé.
Comprendre les échéances du règlement européen sur l’IA
Un agent n’est pas automatiquement classé à haut risque parce qu’il est autonome. Le classement dépend notamment de son usage et des critères du règlement européen sur l’IA. Certains systèmes utilisés pour le recrutement ou la gestion des travailleurs figurent parmi les catégories à examiner ; des règles particulières et des exceptions peuvent s’appliquer selon le cas.
Des systèmes intégrés à certains produits réglementés peuvent également relever du haut risque, notamment lorsqu’ils constituent un composant de sécurité soumis aux conditions prévues par le texte. Les obligations varient selon le rôle de l’organisation, par exemple fournisseur ou déployeur : gestion des risques, documentation, supervision humaine et cybersécurité ne reposent pas toutes de la même manière sur chaque acteur.
Dans le calendrier prévu par le règlement, les dispositions générales concernant les systèmes à haut risque de l’annexe III s’appliquent à partir du 2 août 2026, tandis que certaines obligations visant les systèmes liés aux produits réglementés de l’annexe I s’appliquent à partir du 2 août 2027. Des propositions d’évolution du calendrier existent : vérifie le texte applicable au moment du déploiement plutôt que de traiter une proposition comme une échéance définitivement adoptée.
Le RGPD et les obligations de sécurité des données restent pertinents indépendamment de ce classement. Cartographier les usages, les accès et les responsabilités fournit une base utile pour l’analyse juridique comme pour la gestion quotidienne. La conformité se prépare dans les processus réels, pas seulement dans une politique rangée dans un dossier.
Questions fréquentes sur la sécurité des agents IA en entreprise
Quelle différence entre une injection de consignes et un abus d’outil ?
L’injection cherche à détourner l’agent au moyen d’un contenu qu’il lit. L’abus d’outil correspond à une utilisation dommageable d’une fonction pourtant accessible, avec ou sans injection préalable.
Un agent IA doit-il avoir sa propre identité ?
Une identité dédiée et traçable est une mesure recommandée : elle permet de distinguer ses actions de celles des salariés et de gérer ses autorisations sans partager leurs comptes.
Faut-il valider toutes les actions d’un agent ?
Non. Classe les actions selon leur impact et leur réversibilité : certaines peuvent être autonomes, d’autres nécessitent une approbation préalable, et les plus dangereuses peuvent être interdites.
Un agent IA est-il toujours considéré comme un système à haut risque ?
Non. Le classement dépend de l’usage, des catégories et des conditions prévues par le règlement européen sur l’IA, et non du seul fait que le système soit un agent.
