MCP Permissions and Security: A Practical Review Guide

Treat the server as a capability boundary

An MCP server can expose data, execute code, modify external systems, or combine all three. Review it like any other privileged integration—not like a passive prompt.

The MCP specification emphasizes user consent, data privacy, tool safety, and control. The protocol defines how clients and servers communicate; it cannot guarantee that a particular server, tool description, package, or upstream service is trustworthy.

The official MCP introduction is a useful architecture primer, but a production review must go beyond connectivity and evaluate every data and action path.

Start with source and execution model

For every server, establish:

• Canonical registry, package, repository, or vendor identity.
• Whether code runs locally or at a remote endpoint.
• The exact executable, package version, container image, or URL.
• The publisher and maintenance history.
• The data and systems the server can reach.
• The tools it exposes and whether their descriptions are source-backed.

Local stdio servers are processes on your machine. Depending on the host and operating system, they may inherit filesystem, network, and environment access. A package runner that downloads the latest release on every start increases supply-chain uncertainty; pin and inspect versions where reproducibility matters.

Remote servers shift code execution away from your machine, but they introduce a network and authorization boundary. Review the operator, endpoint, data retention, credential flow, and tenant isolation.

Classify every capability

Use a small, explicit vocabulary:

1. Read: retrieves information without intended state change.
2. Write: creates or updates state.
3. Destructive: deletes, deploys, publishes, revokes, transfers, or makes difficult-to-reverse changes.
4. Credentialed: handles secrets or authenticated sessions.
5. Networked: sends data outside the current trust boundary.

A “read” tool can still expose sensitive data, and a tool labeled read-only by an untrusted server is still an untrusted claim. Validate behavior in a test environment and inspect the underlying implementation when the stakes justify it.

Apply least privilege twice

Least privilege applies at both the credential and tool layers.

• Create a dedicated service account rather than reusing a personal administrator token.
• Grant only the required repositories, tables, projects, folders, or tenants.
• Prefer read-only scopes for discovery and analysis.
• Limit the client's enabled tool set when supported.
• Keep approval prompts for writes and destructive operations.
• Use non-production data until the integration is understood.

Do not rely on a skill or tool description to enforce these limits. The upstream system and server must reject unauthorized operations.

Protect OAuth and tokens

For remote HTTP authorization, follow the current MCP authorization specification. It requires resource-bound tokens and prohibits passing a token intended for the MCP server through to a downstream API.

Operationally:

• Use OAuth with PKCE where the client and server support it.
• Validate token issuer, audience, expiry, and scopes.
• Keep access tokens short-lived and refresh tokens protected.
• Store credentials in the client or a secret manager, not a shared configuration file.
• Never log authorization headers, tokens, codes, or client secrets.
• Revoke the credential when removing the server.

The MCP security best-practices guide explains confused-deputy, token-passthrough, session-hijacking, and consent risks in more detail.

Treat content as untrusted input

MCP resources, tool results, web pages, issue text, documents, and even tool annotations may contain adversarial instructions. A server that retrieves untrusted content can relay prompt injection into the model's context.

Reduce the impact:

• Separate retrieved data from trusted workflow instructions.
• Do not allow content to silently expand permissions.
• Require a human check before consequential actions derived from external text.
• Restrict which tools can be chained in a single unattended workflow.
• Validate structured output before passing it to another tool.
• Keep secrets out of model-visible context whenever possible.

Use approval modes deliberately

“Approve everything” is not a security strategy. A useful policy distinguishes routine read operations from state changes.

A practical default is:

• Auto-approve narrow, verified, read-only tools in a sandboxed or low-risk context.
• Prompt for writes, credential access, network expansion, and cross-system actions.
• Always prompt for destructive or production operations.
• Deny capabilities that the active workflow does not require.

If a client supports per-server and per-tool policies, review both. A broad server default can accidentally override the intent of a narrow workflow.

Test before production

Create an evaluation plan:

1. Start with disposable credentials and test data.
2. Record the advertised tools and schemas.
3. Exercise one tool at a time.
4. Observe filesystem, process, and network behavior.
5. Test malformed, oversized, and adversarial inputs.
6. Confirm authorization failures are closed, not silently downgraded.
7. Verify write and destructive calls need the intended approval.
8. Remove access and confirm the server can no longer operate.

VS Code's MCP documentation, for example, warns that local servers can run arbitrary code and provides trust and sandbox controls on supported platforms. Other clients have different controls; verify the actual host.

Prepare for revocation and response

Before enabling a server, know how to:

• Disable it in the client.
• Stop its local process or remote deployment.
• Revoke OAuth grants, tokens, and service accounts.
• Rotate any secret it could read.
• Find invocation, authentication, and upstream audit logs.
• Identify data that may have left the environment.
• Restore changed state or recover from destructive actions.

A server is safer when removal is tested, privileges are bounded, and every consequential action leaves an auditable trail.