Sécurité des agents IA : définir les accès et les responsabilités

Traitez les messages et documents reçus comme des données non fiables : une instruction trouvée dans une pièce jointe ne doit pas accorder un droit. Gardez les secrets hors des instructions du modèle. Tracez l’action, son statut et l’approbation utile avec un accès et une conservation adaptés, sans recopier inutilement tout le dossier.

Le contrôle technique bloque une opération interdite ; le choix de la personne qui peut l’autoriser relève de votre organisation. Tester l’un ne prouve pas que l’autre a été décidé.

Cartographier les frontières du système

Listez les utilisateurs, les sources, les outils et les systèmes qui reçoivent un résultat. Pour chaque échange, indiquez l’identité utilisée, les informations transmises et les opérations possibles. Ce travail permet de voir où une décision du modèle pourrait devenir une action réelle.

Séparez les informations à lire des instructions autorisées. Un document ou un message reçu peut contenir une demande visant à détourner le comportement du système. OWASP décrit le risque de prompt injection. Le traitement doit tenir compte de cette frontière.

Définir les contrôles selon l’action

La validation humaine doit être placée avant l’action concernée. Elle doit présenter un aperçu suffisamment précis pour permettre une décision réelle.

Tester les limites explicitement

Préparez des scénarios avec une demande hors périmètre, un utilisateur moins autorisé, une source contradictoire et une instruction suspecte dans un document. Vérifiez ce que le système montre et ce qu’il exécute effectivement.

Les contrôles ne doivent pas dépendre uniquement de la bonne formulation d’un refus. Une réponse indiquant « je ne peux pas » n’est pas suffisante si l’outil a tout de même été appelé. Les journaux et les vérifications côté application doivent permettre de constater le comportement réel.

Répartir les responsabilités

Nommez un propriétaire métier du parcours, un responsable technique et des responsables de données. Indiquez qui approuve un nouvel outil, un élargissement des accès ou un changement de modèle. Une fonctionnalité déjà déployée continue d’évoluer et doit garder un propriétaire.

Une approche de gestion du risque peut aider à organiser ces décisions ; le cadre AI RMF du NIST constitue une référence générale. Son usage ne vaut pas certification ni démonstration de conformité d’un produit.

Préparer l’incident et la reprise

Définissez comment arrêter une action, retirer un accès et identifier les opérations concernées. Conservez les éléments nécessaires à l’analyse avec une durée et un périmètre adaptés. Évitez que les traces deviennent une copie incontrôlée des documents métier.

Prévoyez la communication à l’utilisateur et le retour au processus manuel. Après correction, rejouez les cas qui ont révélé le problème avant d’élargir de nouveau l’usage.

Questions fréquentes

Peut-on donner tous les accès pour simplifier le prototype ? Le prototype doit disposer d’un périmètre explicite. Des permissions trop larges rendent les conclusions de l’essai difficiles à transposer et augmentent les conséquences d’une erreur.

Faut-il valider chaque action à la main ? Le niveau de contrôle dépend des conséquences et du besoin. Il doit être défini par catégorie d’action, puis vérifié dans le fonctionnement réel.

La sécurité se termine-t-elle au lancement ? Non. L’ajout de données, d’outils ou d’utilisateurs change le périmètre à examiner.

Précisez ces décisions dans votre cahier des charges et votre plan de production. Binov apporte un accompagnement en architecture et leadership technique.