How to Secure Your MCP Server Setup — Best Practices

MCP servers give your AI assistant direct access to real systems -- databases, cloud providers, payment processors, version control. That same power makes them a security surface you need to think about.

TL;DR: Use test/development API keys (never production), scope permissions to the minimum needed, prefer stdio transport over HTTP/SSE, never commit secrets to version control, and audit every server's source code before granting it credentials. Use the security checklist at the bottom for every new project.

graph TD
    A[Adding MCP Server] --> B{Official server from<br/>known maintainer?}
    B -->|No| C[Review source code<br/>for data exfiltration]
    B -->|Yes| D{Using test/dev<br/>credentials?}
    C --> D
    D -->|No| E[❌ Switch to test<br/>credentials immediately]
    D -->|Yes| F{Minimal permission<br/>scopes?}
    F -->|No| G[Narrow token scopes<br/>to only what is needed]
    F -->|Yes| H{Config file in<br/>.gitignore?}
    H -->|No| I[Add to .gitignore or<br/>use placeholder values]
    H -->|Yes| J{Using stdio<br/>transport?}
    J -->|No| K[Switch to stdio if<br/>server supports it]
    J -->|Yes| L[✅ Secure setup]

The Security Surface of MCP

When you add an MCP server to your editor, you spawn a process that can do real things. A Supabase MCP server can query and modify your database. A GitHub MCP server can merge pull requests. A Stripe MCP server can create charges.

The security considerations fall into four categories:

1. Credential management -- what tokens you hand to MCP servers and how you store them
2. Permission scoping -- how much access those credentials grant
3. Network exposure -- whether the server is reachable beyond your machine
4. Tool auditing -- knowing exactly what each server can do before enabling it

API Key Management

Use test and development keys, not production

• Stripe: use sk_test_ keys, never sk_live_. Test mode lets you build integrations without touching real money.
• Supabase: create a separate project for development. Use that project's access token.
• GitHub: create a fine-grained personal access token scoped to only the repositories you actively develop on.

{
  "mcpServers": {
    "stripe-mcp": {
      "command": "npx",
      "args": ["-y", "@stripe/mcp", "--tools=all"],
      "env": {
        "STRIPE_SECRET_KEY": "sk_test_your_test_key_here"
      }
    }
  }
}

If your AI assistant accidentally runs a destructive operation with a test key, the blast radius is limited to test data.

Never commit secrets to version control

Common mistakes: committing .mcp.json with real tokens, pasting tokens in a .cursor/mcp.json already tracked by git, forgetting that git history preserves deleted secrets.

Use placeholder values in committed configs, or add the config to .gitignore:

# .gitignore
.mcp.json
.cursor/mcp.json

If you accidentally committed a secret, rotate the key immediately. Removing it from the current commit is not enough.

Rotate keys regularly

• GitHub tokens: rotate every 90 days. Fine-grained tokens can be set to expire automatically.
• Supabase access tokens: rotate when team members leave or roles change.
• Stripe keys: roll test keys periodically.

One key per context

Do not reuse the same API key across MCP config, application .env, and CI/CD pipeline. Create dedicated keys labeled clearly: mcp-development, app-production, ci-testing. This limits damage from any single leak.

Permission Scoping

GitHub: Fine-Grained Personal Access Tokens

Instead of a classic token with blanket repo access:

1. Go to github.com/settings/tokens?type=beta
2. Under "Repository access," select only the repositories you are working on
3. Under "Permissions," grant only what you need:
   • Contents: Read-only -- if you only need the AI to read code
   • Pull requests: Read and write -- if you want it to create PRs
   • Issues: Read and write -- if you want it to manage issues

Avoid granting Administration, Actions, or Workflows permissions unless you have a specific reason.

Supabase: Row-Level Security

Enable RLS on all tables, even in development. If the AI runs an unexpected query, RLS policies limit accessible data. Use a development project separate from production.

Stripe: Test Mode Only

• sk_test_... -- safe, creates fake charges
• sk_live_... -- real money, real customer data

There is no legitimate reason to use a live Stripe key with an MCP server during development.

The Filesystem MCP Allowlist Model

The Filesystem MCP server demonstrates a best practice: explicit allowlisting.

{
  "mcpServers": {
    "filesystem-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/Users/me/projects/my-app/src",
        "/Users/me/projects/my-app/docs"
      ]
    }
  }
}

Each path is an allowed directory. The server refuses access outside these directories. Apply this thinking to other servers: scope GitHub tokens to specific repositories, database access to specific schemas, cloud provider tokens to specific services.

Network Exposure: Stdio vs HTTP/SSE

Stdio: Local Only (Preferred)

Most MCP servers use stdio transport. The server runs as a child process with no network listener, no open port, no external access. This is the secure default. Prefer stdio whenever possible.

HTTP/SSE: Network Accessible

Remote MCP servers communicate over HTTP. Security considerations:

• Only connect to URLs you trust
• Use HTTPS exclusively -- never plain HTTP
• Everything sent through a remote MCP server passes through third-party infrastructure
• For sensitive code or data, stick to local stdio servers

For more on transport-related issues, see our troubleshooting guide.

Auditing What MCP Servers Can Do

Before adding a new server, understand its capabilities.

Check the source code

Reputable MCP servers are open source. Before granting credentials:

1. Visit the repository (Supabase MCP, GitHub MCP, Playwright MCP)
2. Look at tool definitions to see what each tool does
3. Check for data exfiltration -- does the server send data to third-party endpoints?
4. Review issues and PRs for security concerns

Prefer official servers

Servers maintained by the service provider are more trustworthy. They have security teams reviewing code and a direct interest in not compromising customers. See our guide to choosing quality MCP servers for evaluation criteria.

Permission Models Across Clients

Claude Code prompts before each new tool invocation. You can allow, deny, or allow permanently for the session.

Cursor generally auto-allows MCP tool calls without prompting. If you use Cursor, be extra careful about token scopes.

VS Code (Copilot) lets you configure tool approval policies per tool.

The takeaway: if your client auto-allows tool calls, your only defense is the scope of the credentials you provide.

What NOT to Do

• Do not use production database credentials. If the AI runs DROP TABLE users on production, there is no undo.
• Do not use admin tokens. Create tokens with the minimum role needed.
• Do not use live Stripe keys. sk_test_ only.
• Do not run untrusted MCP servers. A malicious server could read files, exfiltrate env vars, or execute arbitrary commands. Only run servers from sources you trust -- check the evaluation criteria.
• Do not share configs with embedded secrets. Share with placeholder values only.

Security Checklist

Use this for every new project:

• All API keys are test/development tier, not production
• No real secrets are committed to version control
• .mcp.json is in .gitignore or uses placeholder values
• GitHub tokens use fine-grained access scoped to specific repositories
• Database credentials point to a development database
• Stripe keys use the sk_test_ prefix
• Filesystem MCP (if used) is scoped to specific directories
• All servers use stdio transport unless remote is specifically required
• Each server's source repository has been reviewed
• Server packages are from official or well-known maintainers
• API keys are not reused across MCP config and production environments
• A rotation schedule is set for long-lived tokens

For permission and security details on specific servers, browse the server catalog on stackmcp.dev. If you run into configuration issues while securing your setup, check our connection error troubleshooting guide.

Build fast, but build safely.