Start assessing
0/33 answered
Identity & Auth
—
Isolation
—
Tooling
—
Validation
—
Secrets & Deploy
—
Supply chain & Monitoring
—
1. Strong identity, authentication & policy
Authentication in MCP is optional by default, and many examples ship over plain HTTP. Treat auth as mandatory and enforce policy centrally.
Do all remote MCP servers require OAuth 2.1 / OIDC (not optional, no anonymous access)?
Is every request validated for token signature, issuer (iss), audience (aud) and expiry (exp)?
Are access tokens short-lived (minutes) and narrowly scoped to the minimum needed?
Do you avoid token passthrough — never forwarding the client's token to downstream APIs?
Is authentication, authorization, consent and tool filtering enforced at a central policy/gateway layer?
Is transport encrypted — TLS 1.2+ for remote, and local HTTP bound to 127.0.0.1 with Origin validation?
2. Strict isolation & lifecycle control
MCP servers manage many concurrent sessions and often share identity or compute. Without hard separation you get cross-tenant leakage and impersonation.
Is per-user/per-session state fully isolated (no global variables, class attributes or shared singletons for user data)?
Does each user's action run under a distinguishable identity (not one shared service account)?
On session end / timeout / disconnect, are file handles, temp storage, in-memory context and cached tokens deterministically destroyed?
Are per-session resource quotas enforced (memory, CPU, filesystem, API rate) keyed to session/user?
Is tool/code execution sandboxed (containers or micro-VMs), not run in a shared host process?
3. Trusted, controlled tooling
Tool descriptions are fed to the model automatically, and tools can be swapped after approval ('rug pulls'). Treat tool definitions as a trust boundary.
Does every tool ship a cryptographically signed manifest (description, schema, version, permissions) verified at load time?
Are tools version-pinned so a trusted definition can't be silently swapped or modified at runtime ('rug pull')?
Is there a formal approval workflow to add/update a tool (SAST, dependency scan, manual security review)?
Do you validate that a tool's advertised description matches its actual runtime behavior?
Are only minimal, necessary tool fields exposed to the model (internal/sensitive metadata kept out of model context)?
Are tool names namespaced and collisions detected, so a malicious server can't shadow a trusted tool's name?
4. Schema-driven validation & prompt-injection controls
Treat every message — from the model and from tools — as untrusted. Funnel intent through schemas and gate high-risk actions.
Are all MCP messages, tool inputs and tool outputs validated against a strict JSON Schema, rejecting anything malformed?
Are inputs/outputs sanitized, encoded and size-limited (stripping sequences that enable XSS / SQLi / RCE)?
Do you prefer structured JSON tool calls over free-form model-generated command text?
Do high-risk actions (delete data, send money, system changes) pause for explicit human confirmation?
Are auto-approvals restricted so users aren't desensitized into blanket-approving (consent fatigue)?
For high-risk calls, do you run a separate policy/LLM-as-a-judge check in a distinct context?
5. Secrets & hardened deployment
Configuration files often store tokens in plaintext, and servers run with too much privilege. Lock down secrets and the runtime.
Are secrets stored in a vault (never in env vars, logs, plaintext config or code) and never exposed to the LLM?
Does the server run in a minimal, hardened container as a non-root user with unnecessary packages/capabilities dropped?
Is the server network-segmented (firewall / K8s NetworkPolicies blocking all inbound/outbound except what's required)?
Do responses to the model/client avoid leaking stack traces, tokens, filesystem paths or tool internals?
Does CI/CD fail the build on a new vulnerability, unapproved dependency or failed policy check (security gate)?
6. Supply chain, monitoring & governance
Malicious servers get uploaded to unofficial repositories, and threats surface at runtime. Verify what you install and watch what it does.
Do you verify the source of every MCP server you install (guard against typosquatting / dependency confusion / fake branding)?
Are dependencies version-pinned, scanned (SCA) and images signed, with an SBOM/AIBOM maintained?
Are all security-relevant events logged (tool calls with params, resource access, auth events, config changes) — immutably and with sensitive data redacted?
Do audit logs feed a monitoring system (SIEM) with real-time alerts on suspicious patterns (failed-validation spikes, high-frequency or anomalous tool calls)?
Are runtime protections in place (seccomp / AppArmor / specialized MCP runtime guards) to constrain a compromised tool?
Your prioritized action list
Answer the controls above and your prioritized gaps will appear here, worst-first.
Built on the work of others — please credit them too
This checklist adapts (does not copy) guidance from:
- OWASP GenAI — A Practical Guide for Secure MCP Server Development (v1.0, CC BY-SA 4.0)
- SlowMist — MCP Security Checklist
- Palo Alto Networks — MCP Security Exposed: What You Need to Know Now
This self-assessment is guidance, not a guarantee — a high score reduces risk but does not certify security. Pair it with real testing (SAST/SCA, penetration testing) and the secure-MCP course.