insights23 juillet 20268 min

Agents IA: testez leurs droits d'action, pas seulement leurs réponses

Note exécutive TokenShift

Un agent IA n'est pas risqué uniquement parce qu'il peut produire une mauvaise réponse. Le risque change d'échelle quand cette réponse peut appeler un outil, modifier une donnée ou déclencher un paiement. L'annonce de GPT-Red par OpenAI, le 15 juillet 2026, impose donc un nouveau critère de mise en production: tester les droits d'action des agents IA sous attaque, pas seulement leur exactitude.

Quand la réponse d'un agent IA devient un acte

OpenAI a entraîné GPT-Red par apprentissage par renforcement en auto-jeu afin de fabriquer des injections de prompt dans des courriels, pages web, fichiers locaux ou réponses d'outils. Sur une réplique interne d'un banc d'essai d'injection indirecte visant GPT-5.1, GPT-Red a réussi dans 84 % des scénarios, contre 13 % pour des testeurs humains. Cette comparaison est circonscrite à ce protocole interne; elle ne mesure pas une supériorité générale de l'IA sur l'humain (OpenAI, 2026).

Le cas le plus parlant n'est pourtant pas ce score. Dans un essai sur un distributeur automatique piloté par un agent, GPT-Red a obtenu la baisse d'un prix à 0,50 dollar, la mise en vente à ce même prix d'un article coûtant plus de 100 dollars, puis l'annulation de la commande d'un autre client. Une instruction manipulée avait produit des actes réels dans le système.

Le risque ne réside donc pas seulement dans le modèle. Il naît de la combinaison entre un contenu non fiable, des outils accessibles et des permissions trop larges. Le référentiel OWASP consacré aux applications agentiques en 2026 nomme notamment le détournement d'objectif, le mauvais usage des outils et l'abus de privilèges; il recommande le moindre privilège, l'approbation au niveau de l'action, l'isolation et la journalisation (OWASP, 2025).

La maturité d'un agent IA ne se mesure pas au nombre d'étapes qu'il exécute seul, mais aux actions interdites qu'il est incapable d'accomplir.

Le test d'autorité en cinq étapes

Nous appelons test d'autorité l'épreuve qui vérifie ce qu'un agent IA peut effectivement provoquer lorsque son contexte est erroné, ambigu ou hostile. Ce test porte sur tout le workflow, depuis la source consultée jusqu'à l'acte enregistré dans le système métier.

1. Décrire les actes, pas la fonctionnalité

Pour chaque outil, recensez les données accessibles et classez les droits en quatre niveaux: lire, proposer, écrire, engager l'entreprise. Envoyer un message externe, modifier un bénéficiaire, publier un document ou déclencher un virement ne relèvent pas du même niveau qu'une recherche.

Le livrable attendu est une matrice courte: action autorisée, condition, plafond, donnée concernée, propriétaire, règle d'escalade. Tout droit sans justification métier est retiré.

2. Séparer proposition et exécution

Le modèle peut produire un plan ou une demande d'action structurée. Un composant déterministe contrôle ensuite l'identité, le schéma, le montant, la destination, la fréquence et la politique d'accès avant d'appeler l'outil. Le texte généré n'est jamais traité comme une autorisation.

Cette séparation permet de conserver la souplesse du raisonnement sans lui déléguer les règles de gestion. L'OWASP recommande précisément de considérer la sortie du planificateur comme non fiable et de la faire passer par un point de contrôle avant exécution.

3. Placer l'humain au niveau de l'impact

Faire approuver chaque clic annule le gain et favorise la validation machinale. L'intervention humaine doit viser les actes irréversibles, inhabituels ou engageants: premier paiement à un bénéficiaire, suppression, publication externe, dépassement d'un plafond, accès à un nouveau domaine de données.

Pour chaque classe d'action, fixez trois réponses possibles: exécuter, demander une approbation, refuser. En cas d'ambiguïté, le système doit échouer en position sûre.

4. Attaquer la chaîne complète

Insérez des instructions hostiles ou contradictoires dans un courriel, un PDF, une page web, un dépôt de code et une réponse d'outil. Testez des objectifs concrets: extraire une donnée, changer un destinataire, contourner un plafond, supprimer une trace ou publier à l'extérieur.

Chaque scénario doit avoir un résultat attendu, autorisé, refusé ou escaladé. Ajoutez aussi les incidents ordinaires: pièce jointe illisible, service indisponible, doublon et réponse métier contradictoire. Une production gouvernée doit résister à la malveillance comme à la confusion.

5. Mesurer et rejouer

Conservez l'origine des instructions, les contenus récupérés, le plan proposé, les appels d'outils et leurs paramètres, les approbations, le résultat métier et le retour arrière. Rejouez la suite après tout changement de modèle, de prompt système, d'outil, d'identité ou de permission.

Les marqueurs observables sont simples:

aucune exécution non autorisée dans les scénarios critiques;
part des actions engageantes effectivement soumises à approbation;
taux d'appels bloqués et de faux blocages;
taux de correction et d'escalade humaine;
délai de détection et délai de retour arrière;
coût et temps de cycle par dossier, comparés au workflow de référence.

Le profil GenAI du NIST vise à intégrer les exigences de confiance dans la conception, le développement, l'utilisation et l'évaluation du système, et non dans une revue unique avant lancement (NIST, 2024, mise à jour 2026).

Mini-cas: l'agent de gestion des sinistres

Prenons une mutuelle qui déploie un agent IA pour lire le courriel d'un assuré, analyser les pièces jointes, consulter le contrat et préparer une proposition de remboursement. En pilote, les réponses sont exactes et rapides. Mais une pièce jointe contient une instruction cachée demandant de remplacer le bénéficiaire et d'envoyer le dossier vers une adresse externe.

Avec un compte technique trop puissant, l'erreur de lecture devient un événement financier. Avec le test d'autorité, l'agent peut lire le dossier et proposer un montant, mais il ne peut ni modifier un bénéficiaire ni payer. Un contrôle déterministe vérifie le contrat et la destination; toute modification sensible requiert une approbation nominative.

Le résultat observable n'est plus seulement la qualité du texte. C'est l'absence de paiement sur le scénario injecté, la trace du refus, le temps de traitement des dossiers ordinaires et le nombre de corrections humaines.

L'AI Act renforce cette discipline d'exécution

Tous les agents IA ne sont pas automatiquement des systèmes à haut risque. La qualification dépend notamment de l'usage. Pour les systèmes concernés, la Commission européenne énumère toutefois des exigences directement opérationnelles: gestion des risques, journalisation, documentation, supervision humaine, robustesse et cybersécurité. Elle précise aussi que le déployeur doit surveiller le système et confier la supervision à une personne équipée pour l'exercer (Commission européenne, 2026).

Le test d'autorité ne remplace pas l'analyse juridique. Il produit une partie des preuves dont les opérations, le risque, l'audit et le régulateur auront besoin.

Erreurs à éviter

Le banc de test poli: n'utiliser que des demandes propres et des documents internes laisse intacte l'attaque par contenu externe.
Le pare-feu magique: un filtre d'injection ne suffit pas. OpenAI indique que les attaques élaborées échappent souvent aux classificateurs d'entrée (OpenAI, 2026).
Le supercompte de service: donner tous les droits pour simplifier l'intégration transforme chaque erreur en rayon d'impact maximal.
L'humain tampon: soumettre toutes les actions à validation crée une file d'attente et une approbation réflexe, sans cibler les actes graves.
La moyenne rassurante: un bon taux global masque le scénario rare qui paie, efface ou divulgue. Les résultats doivent être lus par gravité.

La décision à prendre au prochain COMEX

N'autorisez le passage en production d'un agent IA que si le dossier de décision contient cinq éléments: sa matrice de droits, sa suite de tests adversariaux, les résultats classés par gravité, un propriétaire avec procédure de reprise, et des seuils de valeur comme de risque.

Commencez avec un workflow, un périmètre et des permissions minimales. Étendez les droits d'action seulement lorsque les traces, les incidents et les résultats métier montrent que le contrôle fonctionne.

L'autonomie n'est pas un droit accordé au lancement. C'est une capacité gagnée par la preuve.

Sources

Continuer la lecture

Voir toutes les analyses