Lire ne signifie pas envoyer
Le compte peut lire un dossier fictif et préparer une note locale, mais pas l’envoyer. Attendu : lecture et brouillon possibles, envoi refusé par le contrôle. La qualité de la note ne modifie pas cette limite.
Guides pratiques approfondis
Valider les actions d’un agent IA avant de lui donner des droits
Séparer proposition, autorisation et exécution, puis vérifier les objets visés, les confirmations et les effets d’une relance.
Mise à jour :
Panneaux transparents et documents dans un espace de contrôle. Scène illustrative.
Une réponse correcte autorise-t-elle l’action qui suit ?
Une note bien rédigée ne démontre pas que son envoi est permis. L’OWASP traite l’excès de capacité d’action comme un risque distinct. La méthode proposée ici part d’un contrat concret entre une personne, une opération et un objet ; les exemples utilisent uniquement un service simulé et des données fictives.
Décrire l’effet et son périmètre
Indiquer qui peut faire quoi, sur quel dossier, pour quel destinataire et jusqu’à quand. Distinguer lire, préparer un brouillon et envoyer. Chaque étape peut avoir un droit différent ; l’accès au document ne vaut pas droit de diffusion.
Séparer les trois états
Tracer une proposition, une autorisation puis une exécution. Une phrase produite par le modèle, une case dans un document ou une ancienne conversation ne remplace pas le contrôle applicable à l’action précise.
Contrôler les paramètres réellement exécutés
Vérifier côté application l’acteur, l’objet, l’opération et les paramètres finaux. Tester un objet autorisé et un objet hors périmètre. Observer le refus effectif du service simulé, pas seulement l’explication de l’agent.
Lier la confirmation à la proposition exacte
Présenter destinataire, contenu, version et conséquence avant confirmation. Dans le contrat de test, toute modification de ces éléments invalide l’accord précédent. Refaire le contrôle des droits au moment de l’exécution, même si la proposition a déjà été approuvée.
Examiner les reprises et les révocations
Simuler une réponse perdue après un effet enregistré, puis une relance identique. Vérifier le comportement de dédoublonnage prévu, sans supposer qu’un identifiant ou une méthode HTTP suffit. Tester aussi un droit retiré entre approbation et exécution.
Situations et arbitrages
Situations types pour préparer un contrôle. Elles ne décrivent pas des missions ou observations réalisées.
Destinataire changé après confirmation
La proposition approuvée visait un destinataire de test ; l’appel final en désigne un autre. Attendu dans cette recette : pas d’effet, nouvelle proposition à examiner. Ne pas réutiliser un accord attaché à d’autres paramètres.
Effet enregistré, réponse perdue
La doublure a enregistré une opération, mais simule un délai d’attente avant de répondre. Une relance ne doit pas être assimilée à un premier essai sans consulter l’état de l’opération. Observer le nombre d’effets dans la doublure.
Autorisation révoquée entre deux étapes
Le droit de modification est retiré après l’accord humain et avant l’exécution simulée. Attendu : le contrôle à l’exécution refuse l’action. Une confirmation passée ne restaure pas un droit supprimé.
Exercice corrigé
Une opération répétée n’est pas une nouvelle autorisation
Exemple fictif : les valeurs et documents servent à apprendre la méthode, sans décrire un organisme réel.
Données de départ
Exercice fictif. Le service simulé associe chaque identifiant à des paramètres fixes et refuse leur modification. OP-17 avec le contenu v1 et le destinataire A est autorisée puis enregistrée ; sa réponse se perd. Un second appel OP-17 reprend exactement v1 et A. Un troisième reprend OP-17 avec le destinataire B. Que doit-on observer ?
À vous de vérifier
- Compter les effets enregistrés plutôt que les seuls appels.
- Vérifier si le second appel possède exactement les mêmes paramètres.
- Traiter séparément la modification du destinataire et la reprise identique.
Lire le corrigé
Corrigé et décision
Dans le contrat posé, un seul effet est enregistré. Le second appel retourne l’état de la première opération sans nouveau traitement. Le troisième est refusé comme conflit de paramètres ; il ne devient pas autorisé parce qu’il reprend OP-17. Une nouvelle cible doit faire l’objet d’une nouvelle proposition et du contrôle prévu.
Si le cas change
Si la doublure ne permet pas de retrouver l’état après le délai d’attente, le résultat reste inconnu. Ne conclure ni à l’absence d’effet ni à une réussite ; prévoir une réconciliation ou une vérification humaine avant une reprise risquée.
Trace à conserver
Noter l’accord initial, les paramètres de chaque tentative, le contrat de dédoublonnage et le nombre d’effets. Cet identifiant de démonstration ne prouve rien sur une API réelle.
Référence documentaire : OWASP — LLM06:2025 Excessive Agency · Consultée le
Preuve à conserver
- Identité et rôle de test, objets autorisés et opérations interdites.
- Proposition exacte : contenu, destinataire, version et durée de validité.
- Décision d’autorisation, paramètres contrôlés et état au moment de l’exécution.
- Identifiant d’opération, tentatives, réponses et nombre d’effets réellement enregistrés.
Références officielles
Protocoles connexes
Points à vérifier avant de conclure
- Le contrôle refuse-t-il un objet ou un destinataire hors périmètre ?
- Un changement de contenu ou de version rend-il l’ancienne confirmation inutilisable ?
- La révocation d’un droit est-elle prise en compte avant l’effet ?
- Après un délai d’attente, sait-on distinguer absence d’effet, effet confirmé et état encore inconnu ?
Questions fréquentes
Une confirmation humaine suffit-elle ?
Elle valide une proposition dans un contexte donné. Il reste à vérifier que l’action finale correspond à cette proposition et que les droits sont toujours valides.
Un délai d’attente signifie-t-il que rien ne s’est passé ?
Non. Il décrit ce que le client n’a pas reçu dans le délai prévu. Le service peut avoir enregistré l’opération ; vérifier son état avant de décider d’une reprise.
Un même identifiant garantit-il un seul effet ?
Seulement si le service applique un contrat de dédoublonnage adapté et testé. Dans l’exercice, ce contrat est explicitement posé ; ne pas l’attribuer par défaut à une API réelle.