Vercel AI SDK Tool Drift Defenses: Stop MCP Rug Pulls

Vercel AI SDK tool drift detection is now a first-party feature: ai@7.0.19, published July 9, 2026, ships fingerprintTools and detectToolDrift to catch MCP tools whose descriptions or schemas are silently mutated after you trust them — the attack the release notes name directly as “MCP tool-definition drift (‘rug pull’)”.

The stakes are structural, not hypothetical. The MCP specification allows a server’s tool list to change between calls with no required re-approval and no integrity check — that is a protocol property, not a bug. Every description, tool name, and argument schema a connected server advertises flows into your agent’s prompt. A server you approved in March can quietly serve different instructions in July, and until now the mainstream JavaScript agent stack had no built-in way to notice.

This guide covers what shipped in the patch, how the rug-pull attack class actually works, the fifteen-month path from proof-of-concept to framework-native defense, an implementation walkthrough on the current v7 API, a decision table for vendoring versus fingerprinting, and — because most coverage undersells this — an honest accounting of what fingerprinting cannot do.

AI SDK 7 shipped on June 25, 2026 with an agent-focused feature set: opt-in HMAC-signed tool approvals to prevent forged approvals, a WorkflowAgent for durable workflows, a HarnessAgent API for deploying across coding-agent runtimes, and a new separation between model-visible tools and app-only tools for MCP servers. Fourteen days later, ai@7.0.19 (July 9, 2026, 18:07 UTC) extended that security posture to the tool definitions themselves — the first framework-native drift-detection primitive we have seen land in a mainstream JavaScript agent SDK.

The two headline utilities work as a pair. One captures a trusted snapshot; the other compares reality against it later.

One packaging detail worth getting right on day one: the fingerprint utilities import from the core ai package, while createMCPClient — the MCP client constructor you use them alongside — ships from the separate @ai-sdk/mcp package in AI SDK 7. Several older tutorials still show the v5/v6-era experimental_createMCPClient import; that is not the current API. The v7 MCP client supports three transports: HTTP (recommended for production), SSE as a production alternative, and stdio for local development only.

Elastic Security Labs’ September 2025 definition is the cleanest one in circulation: a rug pull occurs when “a tool’s description or behavior is silently altered after user approval, turning a previously benign tool potentially malicious.” The key phrase is after user approval. Unlike a phishing lure, the attack does not need you to make a bad decision — it needs you to make a good decision once, and then it changes the thing you decided about.

The canonical proof-of-concept comes from Invariant Labs, which first publicly documented the attack class on April 1, 2025. Their demo server exposes a benign “get fact of the day” tool. The client reviews it, approves it, everything works. On a later tools/list call, the server swaps in a poisoned description that instructs the agent to misuse a separately connected, fully legitimate WhatsApp MCP server — exfiltrating chat history to an attacker-controlled number. The malicious server never touches the data itself; it steers the agent’s hands.

Why is this possible at all? Because the MCP specification (2025-11-25 is current at this writing) allows a server’s tools/list response to change between calls with no required re-approval and no integrity check. Security researcher Nasser Ali Alzahrani put it bluntly in ReversingLabs’ April 2026 coverage: “Your AI agent’s tools can change after you approve them, without triggering any notification or re-consent. The MCP spec allows this by design.” It is a different failure mode from agentjacking, a related MCP attack pattern where a server is hostile from first contact — rug pulls specifically weaponize the time gap between approval and use.

The attack surface this targets keeps compounding. Public registries tracked roughly 10,000+ MCP servers by April 2026, up from about 6,800 at year-end 2025 — a 47% jump in four months, per third-party registry aggregates (PulseMCP, the official MCP registry, Smithery, mcp.so, and npm keyword tags). Every one of those servers is a party whose tool text your agent may be ingesting as trusted prompt content.

No single source lays out the full chronology, so we assembled it. From Invariant Labs naming the attack on April 1, 2025 to Vercel shipping a native detection primitive on July 9, 2026 is a little over fifteen months — a window in which the mitigation ideas moved steadily downstream: from security-research blogs, to a formal threat-modeling paper, to vendor guidance, to code in the default toolchain.

Two things stand out in that chronology. First, the shipped mechanism is not new thinking — Invariant’s own 2025 mitigation list already recommended pinning MCP server versions via hashes and checksums; the ETDI paper formalized signing a few months later. What changed in July 2026 is where the control lives: in the framework developers already import, rather than in a security product they would have to go find. Second, the interval matters as a signal. Randolph Barr, CISO at Cequence Security, called this “the early emergence of a distinct category worth naming: post-deployment drift attacks in AI systems, more colloquially known as ‘rug pulls.’” When an attack class gets a name, a formal model, vendor guidance, and then first-party framework support inside fifteen months, that is the security ecosystem treating agentic tooling as production infrastructure — the same trajectory dependency signing took in traditional supply-chain security, compressed.

The mental model is a lockfile for tool definitions. fingerprintTools pins the three server-controlled fields of each tool — description, input schema, and title — at the moment you decide to trust the server. detectToolDrift compares any later fingerprint against that baseline and surfaces what changed, before the tool text reaches the model’s context. On the current v7 API, the whole loop looks like this:

import { createMCPClient } from "@ai-sdk/mcp";
import { detectToolDrift, fingerprintTools } from "ai";

const mcpClient = await createMCPClient({
  transport: { /* HTTP transport — recommended for production */ },
});

// 1. At trust time — after your team reviews the tool set
const tools = await mcpClient.tools();
const baseline = await fingerprintTools(tools);
// Persist the baseline yourself: DB row, KV entry, or committed JSON.

// 2. Before each later run — refetch, re-fingerprint, diff
const current = await fingerprintTools(await mcpClient.tools());
const drift = detectToolDrift(current, baseline);

// 3. The SDK stops here. Blocking, warning, or re-prompting
//    for human approval is your application's decision.

The comments in steps one and three are the part teams miss. The SDK computes and diffs fingerprints — nothing more. It does not persist the baseline, and it does not enforce anything when drift is found. Where you store the baseline and what a drift event triggers (fail closed, alert and continue, or route to a human re-approval queue) are application decisions, and they are the decisions that determine whether this control has teeth. A drifted description is, functionally, a prompt-injection payload delivered through your tool channel — which is why we treat drift detection as the tool-gating layer in our 12-layer prompt-injection defense framework.

Version context matters here too. As we covered in our AI SDK 6 deep dive, v6’s MCP support was stable infrastructure for connecting to and calling MCP tools — but it shipped no fingerprinting or diffing utility. If you are on v6, this primitive is a reason to plan the v7 move, not something to backport by hand. Note also that mcpClient.tools() has two modes: automatic schema discovery (everything the server advertises, types inferred from server-provided schemas) or explicit developer-defined schemas per tool name for compile-time type safety. Explicit schemas are themselves a drift dampener — you consume only the tools you declared.

Here is the framing most coverage of this release misses: Vercel already shipped a fix for tool drift once. In September 2025, its mcp-to-ai-sdk tool proposed a heavier-weight answer — generate static AI SDK tool definitions from an MCP server and lock the schemas into your codebase, so the live server’s text never reaches your prompt at all. The July 2026 fingerprint utilities are the lightweight runtime alternative for teams that still want to call the live server and keep receiving its legitimate updates. These are two points on one spectrum of trust strategies, and they fit different tools.

The subtlety in the middle row is worth naming: fingerprinting flags every change, hostile or benign. A server that legitimately improves a tool description will trip the same diff a rug pull does. That is a feature, not noise — it converts silent change into an explicit re-approval event — but it means teams need a review workflow, not just an alert channel, or drift warnings will get rubber-stamped the way certificate warnings once were.

Most coverage of this feature — and of MCP security generally — undersells its boundaries. Four limits deserve plain statement.

It cannot catch a server malicious from day one. Fingerprinting pins fields at trust time. If the very first tools/list response already carries poisoned descriptions — the original tool-poisoning case Invariant Labs documented — then the poison is the baseline, and every later diff comes back clean. Drift detection only helps after a legitimate baseline exists; establishing that the baseline is legitimate requires different controls: source review, server allowlisting, reputation, and reading the tool text a human actually approves.

It detects; it does not prevent. Per the docs and release notes, the SDK computes and diffs fingerprints — it does not block a drifted tool, quarantine a server, or re-prompt anyone. An app that logs drift to a dashboard nobody watches has, in practice, no control at all. Fail-closed handling is yours to build.

It pins definitions, not behavior. The fingerprint covers description, input schema, and title. A server whose tool text stays byte-identical while its implementation changes what it does with your data will never trip the diff. Elastic’s definition explicitly includes behavior changes in the rug-pull class; definition fingerprinting addresses the description half, not the behavior half. Output monitoring and least-privilege scopes cover the rest.

Your baseline is only as safe as its storage. The SDK leaves persistence to you. A baseline stored where the attacker — or the compromised server’s SDK integration — can rewrite it is a control that can be rug-pulled itself. Treat the baseline like a lockfile: version it, review changes to it, and keep write access away from the runtime path.

Looking forward, the protocol-level gap is still open — the MCP spec itself requires no tool-definition integrity check, so every defense today lives client-side. The ETDI line of work (cryptographic signing, OAuth-scoped capabilities) sketches what a protocol-native fix could look like; until something like it lands in the specification, expect more frameworks to follow Vercel’s pattern and ship client-side pin-and-diff primitives. Our projection: within a couple of release cycles, drift detection defaulting to on — not opt-in — becomes the differentiator among agent frameworks, the way lockfiles went from novelty to table stakes in package managers.

Fingerprinting earns its keep as one layer in a deliberate stack. Here is the order we implement for client teams running MCP-backed agents in production:

• Allowlist servers before anything else. Decide which MCP servers may be connected at all, and treat additions like dependency adoption — provenance, maintainer, and a read of the actual tool text. Fingerprinting a server you should never have connected is theater.
• Vendor the crown jewels. For tools that touch payments, CRM records, or outbound email, lock definitions into the codebase mcp-to-ai-sdk-style and review regenerations in pull requests.
• Fingerprint and diff everything live. Baseline at approval, diff before every run, fail closed on drift, and route changes to a human re-approval queue with the old and new text side by side.
• Gate sensitive operations on a human. Elastic’s recommendation stands regardless of fingerprinting: require human approval for sensitive operations and avoid always-allow or auto-run settings for tools touching sensitive data or running in high-privilege environments. Fingerprinting catches the drift; approval gates cap the blast radius when something slips through.
• Use AI SDK 7’s trust boundaries. Keep app-only tools out of the model’s context entirely (they render in a sandboxed iframe and never become prompt text), and turn on HMAC-signed tool approvals so an approval cannot be forged even by injected content.
• Prefer HTTP transport in production. stdio is local-development only and cannot be deployed; HTTP is the recommended production transport in v7.

If you want the exhaustive version of this exercise, run the 75-point MCP security audit — tool-definition integrity is one family of checks among many — and pair it with our full MCP security best-practices guide for the server-side view. For teams that want this implemented rather than read about, our AI transformation engagements include exactly this kind of agent-security hardening as part of production rollout.