Rugpull

A change in an MCP tool’s advertised behaviour after approval while agents continue using a cached definition. The server appears familiar, but its semantics have shifted, which means the identity and access decision made at approval time no longer matches the live system.

Expanded Definition

Rugpull in an NHI or agentic AI context is a post-approval semantics change: an MCP server, tool, or integration advertises one behaviour during review, then later serves different actions, parameters, or side effects while agents continue trusting the cached approval state. The identity layer has not changed, but the effective trust boundary has.

This matters because approval workflows often key on the tool name, endpoint, and a snapshot of its declared schema. If the live tool can mutate without a fresh authorization decision, the agent may keep invoking a capability that no longer matches the originally assessed risk. In practice, the term overlaps with supply-chain tampering, schema drift, and governance bypass, but no single standard governs this yet. For implementation context, see the NIST Cybersecurity Framework 2.0 and the NHI governance guidance in Ultimate Guide to NHIs.

The most common misapplication is treating tool approval as a one-time event, which occurs when teams do not revalidate tool semantics after version changes, backend swaps, or permission expansions.

Examples and Use Cases

Implementing strong anti-rugpull controls often introduces friction, requiring organisations to weigh agent agility against the cost of continuous verification and change detection.

• An MCP tool is approved for read-only ticket lookup, then later gains write access to the same backend without a new review, so agents continue to call it as if nothing changed.
• A vendor updates an API response format or hidden side effect, and the agent’s cached schema still assumes the older behavior, creating a mismatch between expected and actual action.
• A proxy layer swaps one downstream service for another after approval, causing the same endpoint to route to a more privileged or less trustworthy implementation.
• A security team uses discovery and governance practices from Ultimate Guide to NHIs to track approved tool surfaces, then pairs that with schema validation concepts from the NIST Cybersecurity Framework 2.0.
• A change-management policy requires reapproval whenever an agent-facing tool changes scope, authentication method, or downstream privilege boundary, reducing silent trust drift.

In mature environments, rugpull detection is usually tied to catalog drift, release approvals, and runtime telemetry rather than to the agent itself.

Why It Matters in NHI Security

Rugpull undermines the core assumption that authorization remains valid after approval. For NHI security, that is especially dangerous because machines act at scale, repeat decisions quickly, and often inherit trust from static metadata instead of live verification. The result can be privilege escalation, unauthorized data access, broken audit trails, and downstream automation that amplifies a single hidden change across many workflows.

NHIMG research shows that Ultimate Guide to NHIs reports 97% of NHIs carry excessive privileges, 71% are not rotated on time, and 90% of IT leaders say proper NHI management is essential to zero trust. Those conditions make semantic drift more dangerous, because a tool that changes behavior can exploit already-broad access before anyone notices. Governance teams should treat approval artifacts, tool manifests, and runtime behavior as separate security objects, not as one merged control surface.

Organisations typically encounter the impact only after a tool update, backend replacement, or incident reveals that agent actions were authorized against an obsolete definition, at which point rugpull becomes operationally unavoidable to address.