Édition Markdown

AI-translated from English; not yet reviewed by a fluent editor.

# Comparer les contrôles d’action d’un fournisseur d’agents IA avant l’achat

> Comparez les identités, validations, permissions des outils, journaux, flux de données et preuves d’échec d’un fournisseur d’agents IA à votre profil de risque écrit, avant une décision d’achat humaine.

By BIG CHANGE Editorial

Published: 2026-10-19T15:30:34.881Z
Updated: 2026-10-19T15:30:34.881Z
Canonical: https://bigchange.ai/blog/ai-agent-vendor-action-controls-evidence

![Conceptual charcoal illustration of a completely blank five-column comparison worksheet clipped to an angled wooden reading stand, beside a closed unmarked folder.](https://bigchange.ai/api/media/file/agent-vendor-blank-comparison-worksheet-v1.png)
AI-generated conceptual illustration by BIG CHANGE; no actual vendor evidence, security finding, audit, test or purchase decision is depicted.

Un agent IA qui agit dans des comptes connectés peut modifier des données ou déclencher des processus métier. Avant de choisir un fournisseur, un responsable métier et une personne chargée de la sécurité peuvent comparer les contrôles d’**un processus proposé** aux exigences écrites de l’organisation. Le résultat est un dossier de preuves daté. Une réponse manquante reste ouverte ; une affirmation commerciale ne montre pas à elle seule qu’une action sera bloquée. La méthode s’appuie sur le [NIST AI Risk Management Framework Playbook](https://airc.nist.gov/airmf-resources/playbook/) et sur l’[AI Agent Security Cheat Sheet d’OWASP](https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html) ; aucun des deux n’a évalué le fournisseur envisagé.

## Le grand changement

- **Ce qui change :** L’achat d’un agent peut inclure des actions déléguées dans les systèmes de l’entreprise. L’acheteur doit savoir qui peut faire agir l’agent, sur quoi et avec l’accord de qui.
- **Pourquoi c’est important :** L’acheteur peut rattacher chaque action proposée à un contrôle nommé et aux preuves correspondantes. Le responsable métier et la personne chargée de la sécurité disposent ainsi d’une base concrète pour limiter les accès ou suspendre l’achat.
- **À surveiller :** La décision dépend des preuves concernant la version exacte du produit et le processus visé. Un contrôle décrit dans la documentation peut encore nécessiter une démonstration supervisée avant son acceptation pour l’usage prévu.

## Réunir quatre éléments

Utilisez le profil de risque écrit existant, approuvé par votre organisation. Il doit préciser le responsable métier, le résultat attendu, les données et destinations permises, les actions autorisées, l’autorité d’approbation, les conséquences inacceptables et les conditions d’arrêt. S’il n’existe pas, demandez aux personnes responsables de le définir avant d’évaluer le fournisseur. Ce guide ne peut pas fixer leur tolérance au risque à leur place.

[Les recommandations MANAGE 3.1 du NIST](https://airc.nist.gov/airmf-resources/playbook/manage/) demandent d’appliquer la tolérance au risque de l’organisation aux systèmes IA tiers et de documenter leurs contrôles. Le Playbook propose des suggestions volontaires, pas une liste universelle d’exigences d’achat. Les questions ci-dessous sur les contrôles d’action s’appuient aussi sur les recommandations de sécurité d’OWASP propres aux agents. Ces cadres aident à poser les bonnes questions ; les preuves du fournisseur doivent y répondre.

Nommez un fournisseur candidat, ainsi que le produit et la version de déploiement exacts envisagés. Obtenez la documentation actuelle et les preuves que le fournisseur est autorisé à partager. Donnez accès au dossier comparatif à la personne chargée de la sécurité et au responsable des achats. Conservez les fichiers d’architecture ou de preuves sensibles dans un emplacement privé approuvé ; la grille peut contenir des liens plutôt que des secrets copiés.

## 1. Transformer le processus en exigences

Énumérez chaque action proposée de l’agent, son système cible et les données à lire ou à modifier. Distinguez lecture, écriture et actions visibles à l’extérieur ou irréversibles. Pour chacune, recopiez l’exigence pertinente du profil de risque écrit : identité permise, périmètre des outils et cibles, approbation, journalisation, traitement des données, interruption et reprise. Notez le responsable du profil et sa date.

Créez une ligne par exigence. Une inconnue devient ainsi visible au lieu de disparaître dans une note globale du fournisseur. L’interdiction d’accéder à un compte particulier mérite une ligne autant qu’une action autorisée.

## 2. Retracer qui agit et ce qui peut s’exécuter

Demandez quelle personne, quel compte de service ou quelle identité d’agent déclenche chaque action, où les identifiants sont conservés et si un agent peut transmettre une demande à un autre. Identifiez le composant qui vérifie la permission au moment de l’exécution. Comparez les permissions réelles des outils du fournisseur aux outils, opérations, comptes et cibles autorisés par le profil. Demandez des preuves de configuration ou d’architecture applicables à cette version ; une phrase dans une instruction prouve peu qu’une limite est réellement imposée.

Pour les actions nécessitant une approbation, demandez ce que voit la personne qui valide avant l’exécution et comment son accord est lié à l’acteur, à l’appel d’outil exact, à la cible et aux paramètres. Vérifiez ce qui se passe si l’accord expire, est refusé, est utilisé deux fois ou si l’action demandée change. Consignez comment révoquer les accès et qui peut arrêter une exécution active. Un écran d’approbation et un contrôle à l’exécution répondent à des questions différentes ; demandez des preuves pour les deux si le profil exige les deux.

## 3. Suivre les données et les traces d’action

Dessinez le parcours proposé depuis l’entrée jusqu’au modèle, aux outils, aux destinataires externes, aux copies stockées et aux journaux. Demandez quelles données chaque composant reçoit, qui peut les récupérer et comment fonctionnent conservation et suppression. Incluez les sous-traitants ultérieurs ou transferts entre systèmes pertinents pour votre profil. Classez toute question sans réponse sur la destination ou la conservation comme **inconnue** ; ne déduisez pas une protection de la vie privée d’une déclaration générale.

Demandez une trace d’exécution pour la version concernée. La personne chargée de l’examen peut-elle relier un acteur et une version de politique à l’appel d’outil proposé, à l’approbation ou au refus, à la cible exacte et au résultat ? Vérifiez si la trace fournie montre seulement une décision, une exécution réelle ou les deux. Une capture d’écran, un export de configuration et une piste complète d’événements n’établissent pas les mêmes choses. Notez les occultations empêchant la comparaison, sans introduire d’identifiants secrets ni de données personnelles dans la grille.

## 4. Demander des preuves des scénarios d’échec

Demandez des preuves liées à la version pour une action permise et les scénarios d’échec requis par le profil : approbation refusée ou expirée, outil ou cible hors périmètre, exécution interrompue et, le cas échéant, défaillance de journalisation ou de contrôle de politique. Consignez ce qui a été testé, quand, sous quelles politiques et quels réglages d’outils, le résultat attendu et le résultat observé. Un plan de test est une demande de preuve, pas un résultat observé.

La personne responsable de la sécurité décide si une démonstration supervisée est nécessaire et en autorise le périmètre. Utilisez des entrées et comptes autorisés hors production. Ne connectez pas de systèmes en service simplement pour remplir une grille d’achat. Si le fournisseur ne peut pas apporter de preuve, notez le manque et la prochaine demande plutôt que d’imaginer le résultat d’un test.

## 5. Consigner la décision et le travail restant

Pour chaque ligne, indiquez **conforme à l’exigence** uniquement si les preuves fournies répondent à l’exigence écrite pour cette version et ce processus. Indiquez **écart** en cas de contradiction, ou **inconnu** si les preuves manquent ou sont trop faibles. Notez les traces contradictoires et la personne qui doit les départager. Le responsable métier et la personne responsable de la sécurité consignent ensuite leur véritable décision : demander davantage de preuves, solliciter l’autorisation d’un pilote limité, différer ou refuser. Une ligne jugée conforme est une appréciation des preuves, pas une garantie de sécurité ni un remplacement du processus d’achat de l’organisation.

Datez le dossier et réexaminez les lignes concernées lorsque le processus, la version du produit, la politique, les comptes connectés ou les destinations des données changent. Un pilote ultérieur exige sa propre autorisation, ses limites et son examen.

| Exigence du profil écrit | Preuves du fournisseur, version et date | Type de preuve et ce qu’elle montre | Conforme à l’exigence, écart ou inconnu | Personne chargée de l’examen et prochaine action |
| --- | --- | --- | --- | --- |
| [Une exigence d’action ou de contrôle] | [Lien privé ou référence documentaire ; version ; date] | [Affirmation, configuration, trace d’événement ou démonstration observée ; limite] | [Choisir une catégorie et expliquer] | [Nom, demande de preuve ou décision] |

**En-tête du dossier :** processus et responsable ; version du profil de risque et date d’approbation ; produit candidat et version de déploiement ; date de l’examen ; personne chargée de la sécurité ; responsable des achats ; emplacement des preuves à accès restreint. **Décision consignée :** décision, lignes non résolues, limites acceptées ou contrôles compensatoires, responsable de l’approbation et déclencheur du prochain examen. Laissez ces champs vides jusqu’à leur examen effectif par les personnes responsables.

Les recommandations publiques utilisées pour formuler ces questions sont librement accessibles. Préparer la comparaison demande du temps au personnel et aux personnes chargées de l’examen. Les preuves du fournisseur, l’accès confidentiel et toute démonstration autorisée peuvent ajouter des coûts ou limiter les vérifications ; obtenez les conditions réelles auprès du candidat. Cet exercice documentaire ne teste pas un fournisseur et n’établit ni conformité juridique ni seuil d’achat universel.

## Sources et lectures complémentaires

1. [NIST AI RMF Playbook, Manage](https://airc.nist.gov/airmf-resources/playbook/manage/) recommande d’appliquer la tolérance au risque propre à l’organisation aux ressources IA tierces, de documenter les contrôles et de les évaluer. La page indique qu’AI RMF 1.0 est en cours de mise à jour et que le Playbook suivra ; elle ne donne pas de date de révision de la page. Elle n’évalue pas ce fournisseur.
2. [Introduction du NIST AI RMF Playbook](https://airc.nist.gov/airmf-resources/playbook/) décrit les suggestions comme volontaires et précise que le Playbook n’est pas une liste à suivre intégralement. La grille proposée ici est une synthèse de BIG CHANGE pour la tâche indiquée au lecteur.
3. [OWASP AI Agent Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html) traite des outils à périmètre limité, de l’autorisation lors de l’exécution, des approbations liées aux actions, des journaux, de la protection des données et des preuves de validation liées à la version. La page actuelle n’indique ni version ni date de publication. Ces recommandations sont des catégories de preuves, pas la preuve qu’un fournisseur les met en œuvre.

## Sources

- [NIST AI RMF Playbook, Manage](https://airc.nist.gov/airmf-resources/playbook/manage/) — MANAGE 3.1 recommande d’appliquer la tolérance au risque de l’organisation aux ressources IA tierces et de documenter les contrôles. La page actuelle du Playbook AI RMF 1.0 indique qu’une révision est attendue ; aucune date de révision n’est donnée. Elle ne valide pas un fournisseur.
- [NIST AI RMF Playbook](https://airc.nist.gov/airmf-resources/playbook/) — L’introduction précise que les suggestions sont volontaires et que le Playbook n’est ni une liste exhaustive ni un ordre prescrit. La grille comparative de l’article est une synthèse éditoriale.
- [OWASP AI Agent Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html) — Les sections 1, 4, 6, 8 et 9 inspirent les questions sur les outils limités, les approbations liées aux actions, les journaux, les données et les tests liés à la version. Page actuelle sans version ni date de publication ; ces recommandations ne prouvent pas l’efficacité d’un fournisseur.