MCP Connector Security: A Practical 2026 Checklist

MCP security is not one vulnerability. It is the combination of a model reading untrusted content, a connector exposing tools, and credentials granting those tools real authority. Secure the system by narrowing all three: what the model can read, what each tool can do, and what the authenticated identity may access.

This checklist translates the current Model Context Protocol security guidance into decisions you can apply before enabling a connector.

Start with the trust boundary

Draw the request path:

User
  -> Claude or another MCP client
  -> MCP connector
  -> authorization server
  -> downstream API or database

For each arrow, write down:

• Which identity is present
• Which token or credential is used
• Which data crosses the boundary
• Which component makes the authorization decision
• Which actions can mutate state

If the same broad token flows through every layer, the system does not have meaningful boundaries.

Anthropic's custom connector security guidance tells users to connect only trusted servers, review requested permissions, watch for prompt injection, and monitor changes in server behavior. Server builders need to make those reviews possible.

1. Bind every token to its intended resource

An access token presented to the MCP server must be intended for that MCP server.

The MCP authorization specification requires clients to use the OAuth resource parameter and servers to validate token audience. Check at least:

• Signature
• Issuer
• Audience or resource
• Expiry and not-before time
• Required scopes
• Revocation where supported

Reject a valid token with the wrong audience. "The signature passed" is not enough.

Never forward the inbound MCP token to a downstream API. Obtain a separate downstream token through the appropriate delegated flow. Token passthrough lets one credential escape the security assumptions under which it was issued.

2. Use least-privilege scopes

Do not ask for write access because a future feature might need it.

Prefer scopes such as:

orders:read
shipments:read

over:

admin
full_access

Split read and write operations into separate tools and, when possible, separate scopes. A connector used for research should not inherit the ability to delete or publish.

For multi-tenant products, OAuth scopes are only the outer gate. Every tool must still enforce tenant and resource authorization using the validated user identity.

3. Treat tool descriptions and outputs as untrusted input

Prompt injection can arrive through a web page, issue, document, email, database record, or malicious MCP server. Text returned by a tool can try to redirect the model toward another action.

Mitigations include:

• Connect only servers you operate or have evaluated
• Keep tool outputs factual and structured
• Remove embedded scripts, hidden markup, and irrelevant instructions
• Label external content as data, not authority
• Require user approval before consequential cross-system actions
• Do not let one tool output silently widen another tool's permissions

The model should not decide that a document grants authorization. Authorization comes from policy and validated identity.

4. Prevent confused-deputy authorization flows

An MCP proxy can become a confused deputy when it uses one static OAuth client with a downstream service while allowing many dynamically registered MCP clients.

The official MCP security best practices require per-client consent in this architecture. The consent screen should identify:

• The requesting MCP client
• The requested downstream scopes
• The registered redirect URI

Validate redirect URIs with exact string matching. Protect the consent flow with CSRF controls, secure cookies, short-lived single-use state values, and clickjacking protection.

Do not reuse "the user consented once" as consent for every newly registered client.

5. Block SSRF in discovery and redirects

Remote MCP authorization involves fetching metadata and following URLs. An attacker can point those requests at cloud metadata, loopback services, or private network addresses.

For production:

• Require HTTPS outside explicit local development
• Block private, loopback, link-local, and reserved IP ranges
• Validate every redirect destination
• Consider disabling automatic redirects
• Protect against DNS rebinding and time-of-check/time-of-use gaps
• Route discovery through an egress proxy with network policy

Do not write a few regular expressions and call the problem solved. URL parsing, DNS, alternate IP encodings, and redirects make home-grown SSRF filters fragile.

6. Sandbox local MCP servers

A local stdio server runs with the privileges of the client process. If it can read your home directory and access the network, a compromised package may be able to do both.

Reduce local authority:

• Prefer a dedicated working directory
• Restrict filesystem access
• Restrict outbound network destinations
• Run untrusted servers in a container or sandbox
• Pin package versions
• Review package ownership and release history
• Avoid npx -y some-package@latest for sensitive long-lived setups

For a project-shared .mcp.json, review the command before trusting the repository. Configuration is executable supply-chain surface.

7. Make writes explicit and idempotent

Write tools should communicate consequence in the tool name and description:

preview_invoice_update
apply_invoice_update

The preview tool returns the proposed change. The apply tool requires the stable object identifier, expected version, and an idempotency key.

For destructive or external actions:

• Show the target and consequence
• Require user confirmation
• Recheck authorization at execution time
• Use optimistic concurrency
• Support idempotency
• Record an audit event
• Return the final authoritative state

Do not combine "search and delete matching records" into one opaque tool.

8. Bound cost and data volume

Tool calls consume upstream capacity and can expose more data than the user intended.

Set:

• Per-user and per-tenant rate limits
• Maximum result counts
• Pagination
• Request and upstream timeouts
• Maximum response size
• Query complexity limits
• Spending limits for paid downstream APIs

Do not return entire documents or database rows when a status, count, or summary is enough.

9. Log decisions without logging secrets

An audit record should answer:

• Who authorized the call?
• Which client and connector were involved?
• Which tool ran?
• Which resource was targeted?
• Was it read or write?
• What policy allowed or denied it?
• What was the outcome and latency?

Do not log bearer tokens, OAuth codes, secrets, raw prompts containing customer data, or full tool outputs by default.

Alert on repeated authentication failures, unusual tool volume, new write-tool usage, cross-tenant denials, and changes to connector configuration.

10. Plan revocation and incident response

Before launch, know how to:

• Revoke a user's connector authorization
• Rotate client credentials
• Disable one tool without taking down the server
• Block a connector version
• Invalidate sessions and refresh tokens
• Identify affected users and resources
• Recover or compensate for unsafe writes

Short-lived access tokens reduce exposure, but revocation still matters for refresh tokens and active grants.

A pre-launch MCP security checklist

Identity and authorization

• Tokens are validated for issuer, audience, expiry, and scope
• MCP tokens are never passed through to downstream APIs
• Tenant and resource authorization occurs inside every tool
• Read and write scopes are separate
• OAuth uses PKCE and exact redirect URI matching

Tools

• Each tool performs one bounded business action
• Inputs are schema-validated and size-limited
• Outputs omit unnecessary sensitive data
• Writes are explicit, confirmed, idempotent, and audited
• Generic SQL, shell, and arbitrary HTTP tools are disabled

Network and runtime

• Production endpoints use HTTPS
• OAuth discovery and redirects are protected against SSRF
• Local servers run with limited filesystem and network access
• Dependencies are pinned and reviewed
• Rate, timeout, payload, and cost limits exist

Operations

• Logs identify the actor, tool, resource, and policy result
• Secrets and raw sensitive payloads are excluded from logs
• Connector behavior changes are versioned and reviewed
• Revocation and emergency disable paths have been tested
• Negative authorization tests run in CI

MCP connector security FAQs

Is OAuth enough to secure an MCP connector?

No. OAuth establishes delegated identity and scopes. The connector must still validate the token correctly, authorize each resource, constrain tools, protect downstream credentials, and handle prompt injection and unsafe writes.

Are read-only MCP tools risk-free?

No. Read tools can expose private data, enable cross-tenant access, trigger expensive queries, or return injected content. They are lower risk than writes, not zero risk.

Should I allow automatic approval for MCP tools?

Only for narrow, trusted, low-impact tools. Keep approval for writes, external communication, financial actions, permission changes, and tools operating on untrusted content.

How often should connectors be reviewed?

Review on every scope, tool, authentication, dependency, or hosting change. Also review periodically because the server operator can change behavior without the client configuration changing.

What should I do if I connected an untrusted MCP server?

Disconnect it, revoke its OAuth grant or token, review audit logs, rotate any exposed credentials, inspect actions taken through the connector, and check whether it could reach local files or private systems.

For a broader implementation plan, Build This Now can make the connector boundary, authorization model, threat controls, and verification steps part of the product architecture instead of a post-launch patch.

MCP security improves when authority is visible. A user should be able to tell which server they trust, which data it can reach, which actions it can take, and how to revoke that power.

Posted by @speedy_devv