Risques de sécurité liés aux agents ia en entreprise

Les agents IA ne se contentent plus de répondre aux questions. En entreprise, ils lisent la messagerie, ouvrent des fichiers et agissent dans les outils de travail.

Un accès donné pour une tâche peut alors servir à autre chose, sans que personne s’en aperçoive. Cet article vous montre les principaux risques de sécurité de ces agents et comment les maîtriser par la gouvernance et le contrôle.

Dix familles de risques, ce que cela recouvre concrètement

Un agent peut causer un dommage avec des actions pourtant autorisées. Il se trompe, se fait manipuler ou enchaîne dangereusement des opérations permises.

Un courriel piégé peut cacher une consigne que l’agent lit en faisant son travail, et le détourner de sa mission. Pour voir ce qu’un agent autonome sur votre PC peut faire seul sur un poste, voyez la page dédiée.

L’OWASP classe les risques des agents en dix familles :

• ASI01, détournement de l’objectif par un contenu piégé
• ASI02, mauvais usage des outils légitimes
• ASI03, abus de droits ou d’identité
• ASI04, composant externe compromis
• ASI05, exécution de code inattendue
• ASI06, mémoire empoisonnée, qui pèse sur les réponses
• ASI07, échanges non sécurisés entre agents
• ASI08, erreur qui se propage en cascade
• ASI09, confiance de l’humain exploitée
• ASI10, agent déviant hors du cadre prévu

Des identités d’agents à part entière

Un agent doit avoir sa propre identité, distincte de celle d’un employé comme d’un compte de service. Cette identité est unique et vérifiable par cryptographie, pour savoir à coup sûr quel agent a agi.

Liez-la à la configuration approuvée de l’agent : si elle change, l’identité doit être revérifiée. Pour les données qu’il peut traiter, voyez classification des données.

Contrôles d’accès

• Inventoriez accès, ressources et capacités.
• N’accordez que ce que la tâche exige.
• Gardez les secrets hors du contexte, de la mémoire et des journaux.
• Confiez-les à un coffre-fort ou à un proxy.
• Séparez identifiants et connecteurs par environnement.
• Limitez la durée du jeton à la tâche.
• Retirez les accès temporaires à la fin de la tâche.
• Révoquez-les si l’agent se comporte anormalement.

Comment un agent détourné agit sur vos outils

Un agent peut lire un courriel piégé, c’est-à-dire un message qui contient une consigne cachée. Il suit alors cette consigne avec ses propres outils de messagerie, en envoyant par exemple des données à un tiers.

Chaque appel d’outil paraît légitime, mais l’enchaînement sert un autre but. Traitez donc les courriels reçus comme un risque avant d’autoriser l’agent à agir automatiquement.

Qui valide les actions critiques de l’agent

Toutes les actions de l’agent ne pèsent pas autant. Classez chaque action selon son impact métier si elle dysfonctionne. Ce classement décide de son niveau d’autonomie.

Trois cas existent : exécution autonome, approbation humaine obligatoire, ou action interdite. Pour choisir un outil qui intègre la sécurité par défaut, voyez les avancées de n8n 2.0 pour les agents IA.

Pour les actions critiques, un humain valide avant l’exécution.

Cloisonner l’environnement, la mémoire et les composants

Faites tourner l’agent, ses outils et ses connecteurs dans un environnement dédié, isolé et durci. Revoyez-le régulièrement. Séparez les mémoires par organisation cliente et par environnement : un client ne doit jamais lire la mémoire d’un autre.

Repérez les mémoires individuelles, celles qui sont partagées, et leurs utilisateurs. Pour les droits à donner à l’agent, voyez agents IA personnels et sécurité.

Conservation, quarantaine et chaîne d’approvisionnement

Superviser, journaliser et couper l’agent en urgence

Pensez la sécurité dès la conception. Écrivez la mission de l’agent : ce qu’il doit faire et ce qu’il ne peut pas faire. Relisez-la au moins une fois par an, et après chaque changement important.

Après chaque modification du système, du modèle ou de l’environnement d’exécution, refaites l’évaluation des risques. Si un risque reste inacceptable, ne mettez pas l’agent en service.

Pour reprendre la main, combinez ces moyens :

• Testez l’agent avant sa mise en service, puis à intervalles réguliers, et surveillez ses actions.
• Gardez les journaux hors de sa portée, avec de quoi reconstituer chaque demande, autorisation, action et résultat.
• Prévoyez un arrêt d’urgence qui révoque ses accès dès qu’un mécanisme de supervision détecte un traitement anormal.
• Préparez un mode dégradé, sans élargir les droits ni affaiblir les contrôles.

Règlement européen sur l’IA : à quelle échéance et pour quels systèmes

Un agent n’est pas à haut risque du seul fait qu’il est un agent. Il l’est si son usage figure à l’annexe III, comme le tri de candidatures ou la surveillance des salariés.

Il l’est aussi s’il sert de composant de sécurité à un produit couvert par la législation de l’annexe I. Il doit respecter : gestion des risques, journalisation, documentation, supervision humaine, robustesse et cybersécurité.

Un agent IA peut causer un dommage avec des actions pourtant permises. Pour le maîtriser, donnez-lui sa propre identité, ne lui accordez que les droits de sa tâche et placez les contrôles hors de lui.

Commencez par lister vos agents et leurs accès. Classez ensuite chaque action selon son impact si elle dysfonctionne : ce classement fixe le niveau d’autonomie qu’elle peut avoir.

Foire aux questions

Qu’est-ce qu’un agent IA en entreprise ?

Un agent IA en entreprise est un système qui peut planifier une tâche et agir avec des outils pour l’accomplir.

Il peut aussi prendre des décisions dans un processus de travail, par exemple trier une demande et décider de la suite à lui donner.

Quelle différence entre une injection de consignes et un abus d’outils ?

L’injection de consignes cherche à détourner les instructions de l’agent ; l’abus d’outils utilise ses outils légitimes d’une façon qui cause un dommage ou sort du but prévu.

Dans le second cas, rien n’est trafiqué : l’outil est bon, c’est son usage qui dérape.

Un agent IA est-il automatiquement considéré comme à haut risque ?

Non. Le classement dépend de l’usage que vous faites de l’agent et des catégories prévues par le règlement européen sur l’IA.

Être un agent ne suffit pas à le placer dans le haut risque : c’est ce qu’il fait dans votre processus qui décide.

Faut-il un identifiant distinct pour chaque agent IA ?

Oui. Donnez à chaque agent une identité qui lui est propre, vérifiable et séparée des comptes des salariés comme des comptes de service. Sans cela, ses actions se mêlent à celles d’un salarié ou d’un compte technique.

Quelle est la première mesure à mettre en place pour sécuriser un agent IA ?

Commencez par définir la mission de l’agent : ce qu’il doit faire et ce qu’il ne peut pas faire. Ensuite seulement, analysez les risques dès la conception, avant de décider de ses accès et de ses actions.