Tokens MCP limitados a un espacio de trabajo: dale a un agente un tablero compartido, no toda tu cuenta

Crea un token MCP adicional desde Cuenta → Tokens MCP adicionales, elige un espacio de trabajo en el menú desplegable y ese token solo podrá leer y escribir tareas en ese tablero: tiene acceso a un conjunto más reducido de herramientas, y cualquier cosa fuera de su espacio de trabajo responde “no encontrado” en lugar de un error de permisos. Es el tercer eje para acotar un token de Done, junto a solo lectura y un solo proyecto, y existe precisamente para el momento en que una cuenta pertenece a más de un espacio de trabajo: sin él, un token llega a todos los tableros que la cuenta puede ver, incluido el del agente.

¿Por qué no basta con limitar a un proyecto cuando compartes un espacio de trabajo?

Un token limitado a un proyecto ya era la opción más restrictiva, pero un proyecto vive dentro de un único espacio de trabajo: no puede cruzar tableros, pero tampoco puede cubrir “todo lo que hay en este espacio de trabajo compartido, incluidos los proyectos que se agreguen después”. Cuando una cuenta pertenece a más de un espacio de trabajo —uno personal y otro compartido con cada grupo de colaboradores—, un token sin más límites llega a todos a la vez, porque leer no es una acción que se pueda restringir llamada por llamada. Es una propiedad del alcance, no de una invocación concreta, así que hay que aplicarla a nivel de credencial.

Cómo se aplica un token limitado a un espacio de trabajo

Igual que con los proyectos: una lista de permitidos que deniega por defecto (WORKSPACE_TOOLS en lib/mcp.ts), a la que hay que agregar explícitamente una herramienta antes de que un token limitado a un espacio de trabajo pueda llamarla; nunca al revés. project_id y workspace_id son mutuamente excluyentes en un mismo token y se rechazan juntos al crearlo, ya que un token limitado a un proyecto ya está confinado al espacio de trabajo de ese proyecto, y combinar ambos solo abre la puerta a una configuración que podría contradecirse.

Qué puede seguir haciendo un agente con un token limitado a un espacio de trabajo

• Todo el ciclo de vida de las tareas en ese tablero: list_tasks, list_my_tasks y next_task (con el filtro de espacio de trabajo forzado al del token, para que quien llama no pueda ampliarlo), get_task, update_task, comment_on_task, complete_task, propose_completion, claim_task, decline_task, release_task y el seguimiento de ejecuciones (start_run, end_run, check_budget).
• create_task, forzada al espacio de trabajo del token, así que no puede crear una tarea en un proyecto o una tarea padre que viva en otro lado.
• list_projects y list_workspaces, pero filtradas a ese único tablero: los nombres de los demás espacios de trabajo de la cuenta nunca aparecen en la respuesta.

Lo que se rechaza, en lugar de limitarse a medias

Todo lo que lee a nivel de cuenta sin un filtro de espacio de trabajo propio —get_digest, search_activity, list_tags, list_goals, changes_since, list_triggers— hoy se rechaza por completo para un token limitado a un espacio de trabajo, en vez de entregar una lectura parcial que abarque en silencio todos los tableros. Una herramienta que se agregue a Done más adelante tampoco hereda acceso por defecto: queda rechazada para estos tokens hasta que alguien decida cómo se acota, y una prueba del repositorio (tests/scoped-tokens.test.ts) verifica que la lista de permitidos coincida exactamente con lo que se aplica, de modo que una herramienta nueva sin acotar rompe el build en lugar de filtrar datos sin que nadie lo note. La lista de herramientas anunciada también lo respeta: a un cliente limitado a un espacio de trabajo ni siquiera se le muestra una herramienta que no puede llamar, en lugar de mostrársela y rechazarla al momento de usarla.

¿El límite también cubre el flujo de eventos en vivo?

Sí. /api/events acepta un token MCP de portador igual que /mcp, así que un límite que solo cubriera las llamadas a herramientas le entregaría igualmente a una credencial limitada a un espacio de trabajo los cambios de tareas, comentarios y solicitudes a agentes de todos los demás tableros a través del flujo: la misma fuga por otra puerta. La conexión SSE aplica exactamente la misma verificación de espacio de trabajo.

Cómo configurar uno

En Cuenta → Tokens MCP adicionales, el selector de espacio de trabajo solo aparece cuando la cuenta realmente pertenece a más de un espacio de trabajo; si no, no hay nada que acotar. Al elegir un espacio de trabajo se borra cualquier proyecto seleccionado (son mutuamente excluyentes); el token se muestra una sola vez al crearlo, como cualquier otro token de Done, así que cópialo antes de salir de la página.

¿Necesito un plan de pago para esto?

No. Tal como está hoy, crear un token limitado a un espacio de trabajo no tiene ninguna verificación de plan en todo el camino, desde el panel de Cuenta hasta la API y la capa de datos, así que está disponible en cualquier plan. Además es útil antes de lo que “compartir un espacio de trabajo con un compañero” podría sugerir: el plan Gratis ya permite hasta dos espacios de trabajo por cuenta, así que incluso alguien que trabaja solo y mantiene, por ejemplo, un tablero personal y otro aparte puede conectar un agente a uno solo de ellos sin invitar a nadie ni mejorar su plan.

Cómo encaja con los tokens de solo lectura y los limitados a un proyecto

Los tres ejes acotan lo que una credencial puede hacer o alcanzar; no reemplazan la aprobación, que controla por separado lo que un agente puede terminar sin que una persona lo apruebe. Usa el límite por espacio de trabajo cuando lo que quieres darle a un agente es “todo este tablero compartido”, el límite por proyecto cuando es algo más acotado, y solo lectura encima de cualquiera de los dos cuando el agente solo debe observar. Tener más de un agente trabajando sobre una cuenta compartida es mucho más fácil de razonar cuando el alcance de cada token está escrito en la propia credencial y no en una política que nadie vuelve a revisar.