Decide who can use each MCP server from its own Access page, and manage killswitches beside the person they restrict
Access control now starts from the thing you are protecting. Every MCP server has an Access page that answers "who can use this server": grant people or roles, set what each one can do, and narrow a rule to particular tools or to tools carrying an annotation. The organization-wide role editor is rebuilt on the same model. Killswitches move onto the Access tab of the person they restrict, so listing, creating, lifting, and the full version history all happen on that person's page. API keys can be bound to a single project at creation, and RBAC-filtered tool inventories are now marked private so a shared cache can never serve one person's tool list to another.Features
- Per-server Access page and rebuilt role editor #6156 - The read-only Team Access tab on each MCP server becomes an Access page where you grant a person or a role access to that server alone. Each rule reads as a sentence, and narrowing to specific tools or to an annotation such as read-only is a dropdown away. Direct rules are editable in place, inherited organization rules link back to the role that owns them, and a "People this reaches" panel resolves every rule to the members it covers. Role authoring moves onto its own page where permissions are picked from one searchable menu and narrowed on their own row. A guardrail refuses to write a block that would lock the caller out. (Author: @adaam2)
- Killswitches managed from the identity's Access tab #6210 - The separate organization-wide Killswitch screen is retired. Team, connection, and session entry points now open the restricted person's Access tab, where you list, create, edit, and lift killswitches and read their version history. The mark beside a person's name is an icon whose hover text says what the state stops. Old Killswitch addresses redirect, with a single record opening on its subject's Access tab so audit-log links still land on the exact record, in the project and time period the link was read from. (Author: @danielkov)
- API keys bound to one project #6116 - The API key form gains an optional project selector. Omitting it still creates an organization-wide key, and a bound key's project shows separately from its permission scopes in the result and the key list, so a restriction is never confused with a scope. A follow-up restores hosted MCP project context for organization-wide keys executing platform tools while rejecting conflicting bindings (#6115). (Author: @danielkov)
- Filtered tool inventories are never cached across people #5955 - Remote MCP proxy
tools/listresults that pass through the per-tool RBAC filter are labelledcacheScope: "private"withttlMs: 0. The MCP 2026-07-28 revision reads an absent scope as public, which would have let a shared cache serve one principal's tool inventory to another, or let a client keep an inventory after the grants that shaped it were revoked. The label applies whether or not anything was filtered, so it never reveals that a caller was. (Author: @bflad)
