Stars, downloads, forks and a long-standing developer account are exactly the signals teams use to decide which AI model, package or MCP server to trust, and they are the signals adversaries now manufacture. MITRE ATLAS added AML.T0111 AI Supply Chain Reputation Inflation in March 2026, in the Defense Evasion tactic (AML.TA0007). ATLAS describes it as building or leveraging genuinely credible-looking trust signals to increase the perceived legitimacy of AI supply chain components, so that malicious or compromised assets are adopted. This guide explains which trust signals can be inflated and which are harder to fake, how to spot inflation, how to build an adoption process that does not depend on popularity, and how to respond when a popular component turns out to be hostile. It is for engineers choosing AI components, platform teams running internal registries, and security teams approving agent tools. The broader ATLAS context is in the MITRE ATLAS Guide.
Key takeaways
- Popularity is not provenance. ATLAS names downloads, GitHub stars, forks and inclusion in dependency chains as the reputation signals adversaries build, so none of them should approve a component on their own.
- Some signals are real but borrowed. ATLAS notes adversaries use established developer accounts with a history of legitimate projects, which pass both human and automated checks.
- Inflation sets up the rug pull. ATLAS links AML.T0111 to AML.T0109 AI Supply Chain Rug Pull: benign versions first, malicious updates later.
- Prefer signals tied to identity and process. Who publishes (the service owner or not), how releases are built (provenance attestations, signed releases) and how the project is run (code review, multiple maintainers) are harder to inflate.
- Agent tool marketplaces are the newest target. ATLAS case study AML.CS0049 recorded 16 users downloading and running a poisoned agent skill within eight hours of publication.
How the technique works
ATLAS rates AML.T0111 as demonstrated. It covers AI models, datasets, packages and MCP servers. The adversary does not need to fake anything outright: ATLAS stresses that relying on authentic history and usage patterns is what lets these components pass checks. Reputation can be built slowly with real use, bought, or borrowed from an account that already has it.
| Trust signal | How it is inflated | How much weight to give it |
|---|---|---|
| Stars and likes | Purchased or coordinated starring; research found fake-star campaigns grew rapidly in 2024 | Very low |
| Download counts | Scripted installs, CI loops, mirrors, or genuine adoption of benign early versions | Low |
| Forks and dependents | Forks from throwaway accounts; inclusion in small packages the adversary also controls | Low |
| Account age and history | Aged accounts, purchased accounts, or a genuine developer account taken over | Low to medium; ATLAS specifically names established accounts |
| Marketplace ranking or "trending" placement | Driven by the same inflated counts | Very low |
| Publisher is the service owner (verified organisation or namespace) | Look-alike organisations and names | High once verified against the owner's own documentation |
| Build provenance and signatures | Hard to fake; can be absent | High when present and matching the expected repository and workflow |
| Process signals (code review, branch protection, maintainers from more than one organisation) | Possible but costly to simulate | Medium |
The research by He and colleagues on suspected fake GitHub stars (StarScout, arXiv 2412.13459) found that most fake stars promote short-lived phishing and malware repositories, and that AI and LLM repositories were among the other promoted categories. It also found the visibility gain lasted less than about two months, which matters for detection: inflation tends to come in bursts.
Where it shows up
- Agent skill registries: ATLAS case study AML.CS0049 describes a researcher's proof of concept on ClawdHub, a skill registry for agents, where a poisoned skill was downloaded and run by 16 users in its first eight hours. In the later ClawHub Malicious Skills 2026 campaign, one publisher's skills reportedly reached almost 7,000 downloads, and publishing required only a GitHub account at least a week old. See the Agent Skills Security Guide.
- MCP servers on package registries: postmark-mcp built adoption over 15 legitimate versions before turning malicious, which is the reputation-then-rug-pull pattern ATLAS describes. See the postmark-mcp Malicious MCP Server 2025 breach page.
- Model hubs: look-alike organisations borrow the reputation of real companies; ATLAS case study AML.CS0027 shows employees joining an impersonated Hugging Face organisation. See the Hugging Face Security Guide.
- AI-generated recommendations: coding assistants and AI search suggest packages partly on popularity, which turns inflated signals into installs. See the Slopsquatting and Package Hallucination Guide.
Detection
Detection of inflation happens before adoption (is this reputation real?) and after (has a trusted component changed?).
| Indicator | What to check |
|---|---|
| Star or download bursts | Sudden jumps not matched by issues, discussions or dependent projects; the StarScout research found fake-star accounts and repositories show very trivial activity patterns |
| Stargazer and contributor quality | Many new or empty accounts among stargazers; contributors who only touch this project |
| Publisher mismatch | The component carries a company's name but the company's own documentation points to a different repository or namespace |
| Provenance gaps | No build attestation, or attestation from a repository or workflow other than the one advertised |
| Account takeover signs | A dormant, well-known account suddenly publishing AI tools, new maintainers added shortly before a release, changed contact email |
| Behaviour change after popularity | New network destinations, credential access or setup commands appearing in a version released after adoption grew |
For components already in use, the runtime checks in the rug pull guide apply: diff review of updates, tool definition hashing and egress monitoring. Internal registries can also watch for their own inflation: a component that many teams adopt in a short period, driven by one recommendation, deserves a review.
Prevention and hardening
- Write an adoption policy that ignores popularity: approve AI components on publisher identity, provenance, process and review, and record stars or downloads only as context.
- Verify the publisher against the owner: for any component named after a service, confirm in the service owner's own documentation which repository, namespace or registry entry is official.
- Check provenance where it exists: npm trusted publishing generates provenance attestations by default for public packages built from public repositories on supported CI. Check that the attestation names the expected repository.
- Use OpenSSF Scorecard as a process signal: Scorecard runs automated checks scored 0 to 10, including Maintained (at least 90 days old and maintained), Code-Review, Signed-Releases, Pinned-Dependencies and Contributors (contributors from at least two organisations). Use the checks as evidence of process, not as a pass mark.
- Run an internal registry: mirror approved models, packages, MCP servers and skills internally, so developers and agents choose from a reviewed set rather than a public ranking. See the MCP Registry and Server Publishing Security Guide.
- Apply ATLAS mitigations to every component: AML.M0014 Verify AI Artifacts, AML.M0013 Code Signing and AML.M0023 AI Bill of Materials make the decision traceable.
- Constrain agents choosing tools: do not let agents install skills or MCP servers from public marketplaces on their own; ATLAS mitigation AML.M0029 Human In-the-Loop for AI Agent Actions applies to installs.
Decision guidance
Not every component deserves the same scrutiny. Weigh the evidence against what the component can do once installed.
| Component holds or touches | Minimum evidence before adoption (our recommendation) | If evidence is missing |
|---|---|---|
| Nothing sensitive (offline utility, public data only) | Publisher checked, version pinned | Allow with monitoring |
| Read access to internal data | Publisher verified, process signals reviewed, code read for network calls | Run in a sandbox with no egress, or build an internal wrapper |
| Write access, email, code repositories, payments or production cloud | Service owner as publisher or full code review, provenance present, scoped credential, egress allowlist | Do not adopt; request the capability from the service owner or build it internally |
| Model weights or training data used in production decisions | Verified organisation, pinned revision, checksum verified, scanned for unsafe serialisation | Use only in isolated evaluation |
Small teams can apply this table by hand during code review. Larger organisations should encode it in the internal registry, so tier and evidence travel with the component and are visible to every team that installs it.
Implementation
- Baseline: list the AI components in use and record, for each, the publisher, whether it is the service owner, whether provenance exists, and the Scorecard result where available.
- Define tiers (our recommendation): Tier 1, published by the service owner with provenance; Tier 2, community component with good process signals and a completed code review; Tier 3, everything else, not allowed for tools holding credentials.
- Stand up the internal registry: start with MCP servers and skills, which hold the most delegated access, then packages and models.
- Enforce at install: block installs from public marketplaces on managed machines and agent platforms, with an exception route through review.
- Re-score on change: re-run the tier check when the publisher, maintainers or provenance change, not only on a calendar.
Measuring it
- Tier coverage: share of AI components in production that are Tier 1 or Tier 2.
- Registry use: share of installs served from the internal registry rather than public sources.
- Publisher verification: number of components named after a service that have been checked against the service owner's documentation.
- Exceptions: number and age of open exceptions for Tier 3 components.
Where identity fits
Reputation inflation is an attack on publisher identity. ATLAS highlights established developer accounts because a real history is the most convincing signal, and a taken-over account carries that history with it. On the consumer side, treat publisher identity like any other identity claim: verify it against an authoritative source (the service owner's documentation, a verified organisation, a signed attestation) rather than accepting a name. On the producer side, protect your own publishing identities with phishing-resistant multi-factor authentication and short-lived, CI-bound publishing credentials, so your reputation cannot be borrowed. Every approved AI tool should also be registered as a non-human identity with an owner and scoped credentials. See the MCP Server Trust Assessment guide.
Response
- Confirm the component and versions: identify which versions are malicious and when they were published.
- Find installs: search the AI-BOM, lockfiles, agent configurations and endpoints.
- Remove and block: remove the component, block the publisher in your internal registry, and block any exfiltration destinations.
- Rotate: every credential the component's host or agent could read.
- Review the decision trail: record which signals led to adoption, and adjust the policy if popularity carried weight it should not have.
- Report: report the component and the inflating accounts to the registry or marketplace, and record the incident against AML.T0111 and, if a malicious update followed, AML.T0109.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATLAS | AML.T0111 (AML.TA0007); related AML.T0109, AML.T0010 | Technique and the rug pull it enables |
| MITRE ATLAS mitigations | AML.M0013, AML.M0014, AML.M0023, AML.M0029 | Signing, verification, inventory, human approval of installs |
| MITRE ATT&CK v20 | T1195.001 | Compromise of software dependencies and development tools |
| OWASP | LLM03:2025 Supply Chain; Agentic Top 10 ASI04 | Supply chain risk for LLM and agent applications |
| NIST SP 800-53 Rev. 5 | SR-6, SR-4, SR-11, SA-9 | Supplier assessment, provenance, authenticity, external services |
| NIST CSF 2.0 | GV.SC-05, GV.SC-07, ID.AM-02 | Supplier requirements and monitoring, software inventory |
Common failure patterns
- Star thresholds as policy: "over 1,000 stars" written into an approval checklist, which is the exact signal being inflated.
- Brand trust: assuming a package named after a company is published by that company.
- Checking once: verifying a publisher at adoption and never noticing a maintainer change or takeover.
- Letting agents shop: agents or assistants allowed to install the top-ranked skill or server for a task without review.
- No internal source: every team picks from public rankings independently, so one inflated component spreads across the organisation.
Practitioner checklist
- Remove popularity thresholds from AI component approval criteria.
- Verify every service-named component against the service owner's own documentation.
- Record provenance and Scorecard evidence for each approved component.
- Define trust tiers and keep credential-holding tools to the top tiers.
- Serve approved AI components from an internal registry.
- Block unreviewed installs of skills and MCP servers by people and agents.
- Re-review components when publishers, maintainers or provenance change.
- Protect your own publishing accounts with phishing-resistant MFA and CI-bound publishing.
Standards and references
- MITRE ATLAS: AI Supply Chain Reputation Inflation
- MITRE ATLAS: AI Supply Chain Rug Pull
- MITRE ATLAS: Supply Chain Compromise via Poisoned ClawdBot Skill
- OpenSSF: Scorecard
- npm Docs: Trusted publishing for npm packages
- arXiv: Six Million (Suspected) Fake Stars in GitHub
- OWASP: LLM03:2025 Supply Chain
Related NHI Mgmt Group resources: OWASP Agentic Top 10 ASI04 Guide · AI Supply Chain and AI-BOM Guide · Malicious Package and Dependency Confusion Guide · MITRE ATLAS AML.T0109 AI Supply Chain Rug Pull Guide · MITRE ATLAS Guide