Is API key auth enough?

It is a start, but production should also use scopes, rotation, logging, and approval policies.

Can MCP leak secrets?

Yes if tools return secrets or logs store raw headers. Redact aggressively.

Should tools run in sandboxes?

Use sandboxing for file, shell, browser, or network-capable tools.

Does the MCP protocol enforce authentication?

No. MCP does not mandate a specific auth mechanism. Any server exposed over HTTP/SSE must add authentication and transport encryption itself.

How do I rotate API keys without downtime?

Accept both the old and new key for a transition window, move clients to the new key, then revoke the old one once nothing is using it.

complianceHowTo

MCP Security Best Practices

Secure MCP servers with auth, least privilege, tool approval, sandboxing, rate limits, and safe logging.

Quick Answer / TL;DR

Secure MCP by denying risky tools by default, validating schemas, isolating secrets, rate-limiting calls, logging safely, and requiring human approval for destructive actions. The protocol itself does not enforce authentication or authorization; that responsibility sits with whoever implements the server.

Key Takeaways

Least privilege first.
Never trust tool arguments.
Mask secrets in logs.
Pick an auth method that matches deployment risk: API keys for internal tools, OAuth for multi-tenant apps, mTLS for zero-trust networks.

Baseline policy

Security starts with a clear boundary. Every server should know which resources it may read, which actions it may perform, and which users or clients may invoke it.

json

{
  "auth": "required",
  "rateLimit": "60/minute",
  "sandbox": true,
  "denyTools": ["shell.exec", "payments.refund"],
  "requireApproval": ["write", "delete", "send_money"]
}

Choosing an authentication method

API keys are the simplest option and fit internal tools or single-tenant deployments: store the key in an environment variable, rotate it periodically, and reject any request whose header does not match.

OAuth 2.0 suits multi-tenant SaaS and user-facing integrations, since it verifies a bearer token against an identity provider on every request. mTLS gives the strongest guarantee for zero-trust or regulated environments (finance, healthcare, government) because both client and server present certificates, removing passwords and tokens from the equation entirely.

Method	Best fit	Key requirement
API key	Internal tools, dev/staging	Rotate on a schedule, never hardcode
OAuth 2.0	Multi-tenant SaaS, user-facing apps	Verify bearer token per request
mTLS	Zero-trust, regulated industries	Client and server certificates

Authorization with RBAC

Authentication answers who is connecting; authorization answers what they may do. Attach a role to each verified caller and check it before executing a tool, rather than trusting that authentication alone is sufficient.

typescript

const ROLE_PERMISSIONS: Record<string, string[]> = {
  admin: ["tools/call", "resources/read", "resources/write"],
  developer: ["tools/call", "resources/read"],
  readonly: ["resources/read"],
};

function authorize(role: string, method: string) {
  if (!ROLE_PERMISSIONS[role]?.includes(method)) {
    throw new Error(`Unauthorized: ${role} cannot execute ${method}`);
  }
}