Ce qu’il faut retenir
- Autoriser une connexion ne suffit pas : chaque opération doit contrôler l’identité, la ressource, les paramètres et l’effet demandé.
- Le moindre privilège concerne les fonctions exposées, les droits du connecteur et l’autonomie du processus.
- Une validation humaine utile montre l’action concrète, son périmètre et son résultat attendu avant exécution.
Références consultées le 1er octobre 2026. Les contrôles décrits doivent être adaptés aux services effectivement connectés.
Un agent peut lire un dossier, préparer une réponse et modifier un statut. Cette fluidité simplifie le travail, mais elle concentre aussi les risques. La demande « traite ce dossier » est trop large pour établir quelles données peuvent être modifiées, quel client peut être contacté et quand une personne doit intervenir. L’automatisation doit traduire l’intention en opérations précises.
Trois dimensions du moindre privilège
Le référentiel OWASP sur l’autonomie excessive distingue excès de fonctionnalités, de permissions et d’autonomie. Ces dimensions peuvent se cumuler. Un outil limité à la lecture peut utiliser un compte trop privilégié ; un compte restreint peut servir un outil trop général ; une opération légitime peut être exécutée sans la validation prévue.
Les fonctionnalités sont les actions que le modèle peut demander. Les permissions sont les droits réels de l’identité qui les exécute. L’autonomie décrit jusqu’où le processus peut avancer sans intervention. Chacune mérite une règle et un test. Une consigne « ne fais rien de dangereux » n’offre pas le même contrôle qu’une interdiction appliquée par le service.
Les connexions MCP entre agents et outils organisent les échanges, mais le protocole ne définit pas à lui seul toutes les règles métier. Exposer une fonction ne signifie pas que l’utilisateur a le droit de l’appeler sur n’importe quelle ressource. L’application conserve cette responsabilité.
Un contrat par opération
| Question | Information attendue | Exemple de contrôle |
|---|---|---|
| Qui agit ? | Utilisateur et identité technique | Correspondance vérifiée, accès au bon périmètre |
| Sur quoi ? | Identifiant de ressource et état courant | Dossier appartenant au client autorisé |
| Quelle action ? | Opération explicite et paramètres | Modification d’un champ autorisé |
| Avec quel effet ? | Changement, communication ou export | Validation requise avant un effet externe |
| Quelle preuve ? | Résultat relu après exécution | État final et identifiant durable |
Préférer une opération « ajouter une note au dossier autorisé » à une opération « exécuter une requête libre ». La première peut vérifier objet, champ et taille ; la seconde ouvre un périmètre plus difficile à borner. Cette restriction se fait dans le contrat et le service d’exécution, pas seulement dans la description présentée au modèle.
Le jeton utilisé par le connecteur doit posséder les droits nécessaires à cette opération et seulement ceux-ci, dans la mesure permise par le service. Le secret reste hors du contexte de génération. Si le service ne permet pas une restriction assez fine, l’application ajoute une passerelle et limite le périmètre ; elle ne doit pas prétendre que la restriction existe dans le compte fournisseur.
Éviter le compte générique qui voit tout
Une application peut utiliser une identité de service pour des raisons pratiques. Elle doit alors appliquer les droits de l’utilisateur avant la lecture et avant la mutation. Un filtre fourni par le modèle n’est pas une preuve d’autorisation. La ressource et l’utilisateur doivent être contrôlés à partir de données de session et du référentiel d’accès.
Un utilisateur peut perdre un droit entre lecture et exécution. Revalider au moment de l’action protège contre cet écart. Les paramètres sensibles sont liés à l’approbation : si le destinataire, le montant ou l’objet change, la validation précédente peut ne plus couvrir la nouvelle opération. Une autorisation est un périmètre, pas une bénédiction générale du workflow.
La conception des intégrations API doit prévoir ces contrôles avec leurs erreurs. Un refus d’accès n’est pas un incident à contourner automatiquement en changeant de connecteur ou de compte. Il rejoint un circuit de diagnostic explicite.
Faire approuver une action compréhensible
Une fenêtre qui demande « autoriser l’outil ? » informe peu. Pour une action sensible, présenter objet concerné, état actuel, changement proposé et effet externe. Une communication montre destinataire, contenu et pièces jointes. Une suppression identifie les objets et la portée. L’approbation doit correspondre à la proposition effectivement exécutée.
Une longue liste de validations peut fatiguer les utilisateurs et conduire à une acceptation réflexe. Regrouper les opérations réversibles et connues lorsque le métier le permet, tout en gardant les effets sensibles clairement visibles. Le seuil dépend du processus : lire une fiche, ajouter une note et envoyer un message à un client n’ont pas les mêmes conséquences.
La validation ne répare pas une interface qui cache les informations nécessaires. L’opérateur doit pouvoir ouvrir la preuve, comprendre le périmètre et refuser sans perdre la préparation déjà réalisée. Une approbation horodatée peut être conservée sans recopier tous les contenus sensibles dans un journal plus largement accessible.
Un agent de support qui prépare, puis agit sous contrôle
Scénario hypothétique. Un service veut qu’un agent recherche des pièces, résume un dossier et prépare une modification de statut. Il peut lire les documents du dossier autorisé et ajouter une note interne. La modification du statut passe par une opération dédiée qui relit l’état courant. Les envois externes et suppressions restent dans un circuit de validation distinct.
Un document contient une phrase demandant de contacter une adresse nouvelle. L’agent peut la résumer comme demande du client ; elle ne devient pas une autorisation d’envoi. Le service ne donne pas à l’agent un outil universel de messagerie dans l’étape de préparation. Les risques d’injection indirecte décrits par OWASP justifient cette barrière indépendante de la bonne volonté du modèle.
La recette utilise des dossiers factices qui se ressemblent, des droits révoqués et des changements concurrentiels. Elle vérifie qu’un refus interrompt l’action plutôt que de déclencher une autre route. Après modification, le résultat est relu dans le système cible. La proposition produite, l’appel envoyé et l’état obtenu restent trois preuves différentes.
Réconcilier avant de réessayer
Un timeout peut survenir après que le service a exécuté l’action. Répéter immédiatement l’appel peut dupliquer une note, un message ou une commande. Utiliser une clé d’idempotence lorsque le service la permet et conserver un identifiant d’opération. En cas d’ambiguïté, consulter le résultat ou l’état avant d’autoriser une nouvelle tentative.
L’agent doit savoir rapporter « résultat à vérifier » sans inventer un succès ni provoquer une nouvelle exécution. Les essais couvrent réponse perdue, traitement retardé, erreur partielle et action déjà effectuée. Une procédure humaine de résolution reste nécessaire lorsque l’API ne permet pas de trancher automatiquement.
Les plafonds de durée, volume et nombre d’appels limitent les effets d’une boucle. Ils contribuent aussi à maîtriser le coût complet des agents et de leurs infrastructures. À l’arrêt, le système indique les opérations effectuées et celles qui restent en attente.
La checklist avant extension des capacités
- Inventorier les opérations. Distinguer lecture, préparation, mutation et effet externe.
- Réduire les droits. Retirer les fonctions inutiles et tester le compte technique sur des objets interdits.
- Valider les paramètres hors modèle. Vérifier types, ressources, état courant et politique métier.
- Lier approbation et action. Conserver ce qui a été validé et refuser un changement de périmètre non couvert.
- Vérifier le résultat. Relire la ressource ou consulter un identifiant durable, avec traitement des ambiguïtés.
- Tester l’arrêt. Révocation, panne et plafond doivent laisser un état compréhensible pour les opérations.
Le dossier sur la sécurité des agents IA peut servir à élargir cette recette. La présente méthode ne garantit pas l’absence de défaut dans un connecteur ou une API ; elle réduit le périmètre d’un échec et rend la décision observable.
Sources et références
Sources primaires consultées le 1er octobre 2026 : OWASP, Excessive Agency ; OWASP, Prompt Injection. Le contrat d’opérations et le scénario sont des recommandations de conception, sans certification de sécurité revendiquée.
