MCP Access Control & RBAC: Who Can Run Which Tools
Short answer: Access control for MCP answers three questions per request — which client is calling, which server it may reach, and which tools on that server it may run. On MCP Trail you enforce all three at the gateway: each server gets its own revocable Bearer token (mg_live_…), each token reaches only the server it was issued for, and per-tool policies (allow, log, approve, deny) decide what that token can actually execute. Give teammates their own tokens instead of sharing one key, and revoke or rotate to cut access instantly. This post is about authorization — the who-can-do-what — not logging; for the record side, see MCP audit logging.
The gap most deployments have is not authentication. It is authorization. Proving who connected is table stakes; deciding which server and which tool that identity may touch is where MCP setups leak. This guide is about closing that gap.
Authentication tells you who. Authorization decides what.
A raw MCP endpoint usually has one property: if you have the URL, you can call every tool it exposes. There is no notion of “this client may list tools but not delete,” or “this token reaches the GitHub server but not the database server.” Everyone who holds the link holds full privilege.
Real access control splits that into layers:
- Identity — which credential is presenting itself (a per-server Bearer token, or an OAuth-delegated user).
- Reachability — which server that credential is allowed to talk to at all.
- Privilege — which tools on that server the credential may run, and under what condition (straight through, logged, held for approval, or denied).
MCP Trail’s Guardian gateway sits in front of your servers and enforces each layer on the wire, so authorization is decided before a tools/call ever reaches your backend. That boundary is the same one described in MCP firewall and gateway explained — here we focus on the access model it makes possible.
Per-server Bearer tokens: one credential, one server
The unit of access on MCP Trail is the per-server token. When you register a server behind the gateway, it gets its own secret in the form mg_live_…. Clients present it as Authorization: Bearer mg_live_… on every request, exactly as covered in connecting an MCP client to a server.
The important property is scope: a token reaches only the server it was issued for. A key minted for your GitHub server cannot list or call tools on your database server. This is least privilege by construction — there is no single master key that unlocks everything, so a leaked credential exposes one server’s blast radius, not your whole fleet.
Because tokens are per-server, they are also independently revocable and rotatable. Retire one without touching any other. Old keys stop working on the next request — no redeploy of the server itself.
Tool allowlists: deny-by-default authorization
A token that reaches a server still should not be able to run every tool on it. That second layer is the tool policy. Each tool gets a decision:
- Allow — runs straight through.
- Log — runs, but the call is recorded for review.
- Approve — pauses until a human approves or denies (see human-in-the-loop approvals).
- Deny — blocked with a clear outcome; the tool never executes.
Treat the allowlist as deny-by-default: name the tools a client legitimately needs, and unknown or unnamed tools return a blocked outcome instead of silently running. That turns “this client can reach the server” into “this client can run exactly these three tools, and anything destructive waits for a person.” The mechanics of writing those rules live in MCP tool allowlists and policies.
Org and workspace scoping: teams without shared keys
Access control is a team problem, not a single-user one. MCP Trail scopes servers to an organization / workspace with an owner and members. The owner controls which servers exist and who belongs to the workspace; members work against those servers within the privileges they are granted.
The lever that makes team access safe is per-member tokens. Instead of everyone pasting the same mg_live_… key into their client, each teammate gets their own credential for a server. Same reachability, separate identity — which means you can revoke one person’s access without disrupting anyone else, and every call is attributable to a specific credential rather than an anonymous shared secret.
The access model at a glance
| Credential / role | What it can reach | How to revoke or scope down |
|---|---|---|
| Owner (workspace) | Every server in the org; manages members and tokens | Transfer ownership; remove the account |
| Member (workspace) | Only servers they hold a token for, at the privileges granted | Remove from workspace; revoke their tokens |
Per-server Bearer token (mg_live_…) | Exactly one server; tools gated by that server’s policy | Rotate or revoke the token in the dashboard |
| Per-member token | The scoped server, attributable to that person | Revoke that one token; others keep working |
| OAuth-delegated user | Server access on the user’s behalf via their IdP | Revoke the OAuth grant / disconnect the integration |
| Tool policy (allow/log/approve/deny) | Which tools a reaching credential may actually run | Change the tool’s decision to deny |
For user-delegated flows where the credential belongs to a person rather than a server, adding OAuth to an MCP server covers the pattern that plugs into this same authorization layer.
Revocation and rotation: the real access-control levers
Access control is only as good as your ability to remove access. Two operations do almost all the work:
- Rotation — replace a token’s secret on a schedule or after any suspicion of exposure. The server keeps running; only the credential changes. Document a rotation cadence so it is routine, not a fire drill.
- Revocation — kill a credential outright when a key leaks, a contractor rolls off, or a client is decommissioned. On the next request, that credential is dead.
Because both act on per-server, per-member tokens, they are surgical. Revoking a departing teammate’s database-server token does not knock the rest of the team off GitHub, and it does not require rebuilding anything. That granularity is the whole point of not sharing one key.
Pair revocation with tool policy for defense in depth: even a valid, un-revoked token is still bounded by the allowlist, so a compromised credential can only run the tools you explicitly permitted — and anything you marked approve still waits for a human.
Putting it together
A well-governed MCP deployment layers these controls so no single failure is catastrophic:
- Register each server behind the gateway; it gets a
mg_live_…token and a private upstream. - Issue per-member tokens so team access is attributable and independently revocable.
- Set a deny-by-default tool allowlist per server; mark destructive tools approve.
- Rotate on a cadence, revoke on any signal. These are your fastest reactions to a leak.
Authentication gets someone through the door. This model decides which rooms they enter and which switches they may flip once inside.
FAQ
Does MCP support RBAC?
Not natively — a bare MCP endpoint grants full tool access to anyone with the URL. You get role- and least-privilege access by putting a gateway in front: MCP Trail’s Guardian enforces per-server tokens, org/member scoping, and per-tool allow/log/approve/deny policies, which together deliver the authorization RBAC is meant to provide.
How do I give a teammate access without sharing my key?
Issue them their own per-member token for the specific server they need, rather than handing over your mg_live_… key. They get the same reachability but a separate, attributable credential — so you can revoke just their access later without disrupting anyone else, and every call is traceable to a person rather than a shared secret.
How do I revoke access?
Revoke or rotate the token in the dashboard. Because tokens are scoped per server (and per member), the change is surgical: the affected credential stops working on the very next request, while every other token keeps running. No server redeploy, no downtime for the rest of the team.
Isn’t a tool allowlist enough on its own?
It is one layer, not the whole model. The allowlist decides which tools a credential may run, but you still need per-server tokens to decide which server it can reach and org/member scoping to decide who holds the credential. Deny-by-default allowlists are strongest when combined with scoped, revocable tokens — see MCP tool allowlists and policies.
Explore features · Use cases · Open MCP Trail
Related articles
- MCP tool allowlists and policies — Writing the allow/log/approve/deny rules
- MCP audit logging — The record side of who did what
- MCP firewall and gateway explained — The enforcement boundary this model runs on
- How to connect an MCP client to your server — Presenting the Bearer token from a client
- MCP approvals and human-in-the-loop — When a tool call waits for a person