Limiter l'accès d'un agent IA à votre espace de travail

Limitez l'accès d'un agent IA comme vous limiteriez celui d'un nouveau prestataire : accordez la lecture sur les quelques zones dont il a besoin, ajoutez un périmètre d'écriture à la fois quand une tâche précise le justifie, assurez-vous que le jeton ne puisse jamais faire plus que la personne qui l'a créé, et journalisez chaque appel pour voir ce qu'il a touché. En termes MCP, cela signifie des périmètres OAuth 2.1 choisis au moment du consentement, un 403 quand l'agent en sort, et un journal d'audit côté serveur.

Cet article est la recette que nous appliquons à nos propres agents chez Atrix, avec la partie normative tirée de la spécification d'autorisation MCP et la partie produit de notre propre serveur, qui compte 49 périmètres attribuables en octobre 2026.

Pourquoi les permissions d'un agent ne sont pas celles d'un utilisateur

Une personne lit l'écran avant d'agir. Un agent lit la description d'un outil et agit en quelques millisecondes, des centaines de fois par heure, sur du texte qui peut venir d'une page web, d'un courriel ou d'un ticket écrit par quelqu'un d'extérieur à l'entreprise. L'injection de prompt est l'exemple habituel, mais les erreurs ordinaires sont plus fréquentes : un agent à qui l'on demande de « nettoyer les tickets obsolètes » et qui comprend « nettoyer » comme « supprimer ».

Deux conséquences en découlent. D'abord, le rayon de dégâts d'une mauvaise action n'est limité que par ce que le jeton peut faire, donc le jeton doit être petit. Ensuite, vous ne pouvez pas relire chaque action à l'avance, donc il vous faut un journal assez bon pour relire après coup.

Les permissions utilisateur répondent à « que peut voir et modifier cette personne ? ». Les permissions d'agent répondent à « que peut faire ce programme au nom de cette personne, pour cette tâche, cette semaine ? ». La seconde question a une réponse plus étroite.

Ce que la spécification d'autorisation MCP vous donne

La spécification d'autorisation du Model Context Protocol (révision 2025-06-18, la version en vigueur en octobre 2026) traite le serveur MCP comme un serveur de ressources OAuth 2.1 et le client MCP comme un client OAuth 2.1. Les parties qui comptent pour le périmétrage :

Exigence	Ce que cela signifie pour vous
Les serveurs DOIVENT publier des Protected Resource Metadata (RFC 9728) et répondre 401 avec un pointeur `WWW-Authenticate`	Le client découvre lui-même le serveur d'autorisation ; personne ne colle de jeton dans un fichier de configuration
Les clients DOIVENT utiliser PKCE et DEVRAIENT gérer l'enregistrement dynamique du client (RFC 7591)	L'hôte de l'agent s'enregistre seul et lance le consentement dans le navigateur
Les clients DOIVENT envoyer le paramètre `resource` (RFC 8707) et les serveurs DOIVENT valider l'audience du jeton	Un jeton émis pour un serveur ne peut pas être rejoué contre un autre
401 pour un jeton absent ou invalide, 403 pour des périmètres invalides ou des permissions insuffisantes	Les échecs de périmètre sont explicites : un agent distingue « interdit » de « non connecté »
Les serveurs d'autorisation DEVRAIENT émettre des jetons d'accès de courte durée et DOIVENT faire tourner les jetons de rafraîchissement des clients publics	Un jeton fuité expire ; un jeton de rafraîchissement volé est repéré à l'usage suivant
Le passthrough de jeton est interdit	Un serveur ne peut pas transmettre votre jeton à une API en aval

La spécification laisse volontairement les noms et la granularité des périmètres à chaque serveur. Elle fournit le mécanisme (consentement, audience, 403) et vous laisse la politique. Le reste de cet article est la politique.

La recette : lectures d'abord, élargir par écriture, jamais au-delà de la personne

Cinq règles, dans l'ordre où nous les appliquons.

Commencez par des périmètres de lecture seulement, sur les zones que la tâche touche. Un agent qui rédige le point hebdomadaire doit lire les tickets, les objectifs et le fil. Il n'a pas besoin de lire les clients, la paie ou le recrutement. Choisissez trois ou quatre périmètres de lecture et arrêtez-vous.
Ajoutez un périmètre d'écriture seulement quand une tâche nommée en a besoin, et seulement celui-là. « Commenter le ticket qu'il a implémenté » demande l'écriture de tickets. Pas l'écriture de projets, de pages, ni la possibilité de publier dans le fil de l'équipe. Qu'un périmètre d'écriture implique sa lecture est acceptable ; l'inverse n'est jamais vrai.
Traitez les actions destructrices et tournées vers l'extérieur comme des attributions séparées. Supprimer, publier, envoyer un courriel et notifier sont les actions irréversibles. Gardez-les derrière leurs propres périmètres et, idéalement, derrière une confirmation visible par la personne.
Un jeton ne doit jamais dépasser la personne qui l'a émis. Si un jeton d'agent pouvait lire quelque chose que son propriétaire ne peut pas, les périmètres seraient devenus un moyen d'escalade. Résolvez les permissions du propriétaire à chaque appel, pas à l'émission, pour que révoquer le propriétaire révoque l'agent.
Auditez chaque appel, et lisez l'audit. Nom de l'outil, résultat, type et id de ce qui a été touché. Pas le contenu : un journal d'audit plein de données clients est une seconde fuite en attente.

Le mode de défaillance à éviter est l'écran de consentement « tout connecter », où l'hôte de l'agent demande tous les périmètres d'un coup et où la personne approuve parce que la liste est longue. Les listes courtes sont lues.

Exemple réel : les 49 périmètres d'Atrix AI

Le serveur MCP d'Atrix est celui que nous administrons, c'est donc l'exemple honnête. En octobre 2026, il compte 85 outils derrière 49 périmètres attribuables, listés dans la documentation développeurs. Les choix de conception recoupent les règles ci-dessus :

Des paires lecture/écriture par zone : work.read, work.write, crm.read, crm.write, pages.read, pages.write, etc. Un périmètre d'écriture implique sa lecture ; rien d'autre n'est implicite.
Des périmètres nommés pour les actions irréversibles ou tournées vers l'extérieur : destructive, publish, email.send, feed.post. Ils ne sont jamais impliqués par un périmètre d'écriture. feed.post est séparé de feed.write parce que publier notifie les téléphones des gens sans possibilité de refus.
Neuf périmètres exigent aussi la permission correspondante sur le compte derrière le jeton : montants des affaires, dossiers d'emploi, accords, recrutement, intégrations, facturation, factures et changement de produits. La permission est vérifiée à chaque appel, donc un jeton ne peut jamais faire plus que son créateur, et révoquer l'accès de quelqu'un coupe immédiatement la portée de ses jetons.
La paie n'est pas attribuable du tout. Aucun périmètre n'atteint un salaire et aucun outil ne sélectionne un dossier de rémunération. Certaines données ne doivent pas être à un clic de consentement d'un agent, et le moyen de le garantir est de les laisser hors de la liste des périmètres.
Limites et audit : 120 appels et 30 écritures par minute et par jeton ; chaque appel journalisé avec l'outil, le résultat, le type et l'id du sujet, jamais le contenu.

Ce que cela coûte : un coéquipier qui connecte Claude ou Cursor voit un sélecteur de périmètres et doit réfléchir trente secondes. Le serveur de Linear, en comparaison, propose une URL séparée en lecture seule, une façon plus simple d'exprimer « lectures seulement ». Les deux approches fonctionnent ; la nôtre met la décision sur la personne, la leur sur l'URL.

Step-up : élargir quand la tâche le demande, pas avant

L'alternative à l'attribution de périmètres d'écriture dès le départ est l'autorisation step-up : l'agent tourne en lecture, reçoit un 403 à sa première écriture, et l'hôte demande à la personne d'approuver le périmètre supplémentaire pour cette session. L'entrée du glossaire sur l'autorisation step-up décrit le motif ; la spécification le permet via le 403 et un nouveau tour de consentement.

En pratique, cela se passe ainsi. L'agent rédige le rapport d'état (lectures seulement). Vous approuvez le brouillon. Il demande feed.post pour le publier. Vous l'accordez à ce jeton, ou vous publiez le brouillon vous-même. Le périmètre d'écriture existe exactement le temps dont la tâche a besoin.

Le step-up est plus lent qu'une attribution large le premier jour et plus rapide dès le deuxième, parce que l'ensemble des périmètres qu'un agent a mérités cesse de grandir une fois ses tâches stables.

Une liste à coller dans votre politique de sécurité

Les agents s'authentifient en OAuth 2.1 via le consentement de l'hôte ; pas de clés de longue durée dans les fichiers de configuration, sauf en CI.
Chaque jeton d'agent liste ses périmètres, son propriétaire, sa date de création et sa dernière utilisation.
L'attribution par défaut est la lecture seule sur au plus quatre zones.
Les périmètres d'écriture sont accordés par tâche et revus chaque mois.
Les actions destructrices, de publication, de courriel et de notification exigent leur propre périmètre et une confirmation humaine.
Les permissions du propriétaire sont résolues à chaque appel ; révoquer le propriétaire révoque l'agent.
Des limites de débit existent par jeton.
Le journal d'audit enregistre l'outil, le résultat, le type et l'id du sujet, et il est relu chaque semaine.
Certaines données (la paie, au minimum) ne sont atteignables par aucun périmètre.

FAQ

Que sont les périmètres MCP ?

Des périmètres OAuth 2.1 qu'un serveur MCP définit pour limiter ce qu'un jeton peut faire, choisis par la personne sur l'écran de consentement. La spécification MCP exige que les serveurs répondent 403 quand un appel dépasse les périmètres du jeton. Les noms et la granularité dépendent de chaque serveur ; voir l'entrée du glossaire sur les périmètres.

Un agent IA doit-il avoir les mêmes permissions que son utilisateur ?

Non. Les permissions de l'utilisateur sont le plafond, pas la valeur par défaut. Commencez par des périmètres de lecture sur les zones que la tâche touche et ajoutez les écritures une à une. Le jeton doit résoudre les permissions de l'utilisateur à chaque appel pour ne jamais les dépasser.

Une clé d'API dans un fichier de configuration est-elle acceptable pour un agent ?

En CI, sans navigateur, oui, avec les périmètres les plus étroits et un calendrier de rotation. Sur le portable d'une personne, préférez le flux OAuth : le jeton est limité, de courte durée, renouvelable et révocable, et la spécification impose PKCE et la liaison d'audience.

Comment savoir ce qu'un agent a réellement fait ?

Par le journal d'audit du serveur. Demandez le nom de l'outil, le résultat, le type et l'id de ce qui a été touché, avec horodatage. Si le serveur ne journalise que les contenus ou que les erreurs, vous ne pouvez pas reconstituer une session.

Que ne faut-il jamais pouvoir accorder à un agent ?

Tout ce dont l'exposition serait irréversible et dont l'usage par un agent n'a aucun but courant. Pour nous, c'est la paie. Votre liste peut ajouter des données de santé, des coordonnées bancaires ou des secrets du code. La protection est structurelle : pas de périmètre, pas d'outil.

Qu'est-ce que l'autorisation step-up en MCP ?

Faire tourner un agent avec des périmètres étroits et n'élargir que lorsqu'un appel précis renvoie 403, par un nouveau tour de consentement pour le périmètre supplémentaire. Les attributions restent liées aux tâches plutôt qu'à une supposition initiale.

Prochaine étape

Ouvrez l'écran de consentement de l'hôte d'agents que vous utilisez et comptez les périmètres demandés par défaut. Si la réponse est « tous », c'est la première chose à changer. La page MCP d'Atrix liste les 49 périmètres et ce que chacun débloque, et la documentation développeurs indique les périmètres requis par chaque outil.

Comment limiter l'accès d'un agent IA à votre espace de travail : périmètres MCP, moindre privilège et piste d'audit