MCP security risks for Claude Code users

Model Context Protocol gives Claude Code a standard way to use external tools and data. That is useful precisely because it crosses the chat boundary: an MCP server may read files, query a database, call an API, open a browser, or run a local process. The security question is therefore not “Is MCP safe?” It is “What authority does this server add, and what prevents untrusted instructions from using it?”

1. Over-broad local authority

A local MCP server often inherits the permissions of the Claude Code process. A broadly configured filesystem server may read far beyond the active repository. A shell tool may execute any command the user can run. Environment variables can expose tokens that were never intended for the model or the server.

• Scope filesystem access to the smallest required directories and explicitly deny sensitive patterns such as .env files, private keys, and credential stores.
• Prefer named operations over arbitrary shell execution.
• Give each server only the environment variables it needs; do not pass the entire parent environment by default.
• Run untrusted or execution-capable servers in a sandbox, container, or separate low-privilege account.
• Separate development and production credentials, accounts, and network routes.

2. Indirect prompt injection becomes tool use

Claude Code can read repository content and tool results as context. If that content contains hostile instructions, the risk is no longer a strange model response. The instruction may cause a tool call, file write, secret lookup, package install, or network request. How to detect prompt injection in AI-generated code explains how to trace this path from untrusted content to an execution-capable sink.

• Assume repository text, fetched pages, tickets, logs, and database content can contain hostile instructions.
• Require strict schemas for every tool and reject extra or ambiguous arguments.
• Place permission checks between the model’s request and the real operation.
• Require approval when a tool can delete data, change authentication, publish code, access secrets, or affect production.

3. Malicious or compromised server packages

An MCP configuration can launch a package directly from a registry or repository. That makes package identity, version choice, install scripts, transitive dependencies, and update behavior part of the trust boundary. A convincing server name is not proof that the package is official or maintained.

• Confirm the publisher and follow installation links from the project’s official documentation.
• Pin a reviewed version instead of automatically running the newest release.
• Inspect the launch command and package scripts before the first run.
• Review release notes and permission changes before upgrading.
• Remove servers that are unused, abandoned, or broader than the workflow requires.

4. Weak OAuth and token boundaries

Remote MCP servers introduce normal web authorization risks plus MCP-specific trust confusion. The knowledge-base guidance highlights confused-deputy flows, token passthrough, weak redirect validation, missing state validation, and tokens accepted by the wrong audience.

• Require explicit consent for each client instead of reusing a broad approval silently.
• Match redirect URIs exactly and validate a cryptographically random OAuth state value at the callback.
• Validate token signature, issuer, audience, expiry, and scopes on every protected request.
• Do not pass through a token intended for another service. The MCP server must validate and exchange credentials at its own boundary.
• Use short-lived, narrowly scoped tokens and make revocation practical.

5. Server-side request forgery during discovery

Metadata discovery can cause a client or server to fetch attacker-controlled URLs. Without outbound restrictions, those requests may reach loopback services, cloud metadata endpoints, private network hosts, or redirected destinations.

• Allow only expected URL schemes and reject embedded credentials.
• Resolve and check destinations against loopback, link-local, private, and otherwise sensitive ranges.
• Apply the same checks after every redirect.
• Use an outbound proxy or egress policy when the MCP component runs on a server.
• Set strict timeouts, response-size limits, and redirect limits.

6. Missing evidence and stale access

If a tool call causes damage, you need to know which agent requested it, which server executed it, what arguments were accepted, which permission decision applied, and whether a human approved it. A terminal transcript alone is incomplete and easy to lose.

• Give each agent or runtime its own identity instead of sharing one long-lived key.
• Log requested and executed actions separately so denied attempts remain visible.
• Redact secrets while retaining the tool, action, risk, decision, approval state, and outcome.
• Review connected servers and active tokens on a schedule.
• Revoke access when a project ends, a machine is replaced, or a server is removed.

A pre-install checklist for Claude Code

• I know who publishes and maintains this server.
• I reviewed the exact command Claude Code will execute.
• The version is pinned and its dependencies are acceptable.
• File, shell, network, database, and secret access are narrowly scoped.
• Dangerous actions are blocked or require approval before execution.
• OAuth redirects, state, token audience, expiry, and scopes are validated.
• Outbound metadata requests cannot reach sensitive network destinations.
• Tool calls and decisions produce a redacted, searchable audit trail.
• I can revoke the server’s tokens and remove its access quickly.

Use AI agent security checklist for developers when the workflow extends beyond one MCP server. It covers the identity, runtime, memory, monitoring, and incident-response controls that belong around the whole agent system.