MCP Governance: Who in a Team May Connect What

MCP security and governance, for a team, comes down to four decisions written down and one setting that enforces them. Keep an approved servers list that identifies each server by its URL or exact command, with an owner and a purpose. Decide who may add a server at each level: to their own machine, to a shared repository, to everyone. Decide which scopes each connection gets, starting small. Review the list on a fixed cadence and whenever something changes. Then turn the list into client settings, such as Claude Code’s allowedMcpServers or VS Code’s MCP access policy, so the approved list is what actually runs rather than what people remember to follow.

This is narrower than a general AI policy. The wider rules, which agents, which data, who owns each one, are in AI agent governance for small teams; the practices every MCP connection should follow are in MCP security best practices. This piece is the MCP-specific part: which servers, added by whom, enforced how.

Why MCP needs its own rules

By default, anyone running an MCP client can connect any server they choose. A server is either code that runs on someone’s machine with their permissions, or a remote service that receives whatever the assistant sends it. Anthropic’s documentation on controlling MCP server access↗ (opens in a new tab) is plain about the directory it maintains: it reviews connectors against listing criteria but does not security-audit or manage any MCP server. Choosing is your job.

Decision one: the approved servers list

One short list, kept where the team keeps its work. Each entry needs enough to enforce it and enough to review it:

Server        Identified by                               Owner   Purpose              Scopes            Reviewed
fenbs         https://fenbs.ai/api/mcp                    Priya   Task board           read, comment     2026-09
GitHub        https://api.githubcopilot.com/mcp/          Tom     Issues and PRs       repo read         2026-09
docs-search   npx -y @your-org/docs-mcp@2.3.1                 Priya   Internal docs        n/a (local)       2026-08
Not approved: anything that reaches production databases, payments or customer email.

Identify servers by what they are, not what they are called. A name is the label a person typed when adding the server, and anyone can call anything “github”. Claude Code’s own documentation warns that a name entry in its allow and deny lists is not a security control, and recommends matching remote servers by URL and local ones by their exact command. For local servers, pin the version in the command, so an approval covers the code you reviewed rather than whatever is published next.

Decision two: who may add a server

Most clients have three places a server can be configured, and each needs its own rule.

• Personal: a server in one person’s own configuration, for their own work. Allow any server on the approved list; anything else is a request to add it to the list.
• Project: a server in a file committed to the repository, such as .mcp.json for Claude Code or .vscode/mcp.json for VS Code. Anyone may propose one; it goes in through normal code review, and the reviewer checks it against the list.
• Organisation: a server deployed to everyone by an administrator. Only the list’s owner adds these, and only from the list.

Write down the route for adding a server, and keep it fast: say what it is, what it will reach and who will own it, and get an answer within a week. A process slower than setting the server up anyway produces shadow AI agents.

Decision three: scopes per connection

Approving a server is not the same as approving everything it can do. The MCP security best practices↗ (opens in a new tab) recommend a progressive, least-privilege model: start with a minimal set of low-risk read operations and elevate only when a privileged operation is first needed. They list the common mistakes as wildcard or omnibus scopes and bundling unrelated privileges to avoid future prompts. As policy, that means: each person connects with their own sign-in, never a shared key; new connections start read-only; and the list records the widest scope each server is approved for.

Enforcing it in the clients

A list people follow by memory drifts. Most teams use a handful of clients, and the main ones can enforce a list centrally.

Claude Code

Claude Code’s managed settings support several patterns. A managed-mcp.json file deployed to a system path gives an organisation exclusive control: users get exactly those servers and cannot add others. For an approved catalogue, set allowedMcpServers together with allowManagedMcpServersOnly: true in managed settings; without that second key, users’ own allowlists merge in and can broaden it. deniedMcpServers blocks servers everywhere, and a denylist match always wins.

{
  "allowManagedMcpServersOnly": true,
  "allowedMcpServers": [
    { "serverUrl": "https://fenbs.ai/api/mcp" },
    { "serverUrl": "https://api.githubcopilot.com/*" },
    { "serverCommand": ["npx", "-y", "@your-org/docs-mcp@2.3.1"] }
  ]
}

Commands match exactly, argument for argument, so an entry for one version does not admit another. One practical note from the same documentation: a server blocked by policy simply disappears from a user’s list without saying why, so tell people which servers are blocked when you roll out a change.

VS Code and Copilot

VS Code’s enterprise AI settings↗ (opens in a new tab) include an MCP access policy with three values: any source, the configured registry only, or MCP switched off. Allowed and denied server lists match by configured name, remote URL or local command, and denials take precedence.

On the GitHub side, the MCP servers in Copilot policy decides whether Copilot can use MCP at all, and administrators can set an MCP registry↗ (opens in a new tab) and choose between allowing all servers and allowing only servers from that registry. The settings for VS Code in particular are covered in VS Code MCP security.

Clients with no central control

Some clients have no administrator settings. For those, the project file under code review and a monthly check of what each person has configured are the enforcement. If several such clients matter and a central door is needed, that is the case for an MCP gateway.

Registries are a source, not an approval

The official MCP Registry↗ (opens in a new tab), currently in preview, is a metadata catalogue of publicly accessible servers. It verifies namespaces, so a server named under a GitHub account or domain was published by its owner, but it delegates security scanning to package registries and downstream aggregators, and it does not hold private servers; for those it suggests running your own registry. Use a registry to find servers and to feed a “registry only” policy. Do not treat appearing in one as approval: the list is still yours to decide.

The review cadence

• When a server is added: check the publisher, read its tool descriptions, note the scopes, record the owner.
• When a local server’s version changes: re-read the tool list before moving the pinned version.
• Monthly: compare what the clients and servers report as connected with the list, as part of auditing your AI agents.
• Quarterly: remove servers nobody used, and confirm each owner still owns theirs.
• When someone leaves: revoke their connections the same day.

The server’s side of the policy

Client settings decide which servers can be reached. What a connection can do once it arrives is up to the server, so the approved list should favour servers that enforce limits themselves. fenbs, which is a task board and an MCP server, is one example. A connection is approved by a person in the browser, on a page that shows the name the client gave itself marked as unverified. Scopes are read, write and comment, and a token is also capped by that person’s role on the board, which is defined per company; the narrower wins, checked on every call. Each connection works on the one board chosen at approval. Sign-ins get hour-long access tokens renewed with a refresh token; tokens issued by hand under Settings have a name, scopes and an optional expiry; revoking ends either. Every change is recorded in History as “Claude via” the person it acted for.