An MCP security checklist should verify which servers an AI agent can use, what data and actions those servers expose, and where permissions are enforced. Secure Model Context Protocol deployments need more than a successful connection: they need scoped credentials, isolated local processes, checks before sensitive actions, and logs that explain what happened.
This guide covers local stdio servers and remote HTTP servers. The MCP specification defines how clients and servers communicate; it does not enforce your application’s security policy for you.
The protocol-specific guidance below was reviewed against the July 28, 2026 revision. Check the version your client and server actually implement before applying version-specific requirements.
The 12-point MCP security checklist
Use these checks before granting production access, then repeat them when servers, tools or permissions change.
- Inventory active servers. Record the owner, transport, endpoint or startup command, version and connected systems.
- Review server changes. Pin local packages and review changes to tool definitions and deployment behavior.
- Limit tools and credentials. Grant only the repositories, folders, records and actions the task needs.
- Validate OAuth tokens. Check the intended recipient, expiry and permissions; never pass incoming MCP tokens to upstream APIs.
- Isolate local execution. Restrict filesystem access, network access and inherited secrets.
- Approve sensitive actions. Show the actual operation, target and arguments, then enforce that decision outside the model.
- Treat tool content as untrusted. Descriptions and returned text must not override policy.
- Validate tool calls. Check arguments, access rights, output structure, rate limits and timeouts.
- Protect HTTP endpoints. Validate browser origins and keep local-only servers bound to loopback.
- Restrict OAuth discovery requests. Prevent redirects or DNS changes from reaching unapproved destinations.
- Check access on every request. Bind stored workflow state to the authenticated user and tenant.
- Keep redacted logs and test shutdown. Verify that you can disable a server and revoke its access.
Inventory what the client actually loads
Reviewing a repository’s .mcp.json is not a complete inventory. Claude Code can also load servers from other configuration scopes, plugins, managed configuration and connected services. Check the active client, not just files in Git. Claude Code security guidance also cautions that a directory listing is not a security audit of a server.
For Claude Code, start with the commands below. Replace your-server-name with the configured server name:
claude mcp list
claude mcp get your-server-nameInside Claude Code, use /mcp to inspect connected servers. WebSocket servers do not appear in claude mcp list; use claude mcp get or /mcp for those. See the MCP configuration documentation.
Configuration scope tells you where a server is available, not what it can access:
- Local: private to the current project, stored in
~/.claude.json. - Project: shared through the repository’s
.mcp.json. - User: available across projects, stored in
~/.claude.json.
A project-scoped server with a broad credential still has broad access. Enforce restrictions in the credential, server and operating environment.
Read-only labels do not enforce read-only access
MCP tool annotations such as readOnlyHint describe expected behavior. They are not permission checks. A server can mislabel a tool, and a read operation can return attacker-controlled instructions. The MCP maintainers explain this distinction in their tool annotations guidance.
Consider an agent that reads a public issue, can fetch private documents and can send external messages. An instruction hidden in the issue could ask it to fetch a document and send the contents elsewhere. Individually useful tools can create a dangerous combination.
Limit both the data the agent can read and the destinations it can send to. For sensitive actions, the approval screen should show the exact target and arguments. Trusted code must reject an operation that differs from what was approved. A model agreeing to follow policy is not that control. OWASP prompt injection guidance recommends enforcing these boundaries outside the model.
Review local MCP servers as executable code
With stdio, the client launches a server process. Avoiding a listening network port does not restrict that process’s filesystem or outbound network access. Review the executable, package source, version, arguments and environment before launch. Protect MCP configuration files from unapproved changes.
Run local servers with only the folders, network destinations and secrets they need. Review package updates and tool-description changes separately: an unchanged description does not prove unchanged server behavior. These checks follow the OWASP MCP security guidance.
For the underlying execution path, read how MCP stdio configuration becomes local code execution.
Validate tokens before executing tools
For protected remote MCP servers, verify that an access token was issued for that server, remains valid and permits the requested action. A token accepted by another API should not become an MCP credential by accident.
Clients must include the OAuth resource parameter in authorization and token requests. Authorization-code flows require PKCE; clients must verify that the authorization server advertises support and use S256 when capable. Use HTTPS authorization endpoints, exact redirect URI validation and secure token storage.
Do not forward an incoming MCP access token to GitHub, a database API or another upstream service. Use a separate token intended for that service. Prefer short-lived access tokens and rotate refresh tokens for public clients. These are covered in the MCP authorization security considerations.
Protect HTTP and OAuth discovery endpoints
For Streamable HTTP, validate the Origin header. If it is present and invalid, the server must return HTTP 403. A non-browser client may omit it, so absence is not a replacement for authentication. Local-only HTTP servers should listen on 127.0.0.1, not every network interface. See the transport security requirements.
OAuth discovery can also make the client fetch URLs supplied by a server. Restrict those requests, redirects and resolved addresses so they cannot reach cloud metadata services or other unapproved destinations. Recheck redirects and DNS resolution, not just the initial URL. Internal MCP deployments may need private network access; allow specific approved destinations instead of assuming all private addresses are safe or forbidden. MCP security best practices cover this server-side request forgery risk.
Authorize the user, not a workflow ID
The July 2026 protocol has no protocol-level session. A server can still maintain application state, such as a browser context or database transaction, using an explicit handle passed between tool calls.
For authenticated servers, that handle is a reference, not permission. Check the authenticated user’s access every time it is used. Scope it to the correct tenant, use unpredictable identifiers and define expiry. Knowing another user’s workflow ID must not let a caller read or change that workflow. See the MCP stateful tool guidance.
A managed Claude Code policy example
If your organization uses Claude Code, put server restrictions in administrator-controlled managed settings. For example:
{
"allowManagedMcpServersOnly": true,
"allowedMcpServers": [
{ "serverUrl": "https://mcp.example.com/mcp" }
]
}Replace the example URL with an approved endpoint. Both fields belong in managed settings. The lock prevents user and project settings from broadening the allowlist; this cross-source behavior requires Claude Code 2.1.273 or later.
Use endpoint restrictions or exact startup commands, not just a friendly server name that someone can reuse. Review built-in and managed-provided servers separately: they have allowlist exceptions. This example is one policy layer, not a complete list of everything the client can access. See Claude Code managed MCP configuration.
Test the controls, not just the connection
A green connection status proves connectivity. It does not prove that unauthorized actions fail.
Use dummy secrets, test accounts and sandboxed tools. The following checks are starting points, not a complete security assessment:
| Test | Expected result |
|---|---|
| Ask a restricted identity to read a forbidden repository or folder | The server or operating environment denies access. |
| Place an instruction to export dummy private data in a tool result | No unauthorized read or external send occurs. Inspect actual tool activity. |
| Present a token issued for another resource | The server rejects it before executing the tool. |
| Use account B to access account A’s stored workflow handle | Authorization rejects access to A’s state. |
Send a present but invalid Origin to a Streamable HTTP endpoint |
The server returns HTTP 403. |
| Change the target after a sensitive action is approved | Execution rejects the changed operation. |
For prompt injection tests, put the payload where an attacker could actually place it, such as an issue body or retrieved document. Also test a legitimate task that should succeed. Passing a few chosen payloads does not demonstrate resistance to all prompt injections. OWASP’s testing guidance explains why both attack cases and benign controls matter.
Validate tool inputs and access rights in server code. Apply rate limits and client timeouts, and validate structured results against their declared schema. The MCP tool security requirements make these implementation responsibilities explicit.
Keep logs you can use safely
Record the actor, server, tool, timestamp, policy decision, approval reference and outcome. Keep enough redacted argument detail to reconstruct the action, without collecting tokens, passwords or sensitive document contents by default. Limit log access and set retention rules. OWASP’s MCP checklist includes logging and incident-response controls.
Finally, test your own shutdown procedure: disable a server, revoke its credentials and confirm what access remains, including already-issued tokens. Document the provider’s revocation behavior and the time needed to cut access.
Need help reviewing the tool access in your AI application? Talk to Cantina.
