The honest trade-off behind every MCP connection

You found an MCP server that does something genuinely useful — it reads your Notion workspace, checks your Cal.com calendar, or queries your internal API. It could save you hours. But connecting it means handing an AI agent a key to part of your digital life.

That is the real question every founder should ask: what am I actually giving away when I hit connect?

The Model Context Protocol (MCP), introduced by Anthropic, standardizes how AI assistants reach external tools, databases, and files. It cuts through the fragmentation that used to make AI integrations expensive and slow. But the protocol itself does not include authentication or authorization. Every server you deploy inherits whatever permissions it is granted, and every request flows through without verification unless you add controls yourself [5][6][8].

This is not meant to scare you away from MCP. It is meant to make sure you do not hand over more access than you intend.

What MCP servers actually touch

Before evaluating any server, understand what category it belongs to. MCP servers fall into a few broad buckets, and each bucket carries a different risk profile:

Read-only data servers. These pull information from a source — a knowledge base, a CRM, a public API. They do not write or change anything. Risk is mostly around data exposure: can the server leak what it reads? [5]

Write-capable servers. These create, update, or delete resources — sending emails, posting to a project board, modifying database records. The blast radius is larger because a compromised or confused agent can take irreversible action. [5][7]

Proxy or gateway servers. These sit between your AI client and a third-party API, acting as an OAuth bridge. They introduce a “confused deputy” risk: the proxy may execute actions under its own privileges rather than yours, or malicious clients may exploit dynamic registration to bypass consent flows. [7][8]

Local file and system servers. These give agents direct access to your filesystem or shell commands. Even read-only filesystem access can expose sensitive configuration files, API keys, or internal notes. Command execution adds arbitrary code risk. [6][7]

Identifying which bucket a server sits in should be your first step before reading a single line of documentation.

A practical checklist for evaluating MCP servers

When you are hunting for tools that remove pain, speed matters. But speed should not mean skipping the step where you verify what a connection actually does.

1. Review the permission scope

Check what the server claims to access and compare it to what it actually needs. If a server that fetches meeting notes asks for full drive access, that is a mismatch worth investigating. Over-privileged servers are one of the most common warning signs across the MCP ecosystem. [5][7]

Ask yourself:

  • Does the declared scope match the stated purpose?
  • Are there optional permissions that seem unnecessary for the core task?
  • Can you grant read-only access and still get the functionality you need?

2. Examine credential handling

How does the server store and use authentication tokens? Plaintext credential exposure in local configuration files is a real and documented risk. If a server stores API keys or tokens in plain text without encryption, those credentials are vulnerable to theft from your machine. [6][7]

Look for these signals:

  • Credentials stored in encrypted or OS-backed secret managers rather than plain config files
  • Use of scoped, short-lived tokens instead of permanent API keys
  • Clear documentation on where and how credentials are persisted
  • No requirement to paste credentials directly into the server config

If a server cannot explain its credential handling, treat that as a red flag. [6]

3. Check for input validation and sanitization

Unauthorized command execution is a known vulnerability in poorly implemented MCP servers. When user-supplied data is passed into system-level commands without sanitization, it opens the door to command injection. [7]

While you may not be able to audit source code for every server, you can look for signs of defensive design:

  • Servers that validate and sanitize inputs before using them in commands
  • Sandboxed execution environments that limit what a server can reach
  • Documentation that mentions input boundaries and allowed operations

4. Watch for supply chain risk

MCP servers depend on software components and build pipelines, making them vulnerable to supply chain attacks. A compromised dependency can turn a seemingly harmless server into an attack vector. [5][7]

Practical things to check:

  • Is the server open source with a visible commit history?
  • Are dependencies pinned and auditable?
  • For cloud-hosted servers, does the provider offer cryptographic verification so you can confirm you are connecting to the legitimate endpoint?
  • Has the project undergone security review or published a security policy?

Signing and verifying MCP components is a practice the community is moving toward, but adoption is uneven. [7]

Consent fatigue is a real attack pattern. A malicious or carelessly designed MCP server can repeatedly trigger permission requests until you click through without reading them. Over time, you may grant far more access than you intended. [6]

Protect yourself by:

  • Reading every permission prompt carefully the first few times a new server asks
  • Denying or limiting permissions on first contact, then expanding only if the server proves reliable
  • Using servers that request permissions one at a time rather than bundling broad access upfront

6. Evaluate the confused deputy risk

The confused deputy problem occurs when an MCP server executes actions using its own privileges instead of acting strictly on your behalf. If the server lacks proper delegation controls, you may indirectly gain access to resources you should not control — or worse, the server may act beyond what you authorized. [7][8]

This is especially relevant for proxy servers that bridge your AI client to third-party APIs using a static OAuth client ID. In vulnerable configurations, malicious clients can exploit dynamic registration and consent cookies to obtain authorization codes without proper consent. [8]

When choosing a proxy-style server, prefer implementations that enforce per-user token delegation and never mix your identity with the server’s own credentials.

7. Consider runtime isolation

Insufficient sandboxing increases the likelihood of a breach. A server that runs in full isolation from your primary environment limits the damage even if it is compromised. [6][7]

Sandboxing options vary by setup. Some MCP hosts let you restrict network access, file access, or command execution per server. Evaluate whether your host supports these constraints and configure them before enabling any new connection.

8. Inspect the server’s track record

Even well-meaning servers can behave suspiciously. Backslash security research categorized real-world MCP risks into three types: malicious servers built to exploit, suspicious servers that behave beyond their declared scope, and vulnerable servers whose design creates openings for misuse. Confirmed malicious servers are rare, but vulnerabilities are widespread because many were built for speed, not resilience. [10]

Watch for behavior that goes beyond the server’s stated purpose — excessive permissions, unexpected data flows, or structures that do not align with standard patterns. These are signals that warrant closer inspection. [10]

When to walk away

Not every MCP server is worth the connection, even if it looks useful.

Walk away if:

  • The server requires broad permissions that exceed its stated function
  • It stores credentials in plaintext with no encryption or secret management
  • It has no visible security documentation or audit trail
  • It is a closed-source proxy that cannot verify its supply chain
  • It demands access to systems you would not comfortably hand to a junior team member

The convenience of a single connection is real. But the cost of a breached API key, leaked customer data, or an unauthorized action taken in your name can far outweigh the time saved.

How this fits into your tool evaluation routine

You already evaluate tools on functionality, pricing, and fit. Add security posture to that list. For MCP servers specifically, the evaluation can be quick without being careless:

  1. Identify the server category — read-only, write, proxy, or local access.
  2. Check the permission scope against the stated purpose.
  3. Verify how credentials are handled.
  4. Look for input validation, sandboxing, and supply chain transparency.
  5. Decide whether the risk is proportional to the time and pain the server removes.

If a server passes those five checks and still looks valuable, connect it. If it fails any of them, look for an alternative or skip it entirely.

FAQ

Is MCP inherently insecure? No. MCP is a protocol, not a product. Its security depends on how individual servers are implemented and configured. The protocol intentionally leaves authentication and authorization to the implementer, which means responsibility falls on you and the server developer. [5][6][8]

Do I need an enterprise security tool to use MCP safely? Not necessarily. Basic vigilance — reviewing permissions, checking credential handling, limiting scope — goes a long way. Enterprise-grade tools like policy-driven access control and runtime guardrails can add layers of protection, especially for teams managing multiple agents, but solo founders can start with the checklist above. [5][7]

Can I audit an MCP server before connecting it? For open-source servers, yes — you can inspect the code, dependencies, and configuration. For hosted or closed-source servers, you are limited to documentation and reputation. In both cases, the safest approach is to start with minimal permissions and expand only as you gain confidence. [7][10]

What is the biggest risk most founders overlook? Consent fatigue and the confused deputy problem. Both are subtle. One makes you click through permissions without noticing; the other means the server acts on its own authority rather than yours. Neither shows up in a feature comparison. [6][8]

Should I use the official MCP registry? The official registry provides a starting point, but inclusion does not guarantee security. The registry is a discovery tool, not a vetting process. You still need to evaluate each server individually using the checks outlined here. [5][7]

Sources