An AI component that passed review six months ago can turn malicious in its next release, and most teams never review it again. MITRE ATLAS added AML.T0109 AI Supply Chain Rug Pull in March 2026: adversaries publish legitimate AI components, gain adoption, then push an update with a malicious variant. Because most scrutiny happens when a dependency is first adopted, the rug pull evades it, and ATLAS places the technique in the Defense Evasion tactic (AML.TA0007). This guide covers how rug pulls work across models, datasets, packages, MCP servers and agent skills, how to detect a trusted component turning hostile, the update controls that stop it, and how to respond. It is for AI platform engineers, application security teams and anyone approving agent tools. For the OWASP view of agentic supply chain risk, see the OWASP Agentic Top 10 ASI04 Guide.
Key takeaways
- Review at adoption is not enough. ATLAS states that more scrutiny is usually applied when a dependency is first considered; a rug pull exploits every update after that.
- The documented case was one line. In the postmark-mcp case (ATLAS AML.CS0053) fifteen working versions built trust before version 1.0.16 added a blind copy of every email to an attacker address.
- Pin, then review the diff. Exact version or hash pinning turns a silent update into a change request, which is the point where a rug pull can be caught.
- AI components update in more ways than code. Model files, dataset revisions, MCP tool descriptions and skill instructions can all change behind the same name.
- Response starts with the credentials the component held. A malicious tool acts with the agent's delegated access, so rotate what it could use, not just what it touched.
How the technique works
ATLAS describes AML.T0109 in three steps: publish a legitimate AI component or software, gain user adoption, then push an update with a malicious variant, leading to AML.T0010 AI Supply Chain Compromise and, ATLAS notes, making Initial Access (AML.TA0004) more likely. The malicious variant can be delivered as any of three ATLAS resource development techniques: AML.T0058 Publish Poisoned Models, AML.T0019 Publish Poisoned Datasets, or AML.T0104 Publish Poisoned AI Agent Tool. ATLAS links the technique to AML.T0111 AI Supply Chain Reputation Inflation, which adversaries may use to build trust and adoption before the rug pull. ATLAS rates AML.T0109 as realised.
| Component | How the update arrives | What the malicious version can do |
|---|---|---|
| Package (npm, PyPI) wrapping an AI service or MCP server | Caret or tilde ranges, unpinned installs, npx or uvx fetching the latest version at start-up | Run code with the user's or agent's privileges; copy data sent through the tool |
| Remote MCP server | The operator changes server code or tool definitions; no client update needed | Change tool descriptions to inject instructions, alter results, harvest arguments |
| Agent skill or plugin | Auto-update from a marketplace or registry | Add instructions or setup commands the agent follows |
| Model on a model hub | Loading by repository name without a fixed revision | Swap in poisoned weights or unsafe serialisation |
| Dataset on a hub | Loading the latest revision for fine-tuning or retrieval | Poison training or retrieval content |
Where it shows up
- MCP servers on package registries: ATLAS case study AML.CS0053 records the postmark-mcp npm package. An unofficial package posing as Postmark's MCP server published 15 working versions, then version 1.0.16 (17 September 2025) added the attacker's address as a blind copy on every email sent through the tool. Because the server used the victim's own credentials, the copies left from the victim's account. See the postmark-mcp Malicious MCP Server 2025 breach page.
- Agent tool marketplaces: skills and plugins install with a click and often update themselves. The skills guide covers review at install time; see the Agent Skills Security Guide.
- Remote tools with changing definitions: the MCP specification lets servers notify clients that the tool list has changed (
notifications/tools/list_changed), and the MCP security best practices note that a client could end up with tools it was not aware were enabled. A definition that changes after approval is a rug pull at the protocol level. - Model and dataset hubs: loading by name gets whatever the repository holds today. See the Model Supply Chain Guide.
A related but different case is a legitimate maintainer whose account or publishing pipeline is hijacked, as in the MemTensor MemoryOS Supply Chain Attack 2026. The defences below cover both, because the consumer sees the same thing: a trusted name ships a hostile update.
Detection
| Signal | Where to see it | Why it matters |
|---|---|---|
| New version of an AI component in a lockfile or deployment | Pull requests, dependency bot output, software inventory | Every update is a review point for this technique |
| Publisher or provenance change between versions | Registry metadata, provenance attestations, signatures | A version published without the attestation earlier versions had, or from a different workflow, deserves scrutiny |
| Small diff touching network, email, credential or file access | Version diff review | The postmark-mcp change was a single added line |
| Tool definition hash differs from the approved one | MCP gateway or client logs | Catches remote servers that change behaviour without a version |
| New outbound destination from an agent or tool process | Egress proxy logs | Most rug pulls exfiltrate; a new destination after an update is the strongest runtime signal |
| Unexpected recipients, scopes or calls in downstream service logs | Email, SaaS and cloud audit logs | Postmark exposure guidance included checking email logs for hidden blind copy traffic |
D3FEND frames update-time checks as D3-SBV Service Binary Verification and D3-FA File Analysis, and runtime checks as D3-OTF Outbound Traffic Filtering and D3-NTA Network Traffic Analysis.
Prevention and hardening
- Pin exactly: lock packages to exact versions with integrity hashes (pip's hash-checking mode requires a hash for every requirement and dependency, pinned with
==), load models and datasets by commit revision rather than branch, and pin MCP servers and skills to a version. Do not start MCP servers with commands that fetch the latest release at every launch. - Delay adoption (our recommendation): hold new versions of AI components for a set period, for example seven days, before they reach production, unless they fix a security issue. Many malicious releases are found and removed within days.
- Review every update as a change: require a human to read the diff of AI tools and MCP servers before an update is merged, with extra attention to network calls, credential use and added recipients.
- Verify artifacts: ATLAS mitigations AML.M0014 Verify AI Artifacts (cryptographic checksums) and AML.M0013 Code Signing apply to each update, not just the first install. See the Model Signing and OpenSSF Model Signing Guide.
- Track components: AML.M0023 AI Bill of Materials gives you the list to check when a rug pull is reported. See the AI Supply Chain and AI-BOM Guide.
- Approve tool definitions, not just servers: record a hash of each approved tool description and schema, and block or re-approve when it changes. See the MCP Gateway and MCP Server Governance Guide.
- Limit blast radius: AML.M0028 AI Agent Tools Permissions Configuration asks for least privilege on tools. Give each MCP server its own narrowly scoped credential and an egress allowlist, so a malicious update has little to use and nowhere to send it.
- Prefer official sources: install AI tools from the service owner's own repository or registry namespace. Postmark publishes its official MCP server on GitHub, not as the npm package that was abused.
Decision guidance
| Choice | Option A | Option B | When to pick which |
|---|---|---|---|
| Local versus remote MCP server | Local package, pinned and reviewed | Remote server run by the service owner | Local gives you version control but runs code on your machines; remote removes code execution but the operator can change behaviour at any time, so definition hashing and scoped tokens matter more |
| Holding period length | Short (a few days) | Long (two weeks or more) | Short for low-privilege tools and fast-moving development; long for tools holding email, payment, code signing or production cloud credentials |
| Automatic updates | Allowed with review | Disabled, manual only | Small teams can accept bot-raised pull requests with a holding period; regulated or high-value environments should require a named approver |
| Third-party versus self-built tool | Adopt the community tool | Write a thin internal wrapper | For tools that touch sensitive data with simple APIs, a small internal wrapper you control often costs less than reviewing every upstream release |
Small organisations should start with exact pinning and per-tool credentials, which cost little. Large organisations should add a gateway that enforces approved definitions and a central AI-BOM.
Implementation
- Inventory: list every AI package, MCP server, skill, model and dataset in use, with how it is loaded and whether it is pinned.
- Pin in report mode: add exact pins and hashes, and log (without blocking) any load that is not pinned, for two weeks.
- Introduce the update gate: route updates through pull requests with diff review and a holding period; start with tools that hold credentials for email, code, cloud or payments.
- Add runtime controls: tool definition hashing at the gateway, per-server credentials and egress allowlists.
- Enforce: block unpinned loads and unapproved definition changes. Keep a documented emergency path to roll forward a security fix or roll back to the last approved version.
Measuring it
- Pinning coverage: percentage of AI components loaded by exact version, hash or commit.
- Reviewed updates: share of AI component updates merged with a recorded diff review.
- Definition drift: number of tool definition changes detected and how many were re-approved or blocked.
- Credential scope: number of MCP servers sharing a credential with another server or with the user.
Where identity fits
A rug-pulled tool does damage with the identity it was given. In postmark-mcp the stolen emails left through the victim's own Postmark account, so nothing looked foreign to the email service. Treat each AI tool as a non-human identity with an owner, a scoped credential and a review date, and record which credentials each tool can reach. When a component is reported malicious, that record is the rotation list. On the publishing side, maintainers can reduce hijack risk with short-lived publishing credentials: npm trusted publishing uses OIDC from supported CI providers instead of long-lived tokens and, for public packages from public repositories, generates provenance attestations by default.
Response
- Find every install: use the AI-BOM, lockfiles and endpoint inventory to locate the malicious version on servers, CI and developer machines.
- Stop it running: remove or disable the component, and pin back to the last known good version only after confirming that version is clean.
- Block destinations: add the exfiltration domains and addresses to egress and email blocks.
- Rotate credentials: every credential the component could use, plus secrets that passed through it (for postmark-mcp, that included secrets sent by email during the exposure).
- Check downstream logs: look for the malicious behaviour in the services the tool reached, for the full period between the update and removal.
- Report and record: report the package to the registry, and log the incident against AML.T0109. See the AI agent supply chain incidents guide.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATLAS | AML.T0109 (AML.TA0007); leads to AML.T0010; delivered by AML.T0058, AML.T0019, AML.T0104; enabled by AML.T0111 | Technique and related steps |
| MITRE ATLAS mitigations | AML.M0013, AML.M0014, AML.M0023, AML.M0028 | Signing, verification, inventory, tool least privilege |
| MITRE ATT&CK v20 | T1195.001, T1195.002 | Software supply chain compromise; see MITRE ATT&CK T1195 Supply Chain Compromise |
| OWASP | LLM03:2025 Supply Chain; Agentic Top 10 ASI04 | Supply chain risk for LLM and agent applications |
| NIST SP 800-53 Rev. 5 | SR-3, SR-4, SR-11, CM-14, SI-7 | Supply chain controls, provenance, authenticity, signed components, integrity |
| NIST CSF 2.0 | GV.SC-07, ID.AM-02, PR.PS-02 | Supplier risk monitoring, software inventory, maintenance |
Common failure patterns
- One-time approval: a security review at adoption, then automatic updates for ever.
- Launch-time fetching: MCP client configurations that fetch the latest package every time the server starts, so no lockfile ever records a change.
- Shared credentials: tools using the user's full account token, so a malicious update can do anything the user can.
- Trusting the name: installing a package because it carries a service's brand, without checking that the service publishes it.
- Removal without rotation: deleting the bad version but leaving every credential it could reach unchanged.
Practitioner checklist
- Inventory AI packages, MCP servers, skills, models and datasets, with load method and pin status.
- Pin every AI component to an exact version, hash or commit, and remove launch-time latest fetching.
- Route AI component updates through diff review and a holding period.
- Hash approved MCP tool definitions and re-approve on change.
- Give each tool its own scoped credential and egress allowlist.
- Install AI tools only from the service owner's official source.
- Keep an AI-BOM current enough to find every install within hours.
- Rehearse a rug pull response: locate, remove, block, rotate, review downstream logs.
Standards and references
- MITRE ATLAS: AI Supply Chain Rug Pull
- MITRE ATLAS: Poisoned Postmark MCP Server Email Exfiltration
- MITRE ATLAS: AI Supply Chain Compromise
- Model Context Protocol: Security Best Practices
- OWASP: LLM03:2025 Supply Chain
- pip: Secure installs
- npm Docs: Trusted publishing for npm packages
Related NHI Mgmt Group resources: MITRE ATLAS Mitigations Guide · MCP Registry and Server Publishing Security Guide · OWASP Agentic Top 10 ASI04 Guide · MITRE ATLAS AML.T0111 AI Supply Chain Reputation Inflation Guide · MITRE ATLAS Guide