DEV Community

Cover image for Enterprise MCP Governance: Gateway + Layer 2
Ricardo Rodrigues
Ricardo Rodrigues

Posted on

Enterprise MCP Governance: Gateway + Layer 2

#mcp #ai #claude #cursor

One endpoint. Per-member tokens. Full audit trail. How MCPNest solves the team coordination problem for MCP.

When a team of engineers all use Claude with MCP servers, you have a coordination problem.

Each person runs their own npx command. Each person has their own claude_desktop_config.json. When a server URL changes, someone has to update every config. There is no audit trail. No access control. No way to know who called what tool, when, and with what arguments.

This is the current state of enterprise MCP usage in 2026. We built two layers to fix it.

Layer 1: The Gateway

MCPNest Gateway gives every workspace a single endpoint:

https://mcpnest.io/api/gw/{workspace-slug}
Enter fullscreen mode Exit fullscreen mode

Behind that endpoint: all the MCP servers your team has approved. One Bearer token. All tools. Every call proxied and logged.

The Gateway speaks JSON-RPC 2.0 — the MCP standard. Claude, Cursor, and Windsurf connect to it exactly as they would to any MCP server. Your team updates one config file once. When you add or remove a server from your workspace, every connected client sees the change automatically on the next tools/list call.

Technical implementation:

  • Token format: mng_ prefix + 48 hex characters (192 bits of entropy)
  • Storage: SHA-256 hash only — the raw token is never stored in plaintext
  • Verification: timingSafeEqual() to prevent timing side-channel attacks
  • Rate limiting: 200 requests per minute per IP per workspace slug
  • SSE support: streaming responses for MCP servers that use Server-Sent Events
  • Tool prefix: configurable per server to avoid naming conflicts (github_create_issue vs gitlab_create_issue)

Layer 2: Per-Member Access Control

The workspace token is admin-level — full access to all tools. For team members, you create individual Bearer tokens with the same format but different scope.

Each member token can have an allowlist: server_slug : tool_name pairs that define exactly which tools the member can call.

How it works:

  1. Owner creates a member token in the workspace Security tab
  2. Owner defines allowlist rules: github-mcp:list_issues, grafana:get_dashboard
  3. Owner enables enforcement
  4. Member uses their token — Gateway checks allowlist on every tools/call
  5. Blocked calls return error code -32003: Tool not allowed for this user
  6. Every call is logged with user identity to the audit trail

The rule logic:

  • No rules defined: member has full access (open by default)
  • Rules defined + enforcement on: member can only call listed tools
  • Workspace admin token: always full access regardless of allowlist

What this looks like in practice

A DevOps team has three MCP servers in their workspace: GitHub, Grafana, and a custom internal deployment server.

Junior engineers get member tokens with allowlists restricted to read-only operations: github-mcp:list_issues, grafana:get_dashboard. They can query and report but not write.

Senior engineers get tokens with no allowlist restrictions. The deployment server is restricted to the team lead and the CI system.

All of this configured in the workspace UI. No code changes. No config files to distribute to each team member.

The audit log

Every action in a workspace is logged: server added, member invited, tool called, health check run. For tool calls, the log records which user (by member token identity), which server, which tool, and the response latency.

This is the audit trail your security team asks for. It exists out of the box.

Ricardo Rodrigues — Platform Engineer @ BCP, Founder @ MCPNest
Porto, Portugal

MCPNest — The App Store for MCP Servers
mcpnest.io/workspace

Top comments (0)