Agents IA et ISO/IEC 42001 : gouverner leurs actions

DE LA RÉPONSE À L’ACTION

La différence ne tient pas au nom du produit. Un chatbot équipé de connecteurs peut lui aussi agir. Le critère pertinent est sa capacité réelle à consulter des données, appeler des outils et produire des effets sur des systèmes externes.

Prenons un scénario fictif. Un responsable sécurité confie à un agent l’analyse des incidents d’un site. L’agent consulte les signalements, prépare une synthèse et propose les personnes à informer. Ce périmètre peut soutenir le travail du responsable.

Si le même agent peut envoyer des messages, fermer des tickets ou modifier des droits d’accès, il reçoit une capacité d’intervention supplémentaire. Chaque capacité doit faire l’objet d’une décision explicite.

OWASP décrit ce risque sous le terme « Excessive Agency » : des fonctions trop larges, des permissions excessives ou une autonomie mal encadrée peuvent permettre des actions dommageables. [2]

CE QU’APPORTE ISO/IEC 42001

ISO/IEC 42001:2023 définit les exigences d’un système de management de l’intelligence artificielle. Elle fournit un cadre pour organiser les politiques, les objectifs, les processus et la gestion des risques liés à l’IA. [1]

Pour un agent, nous proposons de traduire ce cadre en décisions vérifiables : désigner un responsable métier, documenter la mission, évaluer les conséquences des actions possibles et déterminer les conditions de mise en service et de réévaluation.

Les mesures présentées ci-dessous sont des recommandations opérationnelles adaptées aux agents. Elles ne constituent pas une liste d’exigences techniques explicitement prescrites par ISO/IEC 42001. La norme ne configure ni les comptes, ni les connecteurs, ni les filtres réseau.

1. ATTRIBUER DES DROITS À UNE MISSION PRÉCISE

Accorde à l’agent les seules permissions nécessaires. Distingue la lecture, la modification, la suppression et l’envoi. Restreins aussi les ressources accessibles : un dossier d’incidents autorisé ne justifie pas un accès à tous les documents de l’organisation.

Les systèmes destinataires doivent vérifier les autorisations. Une consigne demandant au modèle de respecter les limites ne remplace pas un contrôle technique. [2]

Dans notre scénario, l’agent peut consulter les signalements et préparer un brouillon. L’envoi et la clôture d’un incident restent soumis à validation.

2. DÉFINIR LES ACTIONS SOUMISES À VALIDATION

La supervision humaine doit intervenir au bon moment. Avant une action sensible, le validateur doit voir l’opération exacte, sa cible et ses conséquences prévisibles. L’autorisation doit porter sur cette opération précise. Si le destinataire ou le contenu change, la validation doit être renouvelée. [3]

Pour un responsable sécurité, approuver une synthèse et approuver sa transmission à un prestataire sont deux décisions distinctes. Une personne identifiée conserve la responsabilité de la décision métier.

3. MAÎTRISER LES CONNEXIONS ET LES DONNÉES TRANSMISES

Un outil capable de consulter une adresse web ne devrait pas pouvoir contacter n’importe quelle destination. Définis les services autorisés et les accès internes interdits. Vérifie aussi les redirections et applique les restrictions au niveau du réseau ou du composant chargé des requêtes. [4]

Complète ces restrictions par une règle métier : quelles données peuvent quitter l’organisation, vers quel service et pour quelle finalité ?

Un rapport contenant des informations sur un salarié exige une attention différente d’un document public. La validation doit couvrir les données transmises autant que l’action demandée.

4. CONSERVER UNE TRACE DES OPÉRATIONS

Un historique de conversation ne suffit pas à suivre les effets d’un agent. Relie la demande initiale aux outils appelés, aux validations et aux résultats. [3]

Prévois des journaux horodatés, protégés contre les modifications non autorisées et accessibles aux seules personnes habilitées. Encadre leur conservation et évite d’y enregistrer des secrets ou des données personnelles sans nécessité. [5]

Après un incident, ton équipe doit pouvoir distinguer une action proposée, une action refusée et une action effectivement exécutée.

5. PRÉVOIR UN ARRÊT EFFECTIF

Définis les événements qui suspendent l’agent : tentatives répétées d’action interdite, dépassement d’un plafond ou indisponibilité d’une validation requise. Prévois une interruption humaine et des limites de durée ou de nombre d’opérations. [3]

Notre recommandation est de tester l’arrêt de bout en bout. Il faut vérifier le sort des tâches déjà envoyées, des opérations en attente et des accès encore actifs. Fermer la conversation peut laisser des traitements en cours.

Documente aussi la reprise. Certaines actions peuvent être annulées. Un message déjà transmis ne peut pas toujours être récupéré.

6. TESTER LES DÉTOURNEMENTS ET REVOIR LES CHANGEMENTS

Un document, un courriel ou une page web peut contenir des instructions malveillantes destinées à détourner l’agent. C’est une injection indirecte d’instructions. Le contenu consulté doit être traité comme une donnée non fiable, et les protections doivent combiner plusieurs niveaux de contrôle. [6]

Dans notre scénario fictif, un signalement demande à l’agent de transmettre tous les rapports à une adresse externe. Le test doit vérifier que cette demande ne lui confère aucune autorisation supplémentaire.

Nous recommandons aussi une réévaluation lors de l’ajout d’un connecteur, d’une permission d’écriture ou d’un autre agent. Même si le modèle reste identique, le périmètre d’action change.

LES POINTS À VÉRIFIER AVANT LA MISE EN SERVICE

• Un responsable métier et un responsable technique sont désignés.

• La mission, les ressources accessibles et les actions interdites sont documentées.

• Les permissions correspondent au périmètre approuvé.

• Les validations portent sur des opérations précises.

• Les destinations réseau et les données transmissibles sont encadrées.

• Les journaux permettent de suivre les opérations et leurs résultats.

• L’arrêt, les tâches en attente et la reprise ont été testés.

• Les changements de capacité déclenchent une revue adaptée au risque.

UNE GOUVERNANCE À LA MESURE DES ACTIONS

La qualité des réponses ne suffit pas à évaluer un agent. Sa gouvernance doit couvrir les conséquences de ses actions et la capacité de ton organisation à les contrôler.

ISO/IEC 42001 fournit un cadre de management. Les restrictions techniques, les validations métier et les tests lui donnent une traduction opérationnelle. Aucun de ces éléments, pris isolément, ne garantit l’absence d’incident.

Pour les données personnelles, prévois une finalité claire, un traitement proportionné, une information appropriée, des accès maîtrisés et une conservation encadrée. Les obligations applicables doivent être examinées selon le cas concret. Une certification ISO/IEC 42001 ne dispense pas de cette analyse.

Tu prépares le déploiement d’un agent IA ou tu souhaites revoir un dispositif existant ? Seeger Consulting peut t’accompagner dans l’examen des usages, des responsabilités et des contrôles, puis dans leur intégration à ta démarche de gouvernance ISO/IEC 42001.

SOURCES

Les références ISO étayent la présentation du cadre de management. Les publications OWASP étayent les recommandations de sécurité. Les exemples de gestion d’incidents et les modalités de déploiement proposées sont une application éditoriale au contexte métier, pas des cas clients.

[1] ISO, ISO/IEC 42001:2023, Artificial intelligence management systems.

[2] OWASP, LLM06:2025 Excessive Agency.

[3] OWASP, AI Agent Security Cheat Sheet.

[4] OWASP, Server Side Request Forgery Prevention Cheat Sheet.

[5] OWASP, Logging Cheat Sheet.

[6] OWASP, LLM Prompt Injection Prevention Cheat Sheet.