MCP-Tokens pro Arbeitsbereich: ein KI-Agent, nur ein Board

Erstelle unter Konto → Weitere MCP-Tokens ein weiteres MCP-Token und wähle im Dropdown einen Arbeitsbereich aus. Dieses Token kann dann nur auf diesem einen Board Aufgaben lesen und schreiben. Es ruft eine kleinere Auswahl an Tools auf, und alles außerhalb seines Arbeitsbereichs kommt als „nicht gefunden“ zurück statt als Berechtigungsfehler. Das ist die dritte Achse, auf der sich ein Done-Token eingrenzen lässt, neben „Nur lesen“ und „ein einzelnes Projekt“. Es gibt sie genau für den Moment, in dem ein Konto zu mehr als einem Arbeitsbereich gehört: Ohne sie erreicht ein Token jedes Board, das das Konto sehen kann, und der Agent damit auch.

Warum reicht die Beschränkung auf ein Projekt nicht mehr, sobald du einen Arbeitsbereich teilst?

Ein auf ein Projekt beschränktes Token war bisher schon die engste Option, aber ein Projekt liegt in genau einem Arbeitsbereich. Es kann nicht über Boards hinweggreifen, aber es kann auch nicht „alles in diesem einen geteilten Arbeitsbereich, egal welche Projekte später noch dazukommen“ abdecken. Sobald ein Konto zu mehr als einem Arbeitsbereich gehört, etwa einem persönlichen und je einem geteilten pro Gruppe von Mitwirkenden, erreicht ein ansonsten unbeschränktes Token alle auf einmal, denn Lesen ist keine Aktion, die sich pro Aufruf absichern lässt. Es ist eine Eigenschaft der Reichweite und nicht eines einzelnen Tool-Aufrufs. Deshalb muss sie auf der Ebene der Zugangsdaten durchgesetzt werden.

Wie ein auf einen Arbeitsbereich beschränktes Token durchgesetzt wird

Nach demselben Muster wie die Beschränkung auf ein Projekt: eine Erlaubnisliste, die standardmäßig alles verweigert (WORKSPACE_TOOLS in lib/mcp.ts). Ein Tool muss ausdrücklich darauf gesetzt werden, bevor ein auf einen Arbeitsbereich beschränktes Token es überhaupt aufrufen kann, nie umgekehrt. project_id und workspace_id schließen sich auf demselben Token gegenseitig aus und werden zusammen schon beim Erstellen abgelehnt. Ein auf ein Projekt beschränktes Token ist ohnehin auf den einen Arbeitsbereich dieses Projekts festgelegt, und beides zu kombinieren lädt nur zu einer Konfiguration ein, die sich widersprechen könnte.

Was ein Agent mit einem auf einen Arbeitsbereich beschränkten Token weiterhin tun kann

• Den gesamten Lebenszyklus einer Aufgabe auf diesem Board: list_tasks, list_my_tasks und next_task (der Arbeitsbereichsfilter ist fest auf den des Tokens gesetzt, damit ein Aufrufer ihn nicht ausweiten kann), get_task, update_task, comment_on_task, complete_task, propose_completion, claim_task, decline_task, release_task und die Nachverfolgung von Läufen (start_run, end_run, check_budget).
• create_task, fest auf den Arbeitsbereich des Tokens gesetzt. Das Tool kann also keine Aufgabe in einem Projekt oder unter einer übergeordneten Aufgabe anlegen, die woanders liegt.
• list_projects und list_workspaces, aber gefiltert auf genau dieses eine Board. Die Namen der anderen Arbeitsbereiche des Kontos kommen in der Antwort nie vor.

Was abgelehnt wird, statt halb eingegrenzt zu werden

Alles, was über das ganze Konto hinweg liest und keinen eigenen Arbeitsbereichsfilter hat (get_digest, search_activity, list_tags, list_goals, changes_since, list_triggers), wird für ein auf einen Arbeitsbereich beschränktes Token heute komplett abgelehnt, statt als Teilabfrage ausgeliefert zu werden, die sich stillschweigend über alle Boards erstreckt. Auch ein Tool, das später zu Done hinzukommt, erbt nicht automatisch Zugriff: Es bleibt für solche Tokens abgelehnt, bis jemand entscheidet, wie es eingegrenzt wird. Ein Test im Repository (tests/scoped-tokens.test.ts) stellt sicher, dass die Erlaubnisliste vollständig mit dem übereinstimmt, was tatsächlich durchgesetzt wird. Ein neues Tool ohne Eingrenzung lässt also den Build scheitern, statt unbemerkt Daten preiszugeben. Auch die angekündigte Tool-Liste hält sich daran: Einem auf einen Arbeitsbereich beschränkten Client wird ein Tool, das er nicht aufrufen darf, gar nicht erst angezeigt, statt es ihm zu zeigen und erst beim Aufruf abzulehnen.

Gilt die Beschränkung auch für den Live-Ereignisstrom?

Ja. /api/events akzeptiert ein MCP-Bearer-Token genauso wie /mcp. Eine Beschränkung, die nur Tool-Aufrufe abdeckt, würde auf einen Arbeitsbereich beschränkten Zugangsdaten über den Strom trotzdem die Aufgabenänderungen, Kommentare und Agentenanfragen aller anderen Boards liefern: dasselbe Leck durch eine andere Tür. Die SSE-Verbindung setzt exakt dieselbe Arbeitsbereichsprüfung durch.

So richtest du eines ein

Unter Konto → Weitere MCP-Tokens erscheint die Arbeitsbereichsauswahl erst, wenn das Konto tatsächlich zu mehr als einem Arbeitsbereich gehört. Sonst gibt es nichts einzugrenzen. Wählst du einen Arbeitsbereich, wird eine eventuelle Projektauswahl geleert (beides schließt sich gegenseitig aus). Das Token wird beim Erstellen einmal angezeigt, wie jedes andere Done-Token auch. Kopiere es also, bevor du die Seite verlässt.

Brauche ich dafür einen kostenpflichtigen Tarif?

Nein. So, wie es ausgeliefert ist, gibt es beim Erstellen eines auf einen Arbeitsbereich beschränkten Tokens auf dem ganzen Weg vom Konto-Bereich über die API bis zur Datenschicht keine Tarifprüfung. Es steht heute also in jedem Tarif zur Verfügung. Nützlich ist es außerdem früher, als „einen Arbeitsbereich mit jemandem aus dem Team teilen“ vermuten lässt: Schon der kostenlose Tarif erlaubt bis zu zwei Arbeitsbereiche pro Konto. Auch wer allein arbeitet und zum Beispiel ein persönliches Board und ein separates führt, kann einen Agenten an nur eines davon anschließen, ohne jemanden einzuladen oder den Tarif zu wechseln.

Wie das zu Nur-Lese-Tokens und auf ein Projekt beschränkten Tokens passt

Alle drei Achsen grenzen ein, was Zugangsdaten tun oder erreichen dürfen. Sie ersetzen nicht die Freigabe, die getrennt davon regelt, was ein Agent abschließen kann, ohne dass ein Mensch zustimmt. Nimm die Beschränkung auf einen Arbeitsbereich, wenn du einem Agenten „dieses ganze geteilte Board“ übergeben willst, die Beschränkung auf ein Projekt, wenn es enger sein soll, und „Nur lesen“ zusätzlich zu einem von beiden, wenn der Agent nur zuschauen soll. Mehrere Agenten auf einem geteilten Konto lassen sich leichter überblicken, wenn die Reichweite jedes Tokens in den Zugangsdaten selbst steht und nicht in einer Richtlinie, die niemand mehr nachprüft.