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 (4)
Ricardo, this post highlights the exact operational blind spot that keeps enterprise CISOs awake at night. The industry treats MCP as a magical, frictionless API layer, completely ignoring that running unverified open-source MCP servers via local
stdiois essentially running arbitrary, un-sandboxed code with the full user privileges of a developer's machine.Moving the ecosystem from local developer laptops to centralized, isolated containers via your Orchestrator isn't just an infrastructure convenience—it’s an absolute security requirement.
Your implementation of Docker-level hardening is a masterclass in least-privilege architecture:
cap_drop ALLstripping the Linux capability surface removes the standard low-hanging fruit for local privilege escalation.no-new-privileges: truecompletely invalidates the threat of malicioussetuidbinaries hidden inside nested open-source dependencies.Decoupling the credentials by injecting them via environment variables strictly to the isolated container context solves the local plain-text JSON hazard.
To push this architectural pattern even further, how do you see teams defending against Indirect Tool-Execution Attacks?
Even inside a pristine, capability-dropped container, if a developer directs an AI agent to read an untrusted public web page or process an unvetted codebase, an attacker can embed malicious prompts that exploit the agent's context window. If the agent is tricked into calling a hosted database or a Slack server tool with valid credentials, the network pathway itself becomes the exploit vector.
Does the MCPNest Gateway plan to implement runtime payload evaluation on tools/call inputs—effectively establishing an application-layer firewall between the LLM's intent and the containerized tool execution—or do you view that semantic filtering as the responsibility of the client application?
Ken, this is the kind of comment that makes writing in public worth it. You're pushing exactly where the hard problems are.
On the indirect tool-execution attack: you've put your finger on the real ceiling of container hardening. cap_drop ALL and no-new-privileges protect the host from the tool, but they do nothing about a poisoned context tricking the agent into calling a legitimate, fully-credentialed tool. The exploit rides the LLM's intent, not the infrastructure — so the sandbox is the wrong layer to stop it.
Honest answer on where we are today: the Gateway does not yet do runtime payload evaluation on tools/call inputs. That semantic boundary currently lives with the client. But I think you're right that the Gateway is the only place it can ultimately live — it's the single chokepoint that sees every member, every tool, and every call across the workspace. The client can't reason about cross-tool or cross-member patterns; the Gateway can. So my view is that an application-layer policy engine between intent and execution belongs at the Gateway, and that's the direction — I just won't claim we ship it today, because real semantic filtering of injected intent is still an open problem industry-wide, and I'd rather be straight about that than hand-wave it.
What we do have today is the deterministic half of that boundary: per-member tool allowlists enforced at the Gateway, so even a hijacked agent can only reach the tools that member was explicitly granted. It narrows the blast radius; it doesn't read intent. The semantic half is the harder, later piece.
On the audit log — your hot/cold split is the right architecture, and you've articulated it better than I had. To be straight about today's state: we run a single queryable tool-call log (workspace, member, tool, status, latency, timestamp, error code — and deliberately no input/output payloads, which keeps it GDPR-clean by construction). The immutable cold tier with Object Lock and Merkle integrity proofs is the direction for the compliance anchor, not something I'm running yet. Your point about the split being non-negotiable for margins over a 7-year retention window is exactly the reasoning that pushes it from "nice idea" to "required architecture" — the hot tier can't carry SOX/HIPAA retention without destroying unit economics, and the cold tier can't serve real-time anomaly detection. Decoupling them is the only way both jobs get done.
Genuinely valuable thinking.
Appreciate the candor here, Ricardo. Being straight about where the deterministic gates end and where semantic runtime evaluation begins is exactly what builds engineering trust. You're entirely right—the sandbox is the wrong layer for intent. An exploit riding fully-credentialed LLM intent requires an application-layer policy engine, and the Gateway is the only chokepoint with enough systemic visibility to execute that job across cross-member patterns.
Enforcing per-member tool allowlists today is already a massive reduction in blast radius.
On the audit side, glad the hot/cold split resonance landed. The unit economics of retention windows are brutal; decoupling real-time anomaly detection from immutable compliance anchors is the only way to scale without breaking the model's margin. Keeping the payload out of the hot tier is an elegant way to maintain GDPR-clean telemetry by construction.
This is world-class infrastructure design. Looking forward to watching the policy engine side evolve.
Enforce at ingestion — that's the answer I suspected but needed someone who'd run into the wall to confirm it. The retrospective reconstruction approach always felt like it was solving the wrong problem: you can reconstruct what happened, but you can't undo a state corruption that happened because the boundary wasn't there at the time.
The Sovereign Systems Specification & Glossary framing interests me — especially 'treating incoming payloads as untrusted telemetry before they hit a tool runtime.' That's exactly the semantic I'm missing language for. The MCPNest audit log today captures the call metadata (who, what, when, outcome) but treats the payload itself as out of scope by design — GDPR-clean, but it means the provenance verification you're describing happens outside the log boundary. Your state-schema approach sounds like it closes that gap from the tool side rather than the gateway side. Are those two layers meant to compose, or does one subsume the other in your model?