MCP for Enterprise Teams: Security, Governance, and Scale

Why enterprises are adopting MCP

MCP (Model Context Protocol) went from an Anthropic experiment to an industry standard in 14 months. Microsoft, Google, Amazon, and OpenAI all support it. The Linux Foundation now governs it. With 97 million monthly SDK downloads and 10,000+ published servers, MCP is no longer optional for engineering organizations that use AI coding assistants.

For individual developers, setting up MCP is straightforward. For enterprise teams with 50, 500, or 5,000 engineers, the questions are different: What are the security implications? How do we control what servers are allowed? How do we roll out configurations across teams? What happens when a server has a vulnerability?

This guide covers the practical answers.

Understanding the MCP permissions model

Every MCP server declares the permissions it needs. These fall into three categories:

When evaluating servers for enterprise use, the permission profile is the first thing to check. Here is how the most commonly used enterprise servers compare:

Servers with shell: true (Docker MCP, Kubernetes MCP) deserve extra scrutiny. They can execute arbitrary commands on the developer's machine. This is powerful for DevOps work but requires trust in both the server code and the AI model's judgment about when to invoke those tools.

Servers that only use network: true without filesystem or shell access are lower risk. They communicate with external APIs using credentials you provide, but cannot touch local files or run commands.

How to audit an MCP server before approval

Before adding any MCP server to your organization's approved list, run through this checklist:

1. Source verification

• Is it official? Servers maintained by the service vendor (Sentry, Datadog, Supabase, GitHub) are generally safer than community servers. Check the official field in the StackMCP catalog.
• Repository activity. Check the GitHub repo for recent commits, open issues, and contributor count. A server last updated six months ago may have unpatched vulnerabilities.
• Dependency audit. Run npm audit or equivalent on the server's dependencies. MCP servers are npm/pip packages like any other; they inherit their dependency tree's vulnerabilities.

2. Permission scope review

• Does the server request more permissions than its functionality requires? A documentation server that needs shell: true is a red flag.
• Are API credentials scoped correctly? For example, the GitHub token you provide should use fine-grained permissions, not a classic token with full repo access.

3. Transport security

MCP supports two transports:

• stdio -- The server runs as a local process on the developer's machine. Communication happens through standard input/output. No network exposure.
• HTTP/SSE -- The server runs remotely. Communication happens over HTTP. This requires TLS and authentication.

For enterprise use, stdio is simpler to secure because the server only runs locally. HTTP/SSE transport is necessary for shared team servers but requires proper network security.

4. Data flow analysis

Map what data flows where:

• What does the server send to external APIs? A GitHub MCP server sends your code diffs to GitHub's API. Is that acceptable under your data classification policy?
• Does the server log or cache data? Check the server's source code for any local caching of API responses.
• Are credentials stored securely? MCP server credentials are typically environment variables. Ensure they are not committed to version control.

Team-wide configuration strategies

Approach 1: Shared config file in the repository

The simplest approach. Add an MCP config file to each repository:

For Cursor projects, add .cursor/mcp.json. For VS Code, add MCP settings to .vscode/settings.json. For Claude Code, add .claude.json to the project root.

Pros: Version-controlled, reviewed in PRs, consistent across the team. Cons: Credentials must be handled separately (environment variables, not hardcoded in the config).

Approach 2: Organization-level approved server list

Maintain a central list of approved MCP servers with approved versions. Distribute it through your internal developer portal or tooling documentation. Engineers can only use servers from the approved list.

This pairs well with the StackMCP config generator, which lets you select specific servers and export configs for any editor. A platform team can generate approved configs and distribute them.

Approach 3: Tiered rollout

Start with a small set of low-risk servers and expand:

Tier 1 -- Low risk, high value (week 1):

Tier 2 -- Medium risk, specialized (week 4):

Add Semgrep MCP (3,500 tokens) for security scanning and Sentry MCP (4,120 tokens) for error tracking.

Tier 3 -- Higher risk, infrastructure (week 8):

Add Docker MCP (7,210 tokens) and Kubernetes MCP (6,180 tokens) for teams that need infrastructure management. These require shell: true and should be limited to DevOps and platform teams.

Compliance considerations

SOC 2 and ISO 27001

MCP servers that access production data (databases, monitoring systems, error trackers) fall under your existing data access controls. Document:

• Which servers have access to what systems
• Who approves new server additions
• How credentials are rotated
• What data leaves your network boundary

GDPR and data residency

If an MCP server sends data to an external API, that data may cross geographic boundaries. For example, Datadog MCP sends queries to Datadog's API. If your Datadog instance is in the EU region, the data stays in the EU. But the MCP server itself runs locally on the developer's machine and makes the API call from there.

Review each server's data flow against your data residency requirements.

Credential management

MCP servers authenticate to external services through API keys, tokens, or connection strings passed as environment variables. Enterprise best practices:

• Use a secrets manager (Vault, AWS Secrets Manager, 1Password CLI) to inject credentials
• Rotate credentials on a schedule
• Use the least-privilege principle: GitHub tokens should have only the scopes the MCP server needs
• Never commit credentials to the MCP config file

Recommended enterprise stacks

For security-focused teams

The Cybersecurity stack combines five security servers:

At 20,000 tokens total, this is a lean stack that gives security engineers direct access to their core tools without burning excessive context.

For platform engineering teams

This is a heavier stack. If the token budget is tight, swap Grafana for Datadog MCP (7,725 tokens) to save 14,420 tokens. See How to cut MCP token costs in half for more optimization strategies.

For product engineering teams

This stack covers the daily workflow of a product engineer: manage issues in Jira, write code with up-to-date docs, create PRs in GitHub, and debug production errors through Sentry.

Governance checklist

Before rolling out MCP to your engineering organization:

1. Create an approved server list. Audit each server using the process above. Publish it internally.
2. Define permission tiers. Not every team needs shell: true servers. Scope access by role.
3. Standardize credential management. Use environment variables backed by a secrets manager. No hardcoded tokens.
4. Set token budgets. Recommend 15,000-30,000 tokens per stack. Teams that exceed this will experience degraded AI performance. See Why too many MCP servers hurt productivity.
5. Establish a review process. New server requests go through security review before being added to the approved list.
6. Monitor and iterate. Track which servers teams actually use. Remove unused servers from configs to save tokens.

Next steps

• Browse all MCP servers with quality scores, token estimates, and permission details
• Use the config generator to create team-wide configs for any editor
• How to secure your MCP server setup for deeper security guidance
• What is MCP? if your team needs an introduction to the protocol