What Sentinel does

Sentinel is FlagThis's own prototype for catching package-squatting and "slopsquatting" — packages published on PyPI or npm under names that AI coding assistants are statistically likely to hallucinate and hand to developers as a real dependency. It watches new package publishes and scores each one automatically, so a suspicious registration can surface before it accumulates real install volume.

The engine behind Sentinel

The scanner that reads each package is SlopWatch — an open-source, zero-LLM supply-chain auditor for PyPI and npm packages and lockfiles. Sentinel runs SlopWatch against the full PyPI and npm publish streams; the code inspection, install-time execution checks, and naming-pattern models are all SlopWatch's. You can run the same engine yourself:

• Source — github.com/royans/slopwatch (Apache-2.0)
• Package — pypi.org/project/slopwatch — pip install slopwatch, then slopwatch check to audit your project's manifests and lockfiles
• In CI / pre-commit — slopwatch init wires it into a repo so a hallucinated or squatted dependency can't be committed or merged; findings carry stable SLOP-XXXX codes you can cite and suppress individually.

SlopWatch audits the dependency supply chain — the package names, lockfiles, and upstream archives your project (or your AI assistant) pulls in. It is not a code-quality or "AI-slop" linter for your own source.

How Sentinel differs from the SlopWatch CLI

The CLI answers a point-in-time question about one package: is the code in this release dangerous, and is the name a typo or hallucination of a real one? It runs offline, on any machine, with no prior knowledge — which also means each run starts cold.

Sentinel runs that same check on every new publish, and then adds a layer that only exists because it has been watching the whole registry continuously:

• Publisher reputation — from observing many thousands of publishers over time, Sentinel can both trust a package whose author is verifiably the real vendor and distrust one whose publisher can't be placed. A cold CLI run can do neither with confidence.
• Adoption trend, not a snapshot — Sentinel tracks how fast a package is being pulled in across repeated observations. Unusually quick uptake for something brand-new and thin is a signal the CLI's single download count can't see.
• Time since registration — a reliable "first seen" date that Sentinel records itself, so it can spot a name that sat dormant for months and then suddenly shipped code — a classic sleeper-squat pattern.
• Predicted-name matching — Sentinel generates the space of names an AI is likely to hallucinate before they're registered (the Brand Watchlist), so it can tell an exact match on that pattern from a coincidence, and knows which brand or capability a suspicious name is aimed at.
• Takeover watch — a sudden change of publisher or domain on an established package is flagged as a possible hijack; that needs the history Sentinel keeps.

These extra signals are being folded back into SlopWatch itself as they stabilize — Sentinel is where they get proven out first. Until then, the CLI is the portable core and Sentinel is the always-on, registry-wide view built on top of it.

Current coverage status

Live monitoring is already on: every new package published to PyPI or npm gets scored as it comes in, so the newest, highest-risk registrations — the ones this tool is actually built to catch early — are covered from day one. What's still catching up is the historical backlog: Sentinel is working through older, already-published packages to backfill scores for them, so a package's absence from the results right now can mean either "not suspicious" or "not backfilled yet," not "cleared." That backlog will keep shrinking; it doesn't affect coverage of anything published going forward.

What it looks for

Every package is scored by SlopWatch's deterministic engine — Python/JavaScript AST inspection, a pre-compiled YARA rule set, and combinatorial heuristics, with no code execution and no LLM. The signals that move a score:

• Naming pattern — whether the name matches a common AI-hallucination template (a plausible-sounding combination of framework, vendor, and capability words) or impersonates a high-value brand (Google, AWS, Stripe, Okta, …) by typo distance, token insertion, or delimiter swap. Generic tokens (safe, base, a bare google) are disambiguated so they don't false-alarm.
• Install-time code execution — whether a static scan found the package runs code on install (setup.py on PyPI, preinstall/postinstall on npm), drops a .pth startup file, abuses node-gyp, or opens a network socket / reverse shell. A dangerous call reachable during install weighs more than one only reachable if you later call into the package.
• Weaponization signatures — YARA matches for credential harvesting, exfiltration to webhooks / C2, obfuscation and sandbox-evasion, persistence, and registry-publish (worm) logic. Each rule carries a confidence rating that decides whether a hit can confirm a verdict or only raise an unverified signal.
• Near-empty codebase — a package with almost no real code is a common signature of a name registered only to hold the namespace, especially paired with a suspicious first version (a release that opens at v99.0.0).
• Publisher, adoption & timing — whether the publisher can be tied to the brand the name claims, how quickly the package is being adopted for how new and thin it is, and how long the name sat before it shipped code. These lean on Sentinel's continuous view of the registry — see how Sentinel differs from the CLI below.

The tabs

• Threat Feed — packages already registered and scored, ranked by risk. Cleared and not-yet-assessed packages are hidden by default (add verdict:benign_community to include them).
• Brand Watchlist — predictable names that aren't registered yet. If one is your project's brand, the defensive move is to register the high-risk ones yourself before an attacker does.
• Growing Packages — flagged packages ranked by download velocity since publish, to catch a sudden adoption spike.
• Taken Down — packages Sentinel flagged with a real threat verdict that PyPI or npm then removed. The verdict and score are frozen at the moment of takedown; where shown, a lead time (in hours) is how long the package stayed provably live after we flagged it.

Classification Philosophy: Risk Radar vs. Guilt

Sentinel's algorithms operate on an essential reality of software security: static analysis cannot reliably determine intent. A package that inspects environment variables and makes outbound network calls might be a data-stealing trojan, or it might be a legitimate Datadog monitoring agent or an AWS CLI helper. Because our detection heuristics are designed to maximize sensitivity against emerging zero-day threats, false positive rates are naturally elevated.

For this reason, Sentinel rejects conclusive accusations. We do not brand packages as "guilty" or definitively "malicious" without human confirmation. Instead, Sentinel acts as an early-warning Risk Radar: its objective is to triage the firehose of new open-source registrations and identify anomalous packages that require human oversight and manual source code auditing before anyone imports them.

To keep that sensitivity usable, scores are dampened where context warrants it: a per-rule confidence gate holds confirmed findings apart from unverified signal, packages from trusted vendors and established community libraries have their scores reduced, and recognised build and packaging workflows are not treated as attacks. A high score should reliably mean "a human should look," not "this is guilty."

Tag & Signal Legend

Use this reference to understand what each verdict badge, behavioral flag, and signal icon represents across Sentinel views.

Verdict Badges

Special Heuristic Tags

Signal Icons

Filtering (the q= box)

Every tab shares one filter language. Comma = OR within a field, space = AND across fields; prefix a field with - to negate.

• verdict:malicious,suspicious — malicious / suspicious / unverified_high_signal / squatted_stub / benign_community / verified_official / unknown
• ecosystem:pypi or ecosystem:npm
• hook:install / hook:network / hook:any — runs code on install
• keyword:aws,stripe (the targeted brand/entity), email:, domain:, version:
• age:<6h / age:>90d — how recently the package was published (combine two for a range)
• state:live / state:taken_down — registry liveness. The Threat Feed and Growing Packages default to state:live; the Taken Down tab is state:taken_down
• lead:>7d / lead:>30d — for taken-down packages, the days we had it flagged while it was still up
• a bare word — package-name prefix search

What it is not

Sentinel's verdicts are automated, unconfirmed signals, not adjudicated findings. A flagged package can be a false positive, or the account behind it can be compromised rather than malicious. Its coverage is intentionally narrow — a small set of heuristics across two registries, not a comprehensive detector — and every score exists to surface a candidate worth a human's attention, not to accuse anyone.

Why this exists

Modern LLMs hallucinate package and domain names deterministically, not randomly — the same model hands thousands of different developers the exact same fabricated recommendation. In one academic benchmark, 43% of hallucinated package names repeated across every one of ten identical prompt runs, and Palo Alto Networks' Unit 42 found real adversaries typically take 18 to 51 days to notice a persistent hallucination and register it. Sentinel is a narrow attempt to shrink that window from the defender's side: flag suspicious registrations early, rather than waiting to find one already sitting in a compromised dependency tree.