North Korean Hackers Poisoned 140+ npm Packages in an AI Dev Tooling Attack. Here's What Would Have Caught It.

#security #ai #appsec #cybersecurity

The Incident

Microsoft's threat intelligence team has attributed a supply chain attack targeting the Mastra AI ecosystem to Sapphire Sleet (also tracked as BlueNoroff), a North Korean state-sponsored hacking group. The attackers compromised over 140 npm packages — not obscure, one-download throwaway packages, but packages embedded in the Mastra AI dependency graph that developers and AI coding tools actively pull.

The attack vector that makes this particularly sharp: AI-powered coding assistants. Tools like Copilot, Cursor, and similar LLM-backed IDEs don't just suggest code — they suggest, and sometimes auto-install, dependencies. If your AI assistant recommends mastra-some-utility and it's one of the 140 compromised packages, you might have malicious code running on your machine before you've finished reading the suggestion.

This is the intersection of supply chain security and AI developer tooling. It won't be the last attack designed around it.

How the Attack Worked

The summary here is deliberately limited to what Microsoft confirmed: Sapphire Sleet poisoned legitimate npm packages within the Mastra AI ecosystem to deliver malicious payloads. The targets were developers building with Mastra AI and the AI-assisted development workflows that automatically surface and consume those packages.

The precise mechanism — whether these were direct compromises of existing packages, typosquats, or dependency confusion attacks — hasn't been detailed in the public disclosure. What is confirmed: 140+ packages, a state-level actor, and a clear focus on developer machines and AI tooling pipelines.

The threat model here is not someone trick-clicking a phishing link. It's a developer typing npm install or, increasingly, an AI agent doing it for them.

The Detection Gap

Standard defenses fail here for a predictable reason: they're designed to detect known-bad, not unknown-suspicious.

npm audit only flags packages with published CVEs. A freshly poisoned package — especially one where the attacker controls the upstream source — has no CVE. It passes audit clean.

Lockfiles help, but only after the fact. If a developer installs a compromised package and commits the lockfile, the malicious version is now pinned and propagated to the whole team.

LLM-based coding assistants are the worst offenders here. They're trained to suggest packages, not validate them. When an AI assistant recommends a package by name, it has no idea whether that package exists in the registry, whether it was registered yesterday, or whether it has zero downloads outside of a coordinated campaign. It just outputs the name. The developer (or the agent) installs it.

In agentic workflows where the AI has shell access and auto-installs dependencies, there's no human in the loop to notice the package was published three days ago with no version history.

Where Sentinel Catches This

Sentinel's SlopScan integration is purpose-built for exactly this scenario. It's the sixth service in the Sentinel stack, and for Pro+ tenants it runs automatically on every scrub.

Here's what happens when an LLM response recommends a package: Sentinel extracts every package name from the content and POSTs them to SlopScan's /check/batch endpoint against live PyPI and npm registry data. The result appears in security.package_scan in the response — separate from the threat score, so a prompt that scores clean on injection can still surface a dangerous package recommendation.

For a compromised or newly-registered package with no legitimate registry presence, the risk level would come back SUSPICIOUS (package doesn't exist in registry or has near-zero trust score) or DANGEROUS (confirmed malicious or known typosquat). A DANGEROUS hit means blocked. A SUSPICIOUS hit means flagged — the package name is surfaced to the caller to decide.

In an agentic workflow where the AI has tool access and is about to run npm install, that flag is the circuit breaker.

What the Response Looks Like

Below is an illustrative example of what a Sentinel /v1/scrub response would look like if an LLM had recommended a compromised Mastra AI package. The package names are illustrative — stand-ins for the kind of packages involved in this incident:

{
  "request_id": "req_9f3a21bc4d",
  "security": {
    "action_taken": "clean",
    "threat_score": 0.03,
    "package_scan": {
      "action": "flagged",
      "hits": [
        {
          "name": "mastra-agent-tools",
          "ecosystem": "npm",
          "trust_score": 0,
          "risk": "SUSPICIOUS",
          "flags": ["not_in_registry"]
        },
        {
          "name": "mastra-memory-adapter",
          "ecosystem": "npm",
          "trust_score": 2,
          "risk": "CAUTION",
          "flags": ["new_package", "zero_downloads"]
        }
      ]
    }
  },
  "safe_payload": "Here's how to set up your Mastra agent..."
}

Note how action_taken is clean — the LLM response itself isn't a prompt injection. But package_scan.action is flagged, and the hits tell you exactly why. In a CI pipeline or an agentic tool-use loop, your code checks package_scan.action before running npm install. If it's not absent (which means all packages were SAFE), you stop and alert.

Here's the integration pattern:

import httpx

response = httpx.post(
    "https://sentinel.ircnet.us/v1/scrub",
    json={"content": llm_output, "tier": "standard"},
    headers={"X-Sentinel-Key": "sk_live_..."},
)

result = response.json()
package_scan = result["security"].get("package_scan")

if package_scan:
    action = package_scan["action"]
    if action in ("flagged", "blocked"):
        hits = package_scan["hits"]
        # halt install, alert developer, log hit
        raise PackageScanException(
            f"Package scan {action}: {[h['name'] for h in hits]}"
        )

Enable it in your tenant dashboard: Settings → Slopsquatting Protection (Pro+ and above).

Takeaway

The Mastra AI incident is a preview of how supply chain attacks will increasingly target AI development workflows specifically because those workflows lower the friction between "LLM recommends a package" and "package is running on your machine."

The actionable thing you can do today: scan LLM output for package names before you act on them. Don't assume that because the LLM sounds confident about a package name, that package is legitimate, uncompromised, or has existed longer than 48 hours.

Sentinel's SlopScan integration does this automatically on every scrub. Enable it, wire the package_scan result into your install pipeline, and treat any non-SAFE result as a hard stop.

Try Sentinel free — no credit card required for the Starter tier — at sentinel-proxy.skyblue-soft.com.