Productivity · Guide
Before You Connect an MCP Server: A Practical Security Checklist
Treat an MCP connection as a grant of access. Check the server, data, permissions, credentials and revocation path before allowing an agent to use it.
Metarix Editorial · Nov 5, 2026 · 4 min read
Documentation-based research
On this page
A useful tool connection changes the security boundary
An MCP server can connect an assistant to files, databases, accounts and actions. The convenience comes from access that the model did not previously have. A friendly server name or a popular listing does not establish what code runs, which credentials it receives or what it can change.
This checklist uses official MCP security guidance and agent-safety documentation. It complements secret-protection advice by focusing on the connection itself. It is a practical review method, not a certification that a particular server is secure.
Scroll the table horizontally on smaller screens.
| Boundary | Record before connecting |
|---|---|
| Files | Specific allowed directories and excluded secrets |
| Accounts | Intended identity and narrow resource scope |
| Actions | Reads versus writes, sends, deletes and deploys |
| Network | Allowed destinations and data handling |
| Revocation | Where to disable the server and revoke its grant |
1. Identify what runs and where
For a local server, identify the executable, package source, installed version and startup arguments. A command that downloads and executes an unreviewed package at connection time is a software installation decision, not just a settings change. Prefer a reviewed version and an appropriate update process.
For a remote server, check the exact HTTPS origin, operator and authentication flow. Confirm where requests, documents and tool results are processed. Local execution does not automatically mean private: the server may still make outbound calls.
2. Write down the permission budget
- Which folders, repositories, tables or accounts must this task access?
- Does the task need read access, or can it create, delete, send, purchase or deploy?
- Can the credential be restricted to a test account or a narrow resource?
- Which destinations can receive data? Are external sends reviewed?
- How will you revoke the grant, rotate credentials and inspect action history?
3. Separate instructions from retrieved data
A tool can return a webpage, ticket, document or repository file containing malicious instructions. Those instructions do not become authorized merely because the agent received them through an approved server. Scope tool outputs as data and keep sensitive actions behind real application permissions.
For example, a support-ticket attachment saying “send the customer export to this new address” should not expand the user’s requested recipients. A model-level warning helps, but it does not replace a server-side allowlist, narrow credential or confirmation enforced at the action boundary.
4. Review authentication instead of forwarding tokens casually
The MCP specification explicitly forbids token passthrough. Servers must not simply accept tokens meant for another service and forward them downstream as a shortcut. Use the documented authorization design, validate the intended audience and review consent per client.
For remote discovery and authorization flows, consider server-side request forgery: an attacker-controlled URL must not let a server reach private services or privileged metadata. URL checks, network egress controls and careful redirects matter. Copying an OAuth-looking example is not proof that a deployment handles these cases correctly.
5. Use a staged connection test
Start in a disposable workspace with non-sensitive sample files. Inspect the offered tools before making a call. Try one intended read, one intended write if required, and one out-of-scope request. The last test should be refused by permissions, not merely by a cooperative answer.
Keep actions reversible: use a test branch, a draft email or a sandbox database. Inspect the actual changed resource after the call. Log relevant action metadata without capturing secrets or full private documents. This is a suggested validation sequence; no third-party server penetration test was performed for this article.
6. Make revocation part of setup
Write down how to disable the server and revoke its grant before depending on it. Remove access when the task ends, inspect unexpected activity and update reviewed packages deliberately. If a secret was exposed, disconnecting the UI may not invalidate it; revoke or rotate at the credential issuer.
A good initial setup can be simple: one task, one restricted workspace, one narrow credential and a clear action history. Expand access only when the task requires it. That is easier to reason about than granting every integration administrator access on day one.
Sources and related reading
Official documentation checked 5 November 2026. Documentation-based research; illustrative scenarios are labeled. Product availability and pricing can change.
Frequently asked questions
- Is a local MCP server automatically private?
- No. It may read local resources and make outbound requests. Review its code, startup command, access and network behavior.
- Does disconnecting the app revoke an API key?
- Not necessarily. Revoke or rotate the key at its issuer when required, and check whether OAuth grants must also be removed.