Un agent peut lire un ticket, interroger une application et proposer une action. Dès qu’il obtient des droits d’écriture ou d’envoi, il devient un acteur du système d’information. Le bon point de départ consiste à décrire les actions autorisées et leurs limites, indépendamment de la qualité apparente de ses réponses.
En résumé
- Un cas d’usage doit préciser les données accessibles et les actions autorisées.
- L’autorisation doit être vérifiée par le composant qui exécute l’action, pas seulement par une instruction donnée au modèle.
- Une validation humaine doit porter sur une action et des paramètres précis.
- Les tests doivent inclure des demandes hors périmètre, des contenus trompeurs et des erreurs d’outil.
- Un responsable, des traces utiles et une procédure de suspension sont nécessaires au suivi opérationnel.
Décrire un contrat d’action
Prenons un scénario fictif : un assistant prépare les réponses du support. Son rôle initial est de consulter une base de connaissances et de rédiger un brouillon. Envoyer le message au client, modifier son contrat ou créditer son compte sont d’autres capacités, qui doivent faire l’objet de décisions distinctes.
Écrivez une fiche : propriétaire, utilisateurs autorisés, données accessibles, outils disponibles, actions interdites et conditions de suspension. Cette fiche sert de base à la configuration et aux essais ; elle ne doit pas rester une simple présentation du projet.
Limiter les droits à chaque outil
Les recommandations OWASP sur la sécurité des agents demandent notamment des permissions limitées par outil et une autorisation vérifiée au moment de l’exécution. Une instruction du type « ne consulte que les dossiers autorisés » ne remplace pas un contrôle d’accès sur le service appelé.
Dans notre exemple, l’outil de lecture doit recevoir l’identité et le contexte d’autorisation utiles. Il ne doit pas accepter qu’un simple identifiant de dossier permette de franchir une séparation entre clients. Le test vise le résultat du contrôle côté service, même si la réponse du modèle semble raisonnable.
Rendre les validations compréhensibles
Présentez à l’approbateur l’opération exacte, sa cible et les données qui vont sortir du système. Si l’adresse du destinataire ou le contenu change, une validation précédente ne doit pas couvrir silencieusement la nouvelle opération. La même fiche d’action sert à l’utilisateur et à la vérification technique.
Un clic sur « continuer » sans explication apporte peu de contrôle. Dans le scénario support, l’utilisateur doit voir le destinataire et le message final avant l’envoi. Les cas particuliers, comme un envoi groupé ou une pièce jointe sensible, demandent leurs propres conditions.
Construire une recette avec des cas limites
- Un utilisateur demande l’accès à un dossier qui ne lui appartient pas : le service refuse.
- Un document de référence contient une instruction d’envoi externe : elle ne devient pas une autorisation.
- Un outil est indisponible : l’agent signale la limite et ne fabrique pas une confirmation.
- La cible change après validation : l’action ne reprend pas l’ancienne approbation.
- Le traitement se répète : les protections empêchent les doubles opérations prévues comme uniques.
Ces scénarios sont des propositions de recette à adapter. Consignez la version, les entrées de test, le résultat attendu et le résultat constaté. Un changement de modèle, d’outil ou de règles peut nécessiter de rejouer les essais concernés.
Prévoir l’exploitation dès le départ
Définissez qui analyse un comportement inattendu et comment suspendre les actions. Les traces doivent permettre de reconstituer une décision sans enregistrer inutilement des secrets ou des données personnelles. Un déploiement progressif permet de vérifier les hypothèses sur un périmètre limité avant son extension.
Le contrôle des actions d’un agent s’inscrit dans la gestion des accès et des responsabilités. Notre constat illustratif sur un agent de support montre comment transformer un écart en action vérifiable.