Jetons MCP en lecture seule et limités à un projet pour les agents IA

« Dois-je donner à un agent IA l’accès à ma liste de tâches ? » recouvre en réalité trois questions distinctes : que peut-il voir, à quelle vitesse puis-je lui couper l’accès si quelque chose cloche, et qu’est-ce qui demande encore ma validation même lorsqu’il est connecté ? Aucune ne dépend du modèle que vous utilisez. Ce sont des propriétés de la façon dont le serveur applique les accès, pas du jugement de l’agent.

Pourquoi la portée compte plus que le modèle

Un agent ne peut faire que ce que ses identifiants lui permettent, quelles que soient les capacités ou la prudence du modèle sous-jacent. C’est une garantie volontairement banale, côté serveur, plutôt qu’un espoir sur le comportement du modèle. C’est pour la même raison que vous limiteriez une clé d’API de n’importe quel autre service à ce dont elle a exactement besoin, et non à tout ce qu’elle pourrait théoriquement toucher.

Accès complet, lecture seule ou un seul projet

Chaque compte a son propre point d’accès MCP et ses propres jetons, jamais un jeton partagé ou global. Avec Pro et Teams, un jeton peut être restreint davantage : en lecture seule, pour qu’un agent puisse voir la file et le contexte des commentaires sans jamais rien modifier, ou à un seul projet, pour qu’il ne voie que les tâches de ce projet et rien du reste de votre compte. Commencez plus étroit que ce dont vous pensez avoir besoin. Élargir plus tard est facile. Restreindre après coup veut dire que vous faites confiance à un agent qui a déjà eu un accès plus large.

Révoquer l’accès instantanément

Régénérer ou révoquer un jeton l’invalide immédiatement, sans attendre qu’un cache expire quelque part. Et si vous réagissez à quelque chose dont vous n’êtes pas sûr, modifier ou réinitialiser votre mot de passe révoque d’un coup tous les identifiants d’API du compte, jetons MCP et applications connectées compris. Une compromission suspectée ne laisse donc pas l’accès d’un agent discrètement actif alors que vous avez déjà changé le mot de passe.

L’étape d’approbation, un second garde-fou

La restriction porte sur ce qu’un agent peut voir et toucher. L’étape d’approbation porte sur ce qu’il peut terminer sans demander. Une tâche réglée sur Clôture automatique peut être clôturée directement, ce qui convient à un travail réversible et à faible enjeu. Tout le reste passe par propose_completion et reste en attente de validation jusqu’à ce qu’un humain l’approuve, et seul un humain peut régler une tâche sur Clôture automatique. Les deux mécanismes couvrent des risques différents : la portée limite l’étendue des dégâts possibles, l’étape d’approbation limite ce qui devient définitif sans supervision.

Exécutions vérifiables et budgets

Chaque session d’agent est une exécution consignée, avec son propre budget d’appels d’outils et de temps. check_budget vous indique ce qu’il reste avant que l’enveloppe d’une session soit épuisée. Une fois l’enveloppe d’une tâche soumise à budget consommée, start_run est purement et simplement refusé, plutôt que de laisser la session continuer à crédit. C’est un troisième levier, indépendant : il ne porte ni sur l’accès ni sur le caractère définitif, mais sur ce qu’une session peut faire avant de devoir s’arrêter et revenir vers vous.

Une configuration par défaut raisonnable

Démarrez un agent en lecture seule ou limité à un seul projet, laissez la plupart des tâches hors clôture automatique, et observez quelques exécutions avant d’assouplir quoi que ce soit. Élargissez la portée du jeton, ou commencez à régler les tâches de routine sur Clôture automatique, une fois que vous avez réellement vu ce que l’agent fait de l’accès dont il dispose, pas avant. Rien de tout cela ne relève de la défiance. C’est la posture que vous adopteriez pour intégrer une nouvelle recrue dans un système où les conséquences sont réelles.