The MCP ecosystem is growing fast. Thousands of servers, dozens of clients, and teams across the industry moving from personal experimentation to production deployments. But there is a security architecture problem baked into how most teams are using MCP today — and most of them do not know it yet.
The Problem: One Token, Everyone
When you set up an MCP workspace for your team, you generate one Bearer token. That token goes into every team member's AI client configuration. Claude Desktop, Cursor, Windsurf — they all use the same token to authenticate against your MCP servers.
This means every team member has identical access to every MCP tool in your workspace.
Your junior developer has the same permissions as your principal engineer. Your intern can call the deployment tools. Your contractor can query the production database. There is no way to say "Alice can use the database tools but not the CI/CD tools" — not without managing separate workspaces per person, which defeats the purpose of a shared workspace entirely.
This is not a preference problem. It is a security architecture problem. And it gets worse.
The Revocation Problem
Imagine someone leaves the team. To revoke their access, you rotate the workspace token. Now you have to update the configuration of every AI client on the team. Every developer. Every machine. Every client app. Simultaneously.
In a team of ten people, this is painful. In a team of fifty, it is a production incident.
What Proper Access Control Looks Like
Enterprise security operates on the principle of least privilege. Every actor gets access to exactly what they need to do their job — and nothing else. When someone leaves, you revoke their access specifically, without affecting anyone else.
For MCP, this means per-member tokens and per-member tool allowlists.
How MCPNest Gateway Layer 2 Works
We built Gateway Layer 2 to solve this at the infrastructure level, not the application level.
Per-member Bearer tokens. Every workspace member gets their own token. The workspace token still exists for system-level access, but individual members authenticate with their own credentials. The audit trail captures member_id on every call — you know exactly who called what tool and when.
Tool allowlists per member. Admins define exactly which tools each member is permitted to call. Alice gets the database tools. Bob gets the search and retrieval tools. The deployment tools are restricted to the engineers who should have them. These allowlists are configured in the Security tab of the workspace UI — no code required.
Enforcement toggle. The workspace owner enables or disables allowlist enforcement with a single toggle. You define the allowlists first, verify they are correct, and then enable enforcement when ready.
Instant revocation. When someone leaves the team, you delete their token. Their access is gone in seconds. Nobody else is affected. No workspace token rotation. No client reconfiguration across the team.
The Audit Trail
Every tools/call through the MCPNest Gateway is logged with:
| Field | Description |
|---|---|
workspace_id |
Which workspace |
member_id |
Which team member |
tool_name |
Which tool was called |
latency_ms |
How long the call took |
status |
Success or failure |
This is not workspace-level logging. This is tool-level forensics. When something goes wrong — and in production, something always goes wrong — you know exactly what happened, who triggered it, and when.
Why This Matters Now
The MCP ecosystem is at the same inflection point that OAuth was at in 2010. Teams are moving from "I set this up on my laptop" to "we are running this in production for the whole engineering org." The security model needs to evolve at the same pace.
Right now, most teams are one credential leak away from full workspace exposure. One misconfigured client. One developer who stored their token in a public dotfile. One contractor whose access should have been revoked three months ago.
Per-member access control is not a nice-to-have for enterprise MCP deployments. It is the minimum viable security posture for any team taking this seriously.
MCPNest is the governance layer for MCP servers — Gateway, Layer 2 access control, hosted MCP infrastructure, and a marketplace of 7,554+ servers.
Ricardo Rodrigues is the founder of MCPNest and a Platform Engineer at a large financial institution in Portugal.
Top comments (0)