Jetons MCP limités à un espace de travail : un agent IA, un seul tableau

Créez un jeton MCP supplémentaire depuis Compte → Jetons MCP supplémentaires et choisissez un espace de travail dans la liste déroulante. Ce jeton ne peut alors lire et écrire des tâches que sur ce tableau : il appelle un ensemble d’outils plus restreint, et tout ce qui se trouve hors de son espace de travail revient comme « introuvable » plutôt que comme une erreur d’autorisation. C’est le troisième axe de restriction d’un jeton Done, à côté de la lecture seule et du projet unique. Il existe précisément pour le moment où un compte appartient à plusieurs espaces de travail : sans lui, un jeton atteint tous les tableaux que le compte peut voir, agent compris.

Pourquoi la restriction à un projet ne suffit-elle plus quand vous partagez un espace de travail ?

Un jeton limité à un projet était déjà l’option la plus étroite, mais un projet vit dans un seul espace de travail. Il ne peut pas s’étendre à d’autres tableaux, mais il ne peut pas non plus couvrir « tout ce qui se trouve dans cet espace de travail partagé, quels que soient les projets qu’on y ajoutera plus tard ». Dès qu’un compte appartient à plusieurs espaces de travail (un espace personnel, plus un autre partagé avec chaque groupe de collaborateurs), un jeton sans autre restriction les atteint tous à la fois, parce que la lecture n’est pas une action que l’on peut filtrer appel par appel. C’est une propriété de la portée, pas d’un appel d’outil isolé. Elle doit donc être appliquée au niveau de l’identifiant.

Comment la restriction à un espace de travail est appliquée

De la même façon que la restriction à un projet : une liste d’autorisation qui refuse tout par défaut (WORKSPACE_TOOLS dans lib/mcp.ts), à laquelle un outil doit être ajouté explicitement avant qu’un jeton limité à un espace de travail puisse l’appeler. Jamais l’inverse. project_id et workspace_id s’excluent mutuellement sur un même jeton et sont refusés ensemble à la création : un jeton limité à un projet est déjà confiné au seul espace de travail de ce projet, et associer les deux ne ferait qu’ouvrir la porte à une combinaison contradictoire.

Ce qu’un agent peut encore faire avec un jeton limité à un espace de travail

• Tout le cycle de vie des tâches sur ce tableau : list_tasks, list_my_tasks et next_task (leur filtre d’espace de travail est forcé sur celui du jeton, l’appelant ne peut donc pas l’élargir), get_task, update_task, comment_on_task, complete_task, propose_completion, claim_task, decline_task, release_task, ainsi que le suivi des exécutions (start_run, end_run, check_budget).
• create_task, forcé dans l’espace de travail du jeton : il ne peut donc pas créer une tâche dans un projet ou sous une tâche parente qui se trouve ailleurs.
• list_projects et list_workspaces, mais filtrés sur ce seul tableau : les noms des autres espaces de travail du compte ne figurent jamais dans la réponse.

Ce qui est refusé, et non restreint à moitié

Tout ce qui lit l’ensemble du compte sans filtre d’espace de travail propre (get_digest, search_activity, list_tags, list_goals, changes_since, list_triggers) est aujourd’hui refusé purement et simplement à un jeton limité à un espace de travail, plutôt que livré sous la forme d’une lecture partielle qui s’étendrait discrètement à tous les tableaux. Un outil ajouté plus tard à Done n’hérite pas non plus de l’accès par défaut : il est refusé à un jeton limité à un espace de travail jusqu’à ce que quelqu’un décide comment il se restreint. Un test du dépôt (tests/scoped-tokens.test.ts) vérifie que la liste d’autorisation reste exhaustive par rapport à sa propre application, si bien qu’un ajout sans restriction fait échouer le build au lieu de fuiter en silence. La liste d’outils annoncée en tient compte elle aussi : un client limité à un espace de travail ne se voit même pas présenter un outil qu’il n’a pas le droit d’appeler, au lieu de le voir puis d’essuyer un refus à l’appel.

La restriction couvre-t-elle aussi le flux d’événements en direct ?

Oui. /api/events accepte un jeton MCP bearer de la même façon que /mcp. Une restriction qui ne couvrirait que les appels d’outils livrerait donc quand même à un identifiant limité à un espace de travail les modifications de tâches, les commentaires et les demandes d’agent de tous les autres tableaux par le flux : la même fuite par une autre porte. La connexion SSE applique exactement la même vérification d’espace de travail.

Comment en configurer un

Dans Compte → Jetons MCP supplémentaires, le sélecteur d’espace de travail n’apparaît que si le compte appartient réellement à plusieurs espaces de travail. Sinon, il n’y a rien à restreindre. Choisissez un espace de travail, et toute sélection de projet est effacée (les deux s’excluent mutuellement). Le jeton n’est affiché qu’une seule fois, à la création, comme tous les autres jetons Done : copiez-le avant de quitter la page.

Faut-il une offre payante pour cela ?

Non. Dans la version actuelle, la création d’un jeton limité à un espace de travail ne comporte aucune vérification d’offre sur tout le parcours, du panneau Compte à la couche de données en passant par l’API. Elle est donc disponible aujourd’hui avec n’importe quelle offre. Elle sert aussi plus tôt que ne le laisse penser l’idée de « partager un espace de travail avec un collègue » : l’offre gratuite autorise déjà jusqu’à deux espaces de travail par compte. Même une personne seule qui tient, par exemple, un tableau personnel et un autre à part peut donc relier un agent à un seul des deux, sans inviter qui que ce soit ni changer d’offre.

Comment cela s’articule avec les jetons en lecture seule et limités à un projet

Les trois axes restreignent ce qu’un identifiant a le droit de faire ou d’atteindre. Ils ne remplacent pas l’étape d’approbation, qui contrôle séparément ce qu’un agent peut terminer sans la validation d’un humain. Utilisez la restriction à un espace de travail quand l’unité que vous voulez confier à un agent est « tout ce tableau partagé », la restriction à un projet quand c’est plus étroit que cela, et la lecture seule par-dessus l’une ou l’autre quand l’agent doit seulement observer. Faire tourner plusieurs agents sur un compte partagé devient plus simple à comprendre quand la portée de chaque jeton est inscrite dans l’identifiant lui-même plutôt que dans une règle que personne ne revérifie.