Aligner les autorisations sur la mission réelle de l'agent

Réduire le premier niveau ne règle pas le deuxième, et un rôle bien choisi au deuxième niveau peut rester trop large au troisième.

Le rôle technique disponible permet de lire, exporter, modifier, supprimer, partager et changer les permissions. La mission de l’agent : exporter un rapport sélectionné vers une destination approuvée.

Il s’agit d’un exemple d’architecture. Toutes les applications ne permettent pas d’exprimer ce découpage nativement ; lorsqu’elles ne le permettent pas, la restriction doit être portée par un composant placé entre l’agent et l’application.

OWASP identifie trois causes racines de l’agentivité excessive : fonctionnalités excessives, permissions excessives et autonomie excessive. Parmi ses exemples : une extension exposant modification et suppression quand seule la lecture est requise, ou des credentials en aval disposant de UPDATE, INSERT et DELETE quand SELECT suffit.^[1]

Ses recommandations incluent de n’exposer que les fonctions nécessaires, d’éviter les outils trop génériques, de minimiser les permissions en aval et d’exécuter les actions dans le contexte d’autorisation de l’utilisateur lorsque c’est approprié.^[1]

Pour MCP, OWASP recommande d’accorder aux serveurs les seules permissions requises, avec des credentials cloisonnés et des scopes OAuth étroits.^[2]

Le NIST définit l’ABAC comme une méthode où l’autorisation évalue des attributs du sujet, de l’objet, de l’opération demandée et, dans certains cas, de l’environnement, au regard de politiques ou de règles.^[3]

Appliqué à un agent, le contexte utile peut comprendre par exemple les attributs suivants. Cette liste est la nôtre ; le NIST ne prescrit pas de liste propre aux agents.

• agent identity
• human requester
• tool
• operation
• resource
• parameters
• destination
• data classification
• environment

01

Distinguer demandeur humain et identité de l’agent

La décision peut alors tenir compte des droits de l’utilisateur pour lequel l’agent agit.

02

Contrôler les paramètres

Autoriser « export » ne suffit pas si la destination ou le périmètre des données sont libres.

03

Externaliser la décision quand le rôle natif est trop grossier

Une politique évalue l’action précise à partir des attributs disponibles.

Un rôle natif suffisamment granulaire peut suffire dans certaines applications. Une politique externe n’est pas requise partout : elle se justifie lorsque l’écart entre le rôle disponible et la mission reste significatif.