The Model Context Protocol standardizes how an LLM discovers and calls external tools, and its main security risks come from the trust an agent places in whatever a connected MCP server tells it, rather than from the protocol's wire format itself. A malicious or compromised MCP server can perform what is often called tool poisoning, where the tool descriptions it exposes to the model contain hidden instructions that manipulate the agent's behavior the moment the tool list is loaded, before the user has even issued a request. Overly broad permissions are a related risk, since an MCP server connected to a database or file system is frequently granted more access than any single task requires, so a manipulated agent session can reach far beyond its intended scope. Because the MCP ecosystem is young, third-party servers vary widely in how carefully they validate input and authenticate callers, making unvetted community servers a real supply-chain risk for anything connected to sensitive systems. Mitigations include pinning specific, reviewed versions of any MCP server rather than always pulling the latest release, running servers in isolated environments with their own scoped credentials, and logging every tool call for later review. Nanobase AI vets and scopes MCP server integrations before connecting them to a client's production systems.

MCP's trust model, in one sentence

The Model Context Protocol lets an LLM discover and call external tools, and nearly every meaningful security risk in that design comes down to one fact: the agent trusts whatever the connected MCP server tells it, about its own tools, its own outputs, and its own identity, often without independent verification. Securing an MCP integration is less about the protocol's wire format and more about deciding how much trust to extend to each server it connects to, and building controls for the case where that trust turns out to be misplaced.

Attack catalog

AttackHow it worksPrimary mitigation
Tool poisoningA malicious server embeds hidden instructions inside its tool descriptions, manipulating the agent the moment the tool list loadsReview tool descriptions before connecting; pin reviewed versions
Rug pullA previously benign, trusted server pushes a malicious update after the agent has already been granted accessPin specific versions; monitor for unexpected server behavior changes
Tool shadowingA malicious server's tool description overrides or impersonates a legitimate tool the agent already trustsNamespace and explicitly verify tool identity, not just tool name
Confused deputyAn MCP server connected to a database or file system is granted broader access than any single task requires, letting a manipulated session reach beyond scopeScope credentials per task, not per server connection
Credential leakageSecrets passed to a server for authentication are logged, cached, or exposed through the server's own vulnerabilitiesUse short-lived, scoped tokens rather than long-lived broad credentials

Tool poisoning and rug pulls are the two risks most specific to MCP's young ecosystem, since the protocol makes it easy to add a new tool source quickly, and the same ease of adoption applies to a malicious or later-compromised one.

Vetting a third-party server before connecting it

Treat every new MCP server as an unvetted vendor until it passes the checks below, regardless of how convenient or popular it appears.

  1. Read the actual source code of the server if it is open source, or request a security review summary if it is not, rather than relying on its published description alone.
  2. Pin a specific, reviewed version rather than always pulling the latest release, since an update is exactly when a rug pull would occur.
  3. Test the server in an isolated environment first, checking what data and credentials it requests versus what its stated function actually requires.
  4. Confirm the server's tool descriptions match its actual behavior, since a mismatch is the clearest sign of tool poisoning.
  5. Check whether the server or its maintainers have a track record, favoring servers backed by an established vendor or an active, reviewable open-source community over an unverified single-maintainer project for anything touching sensitive systems.

Isolating what you cannot fully trust

For MCP servers that cannot be fully vetted, typically community projects connecting to a genuinely useful but unverified service, running them in a sandboxed environment with scoped, short-lived credentials limits the blast radius if the server turns out to be malicious or gets compromised later. Logging every tool call and its parameters, not just the agent's final output, gives a security team the trail needed to spot a poisoned tool description or an unexpected data request after the fact, which is also the same discipline covered in securing AI agents with tool access.

Frequently asked questions

Is MCP itself less secure than other tool-calling approaches?

The protocol itself is not inherently less secure than other function-calling mechanisms; the risk comes from the ecosystem of third-party servers built on it varying widely in security maturity, which is a supply-chain problem more than a protocol design flaw.

How often should a connected MCP server be re-reviewed?

Re-review any server before accepting a version update, since that is the point at which a previously trustworthy server could introduce malicious behavior, and periodically audit even unchanged servers as part of a standing security review cycle.

Can output validation catch a tool poisoning attack?

Output validation catches some downstream effects, such as an unexpected API call, but tool poisoning often manipulates the agent's behavior before any output is produced, which is why reviewing tool descriptions at connection time matters more than validating outputs alone.

How Nanobase AI helps

Nanobase AI, an NVIDIA Inception Program member, vets and scopes MCP server integrations before connecting them to a client's production systems, applying the checklist above and building the MCP server infrastructure with credential scoping and logging in place from the start.

Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.