Back to Resources
Auth
Secrets
Audit

MCP Security

Auth, Secrets & Least-Privilege

Security Guide•
9 min read
•
January 20, 2025

Securing MCP Servers: Auth, Secrets & Least-Privilege

All Tools Directory Team
MCPSecurityBest PracticesAuthentication

MCP unlocks powerful tool access for AI agents—but that power cuts both ways. Exposed endpoints, over-broad permissions, and leaky secrets can turn a helpful server into a high-impact risk. This guide gives you a pragmatic blueprint: a fast threat model, clear authentication options, battle-tested secrets practices, safe sandboxing defaults, and an audit strategy—ending with a copy-paste checklist you can run through on every deployment.

Why MCP Security Matters (Quick Threat Model)

Before picking tooling, define what you're defending against:

Impersonation

An attacker calls your MCP server as a trusted client.

Privilege Escalation

A valid client uses over-broad scopes to reach sensitive tools or data.

Secrets Exposure

Tokens, API keys, or credentials leak via logs, prompts, or crash reports.

Environment Escape

Tools access local filesystem, shell, or network beyond intent.

Security Objective

Adopt least privilege (grant the minimum capabilities needed for the task, for the minimum time), make risky actions explicit and observable, and assume tokens and prompts can leak.

Authentication Options for MCP Servers

API Keys vs OAuth vs mTLS

Static API Keys

Pros
  • • Simple, ubiquitous
  • • Easy for service accounts
Cons
  • • Hard to rotate safely
  • • Coarse-grained
  • • Often shared

Use short TTL and scope to specific routes if possible.

OAuth 2.0 / OIDC

Pros
  • • User and service flows
  • • Refresh tokens
  • • Fine-grained scopes
  • • Integrates with SSO
Cons
  • • More moving parts
  • • Needs token verification cache
  • • Clock skew handling

Mutual TLS (mTLS)

Pros
  • • Strong client identity
  • • Great for service-to-service
Cons
  • • Cert lifecycle overhead
  • • Less ideal for end-users

Pragmatic Pattern

  • For human users → OIDC with SSO, short-lived access tokens (5–15 min) + refresh, narrow scopes.
  • For service accounts → mTLS or client-credentials OAuth with rotating secrets in a vault.
  • For experimentation → scoped API keys in dev only; never reuse keys across environments.

Designing Scopes and Session Lifetimes

  • Scopes map to capabilities, not endpoints: e.g., tools:read, tools:exec:filesystem, secrets:read:kv/myapp/*.
  • Prefer deny-by-default; explicitly allow each tool or dataset.
  • Use time-boxed tokens: short access tokens; refresh token rotation; immediate revocation on risk.
  • Tag tokens with audience (your MCP server) and purpose (agent, user, CI).
  • Implement step-up auth for sensitive actions (e.g., signing, bulk export).

Secrets Management (Generation, Storage, Rotation)

Critical Rules

  • Never hardcode secrets in code, prompts, or environment files shipped to clients.
  • Generate machine secrets with high entropy and least scope; human tokens with PKCE flows.
  • Store in dedicated secrets managers (Vault, AWS/GCP/Azure KMS + Secrets Manager).
  • Encrypt in transit and at rest; prefer envelope encryption with KMS keys.
  • Rotate keys on a schedule (e.g., 90 days) and on events (role change, suspected leak).
  • Use one secret per integration per environment; no shared org-wide tokens.
  • Scrub secrets in logs, traces, and error messages; add secret-detectors in CI and ingestion.
  • Provide ephemeral, task-scoped credentials to tools (e.g., short-lived cloud creds via STS).

Sandboxing & Permissioning for Tools

Filesystem, Network, and Process Controls

Filesystem

  • • Read-only by default
  • • Mount only required paths
  • • Block home directories
  • • Use per-task temp dirs

Network

  • • Default egress deny
  • • Allow-list specific hosts/ports
  • • Rate limit and set DNS policies

Process

  • • Restrict syscalls (seccomp)
  • • Drop Linux capabilities
  • • User-namespaces
  • • No root

Resource Limits

  • • CPU/memory quotas
  • • Timeouts
  • • Output size caps
  • • Mitigate DoS attacks

Auditing, Logging & Monitoring

Audit Requirements

  • Emit structured logs for: auth events, tool execution (who, what, input hashes, output size), secret accesses, policy denials.
  • Privacy-aware logging: hash or redact sensitive inputs/outputs; maintain linkage via request IDs.
  • Ship to a central SIEM; define detectable signals: unusual scope use, high-risk tool bursts, failed mTLS handshakes, token geography changes.
  • Tamper resistance: append-only storage or write-once buckets; clock sync (NTP).
  • Review cadence: weekly triage of anomalies; monthly access reviews; per-release policy diffs.

Practical MCP Security Checklist (Copy/Paste)

Identity & Auth

Choose auth: OIDC for users, mTLS or OAuth client-credentials for services.
Short-lived access tokens (≤15 min); rotate refresh tokens; audience restricted.
Scopes align to capabilities; deny-by-default; step-up for sensitive actions.

Secrets

All secrets in a vault/KMS; never in source or prompts.
Automatic rotation (≤90 days) and on incident.
Logs, traces, and crashes scrubbed for secrets.
Ephemeral, task-scoped credentials for tools.

Sandboxing & Permissions

Container/VM isolation with seccomp/caps drop; non-root.
Read-only FS; per-task tmp; explicit write allow-lists.
Egress deny; allow-list required hosts; rate limits.
Tool RBAC per role; human confirmation for destructive actions.

Audit & Monitoring

Structured logs for auth, tool exec, secret access, denials.
Centralized SIEM with alerts for scope abuse, token anomalies.
Append-only log storage; NTP-synced clocks.
Monthly permission reviews; incident runbooks tested.

FAQs

What is the least-privilege model for MCP?

Grant each client only the minimal tools and data needed, for the shortest time, with narrow scopes; require explicit confirmation for risky actions.

Should I use API keys or OAuth for MCP?

Use OAuth/OIDC for humans (with SSO) and mTLS or client-credentials OAuth for services. API keys are acceptable for short-lived dev/testing with tight scopes.

How do I prevent tools from leaking data?

Combine egress-deny networking, output size caps, PII redaction filters, and human review for high-risk actions. Log hashes of inputs/outputs for traceability.

How often should secrets rotate?

Adopt event-driven rotation (on exposure or role change) and scheduled rotation (≤90 days). Automate via your secrets manager.

Key Takeaways

  • Authentication: OIDC for users, mTLS/OAuth for services, scoped API keys for dev only
  • Secrets: Vault/KMS storage, automatic rotation, scrubbed logs, ephemeral credentials
  • Sandboxing: Container isolation, read-only filesystem, egress deny, resource limits
  • Auditing: Structured logs, SIEM integration, tamper resistance, regular reviews
  • Least privilege: Minimal scopes, time-boxed tokens, explicit confirmations for risky actions

Related Resources