MCP Security

Rug Pull Risk in MCP Servers: Governance Controls That Prevent Behavioral Drift

Previously approved MCP servers can change behavior, permissions, or data access after integration without triggering a new review. This page explains how the protocol trust model creates that gap and which governance controls close it.

Request a Demo Talk to an Expert
In brief: Rug pull risk in MCP servers arises because the specification treats tool descriptions as untrusted, mutable data and allows servers to update their exposed tool set at any time. Mitigating it requires continuous runtime verification: baseline pinning of tool definitions, scoped and revocable authorization, policy enforcement on every tool call, and detailed audit logging.

What Constitutes a Rug Pull in MCP

A rug pull in the Model Context Protocol context occurs when a server or tool that was reviewed and approved by an enterprise later changes its behavior, permissions, or data access without a corresponding change in the trust or review process. The tool a security team approved during onboarding is not guaranteed to be the same tool an AI agent invokes weeks later.

Security research from Invariant Labs has formally documented this pattern, describing how a previously approved tool definition can be altered post-approval in a way that changes its function without prompting a new review cycle. This differs from a conventional supply chain compromise because the change can happen entirely within normal protocol operation, not through an external breach.

How the Protocol's Trust Model Enables This

MCP's architecture is built around a host-client-server model where servers expose tools, resources, and prompts to AI clients over a standardized interface. Two design characteristics create the conditions for rug pull risk.

First, the specification includes a notifications/tools/list_changed mechanism, meaning a server can natively update its exposed tool set after a client has already connected and been granted access. This is a protocol feature, not an implementation defect.

Second, MCP guidance explicitly states that tool descriptions and annotations originate from the server and should not be treated as trusted or authoritative for security-relevant decisions, yet many integrations rely on those same descriptions to inform authorization logic. The base specification does not mandate cryptographic signing or versioning of tool definitions, so there is no built-in way to confirm that a tool invoked today matches the one reviewed at approval time.

For remote, HTTP-based servers, this gap widens further because the server owner retains independent control over server logic after the client's original review, separating the trust decision from ongoing enforcement.

Where Rug Pull Risk Originates in MCP

Four protocol and deployment characteristics combine to create the opening for post-approval behavioral change.

  • Dynamic tool lists Servers can update their exposed tools after connection via native notification mechanisms.
  • Untrusted tool metadata MCP guidance treats tool descriptions as server-supplied and not authoritative for security decisions.
  • No built-in integrity check The base specification does not require signing or versioning of tool definitions.
  • Remote server control HTTP-based servers remain under the operator's control after the client's original approval.

Governance Controls That Close the Gap

Effective mitigation shifts from one-time approval to continuous runtime verification. The following controls address the trust gap directly.

Identity verification for servers and agents

Establish verifiable identity for MCP servers and the agents calling them, rather than relying on a single point-in-time connection event, so access decisions can be tied to a known and current identity.

Scoped, revocable permissions

Apply OAuth 2.1-based authorization to remote MCP servers so access is granted in narrow, revocable scopes instead of broad, static trust that persists indefinitely after approval.

Runtime policy enforcement

Insert a policy or gateway layer between MCP clients and servers to inspect and evaluate tool calls at the moment of execution, not only during onboarding review.

Baseline comparison of tool definitions

Maintain a stored baseline, such as a hash or schema snapshot, of approved tool definitions and compare it against the live definition on each session to detect unauthorized changes.

Continuous auditability

Log tool-call requests, responses, and the tool description payloads present at the time of each call to support forensic reconstruction if a rug pull is suspected.

Implementing Continuous Verification in Practice

In practice, continuous verification means treating every tool invocation as a policy decision, not a continuation of a past approval. Teams typically combine baseline pinning with a gateway that intercepts calls, compares live tool metadata to the approved snapshot, and enforces scoped tokens before the call proceeds. When a drift event is detected, automated alerts and re-approval workflows keep legitimate updates from being blocked indefinitely while still preventing silent behavioral change.

Operational tradeoff: Baseline comparison requires storing and maintaining reference states for every approved tool, and re-approval workflows can slow legitimate, benign updates if not tuned carefully. Logging full tool-call payloads increases storage and monitoring requirements. These costs should be weighed against the alternative: without runtime checks, an enterprise has no reliable way to confirm that a server's behavior at invocation time matches what was reviewed at approval time.

Aligning MCP-specific controls with existing enterprise least-privilege and change-management policies, rather than treating MCP integrations as a separate exception, helps limit the added operational burden while closing the visibility gap.

Evaluation Questions for MCP Governance Controls

Use these questions when assessing whether a control stack actually addresses rug pull risk, rather than only covering initial onboarding.

  • Does the control verify tool definitions against a stored baseline before every invocation, not only at initial connection?
  • What mechanism detects and alerts on changes to a previously approved server's tool descriptions, schemas, or scopes?
  • Can the control enforce OAuth 2.1-based scoped authorization and support token revocation for remote MCP servers?
  • What logging is captured for MCP tool calls, and can it reconstruct the tool definition state at the time of each call?
  • Does the control support automated re-approval workflows when a connected server's behavior or metadata changes?

Move from One-Time Approval to Continuous MCP Governance

Rug pull risk exists because MCP's trust model was not designed for ongoing behavioral verification. Runtime governance closes that gap by enforcing permissions and monitoring tool behavior on every call, not just at onboarding.

Request a Demo