MCP security checklist: what to verify before connecting a server

Start with the real blast radius

The first question is not “does this server work?” but “what can it do with my privileges?”. List the files, APIs, accounts, databases and networks it can access. A simple-looking tool becomes high risk when it inherits an administrator token, full disk access or unrestricted access to an internal network.

OWASP documents MCP-specific risks including malicious tool descriptions, definition changes after approval, excessive permissions, data exfiltration and dangerous interactions between multiple servers. A useful checklist therefore covers code, authorization and the way data reaches the model.

1. Verify provenance before installation

Identify the publisher, source repository, installation method and exact version you are about to run. Avoid commands copied from unknown sources and double-check package names: typosquatting is especially dangerous when installation immediately grants access to secrets or the filesystem.

For a critical dependency, prefer a pinned version or another mechanism that identifies exactly what was reviewed. A legitimate update can still change behavior or tool definitions, so it deserves the same attention as a new integration.

• Publisher and source repository are identifiable.
• Version or revision is known.
• Dependencies and installation method have been reviewed.
• No secret is embedded in the install command or repository.

2. Grant the minimum permissions

Each server should receive only the permissions required for its job. A server that reads documentation should not automatically see the whole machine. A read-only integration should not receive a token that also allows deletion or administration.

OWASP recommends separate credentials per server, narrow scopes and short-lived tokens when the architecture supports them. That limits the impact of a compromised component and prevents a general-purpose tool from becoming a gateway into several systems.

3. Check authentication and authorization

For a remote server exposing private data or actions, verify how callers are authenticated and how every protected request is authorized. MCP 2026-07-28 hardens several authorization details, including issuer validation in relevant OAuth flows and stronger isolation of client registration information.

An MCP access token should not become a universal credential for downstream APIs. The server should validate audience and scope, then use an appropriate downstream credential when it calls another service. Do not keep long-lived tokens in a synchronized or version-controlled configuration file.

4. Treat tool descriptions as untrusted content

Descriptions, parameters and tool results can enter the model's context. A malicious server can try to steer the agent through hidden or misleading instructions, so reviewing only the tool name is not enough.

Inspect the complete definition: name, description, parameters, annotations and expected effects. If your client can detect changes, require fresh review when a definition changes. Tool annotations can inform the UI, but they must not replace authorization enforced by trusted code.

5. Validate inputs and outputs

Arguments proposed by a model are untrusted input. Validate file paths, identifiers, URLs, queries and formats before execution. Avoid tools that turn an arbitrary model-generated string directly into a shell command. For network tools, enforce explicit destination rules to reduce SSRF and internal-service exposure.

Outputs are untrusted too. A web page, ticket or document can contain instructions aimed at redirecting the agent. Prefer structured extraction where possible and keep sensitive decisions in application code even when the model says an action is safe.

6. Isolate the server and shrink its environment

A local server launched over stdio does not expose a network listener, but the process can still read files or open network connections if its operating-system permissions allow it. Run unfamiliar integrations in a restricted environment and mount only the directories they genuinely need.

For remote deployments, restrict outbound network access and the secrets available to the process as well. The goal is straightforward: compromising one server should not automatically compromise everything available to the machine or hosting account.

7. Keep human approval for high-impact actions

Deletion, publishing, payments, permission changes and external messages should not depend only on the model's judgement. Show the action and its parameters to the user, then bind approval to that exact operation. A generic confirmation at the start of a session is not the same as authorizing a destructive call later.

OWASP explicitly recommends human oversight for sensitive operations. This does not prevent useful automation: low-risk reads and reversible operations can use lighter policies, while high-impact actions keep an additional gate.

8. Log enough to investigate, not enough to leak

Keep enough evidence to understand which tool ran, under which user and policy context, and what decision was made. Do not automatically copy secrets, full documents or personal data into logs simply because they passed through a tool.

Rate limits, timeouts and resource budgets complement that visibility. An agent stuck in a tool loop can create denial-of-service conditions or unexpected cost even when there is no traditional attacker.

9. For HTTP: TLS, origin and network exposure

A remote HTTP server should use TLS and expose only the interfaces it truly needs. OWASP's MCP guidance also highlights origin validation where browser contexts apply and verifying that access tokens are intended for the correct resource.

A server intended only for the local machine should not listen on every interface by default. Likewise, a public gateway must not accidentally turn an unauthenticated internal service into an Internet-facing endpoint.

The checklist before you click Connect

Before first use, you should be able to answer yes to the checks below. If an answer is missing, reduce the scope or test inside an isolated environment before introducing real data.

Secure first, connect second

MCP makes interoperability easier, which also makes it faster to connect new tools. The answer is not to reject every integration, but to make trust explicit: known source, minimum permissions, controls enforced in code and isolation proportional to risk.

If the architecture itself is still unclear, start with our Model Context Protocol guide. When comparing assistants or clients afterwards, use a repeatable method such as our AI tool evaluation guide.