Frequently asked questions

What is a "package"?

“Package” is our umbrella word for the things we scan: an MCP server, a Claude Skill, a Gemini Extension, or a Cursor Rule. We use one word because the same approach (acquire every distribution surface, scan each one independently, diff them against each other) applies to all four, even though they are built and distributed differently.

Which platforms do you cover?

Four: Claude Code, Cursor, Gemini, and generic MCP, the last covering Model Context Protocol servers usable from any MCP-capable agent. A package is listed under the platform it targets.

Coverage is not even across the four. We list what our crawlers have discovered and scanned, not everything that exists, so a thin platform page means thin discovery. It is not a verdict on what is missing. Platforms shows what is in the registry for each one.

What does the composite badge mean?

It is a convenience summary, and it is subordinate to the per-scanner verdicts. We run a suite of scanners over each package (third-party tools and our own) and show you every verdict separately. Each scanner produces its own scorecard (its own score, findings, and tool version), and those per-scanner reports are the primary view.

The composite never hides, overrides, or re-ranks a per-scanner verdict. A clean report from one tool cannot launder a critical finding from another, because both are shown on equal footing. If you do not trust a scanner, deselect it and the composite recomputes from only the tools you kept. The scorecards stay put either way. Methodology has the exact formula.

Does a clean score mean a package is safe?

No. It means the scanners we ran reported no findings on the version we scanned. That is a useful signal, and it is not a clearance.

No findings does not mean no risk. Nerlo aggregates automated scanner output; automated scanning is one layer of defence, not a substitute for review.

Every scanner has blind spots, which is why we run several and publish each verdict separately instead of averaging them into one number. Read a clean scorecard as “no findings reported.” See Scanners for what each tool actually looks for.

So much of the registry is flagged. How do I tell a real finding from noise?

This is the honest problem with running a lot of scanners, and we would rather publish it than quietly smooth it over. A finding can be a genuine vulnerability, or it can be an artefact of a documentation file, a test fixture, or a CI config that never reaches the machine you install on. Both arrive from the scanner looking identical, and a tool that flags everything is worth about as much as a tool that flags nothing.

So we adjudicate each finding and label it real, noise, or unadjudicated. The label is published with the finding's fingerprint and the basis it was decided on, so it is attributable to a specific finding rather than a summary of the whole scan. The scanner's original severity is never rewritten: a finding we call noise still carries the severity the tool filed it at, so you can disagree with our reading and still see exactly what the tool said.

The two directions are deliberately not accepted on the same terms. Real is accepted on the model's word alone, because it is the conservative direction: it leaves the finding exactly as the scanner filed it. Noise is accepted only when the model names a basis from a closed list and our own deterministic check for that basis agrees. When the check does not agree, the finding stays unadjudicated, which is not a pass: it means we did not get an answer we would stand behind. The model is never told whose package it is reading, so it cannot favour one.

Adjudication is interpretation layered on top, never a replacement. It does not move the composite score or the badge, which come from the scanners by the formula on Methodology. You can pull the whole record yourself: GET /api/v1/servers/<id>/synopsis returns every finding's verdict, the basis behind it, the scanner and rule that filed it, and the file it was found in, with no account needed.

Why not just give me one score?

Because one score would inherit one scanner's blind spots silently. If a single tool is weak in some language or attack class, or compromised outright, a single-score design carries that gap through without telling you. Showing per-scanner verdicts at one flat rank means the other scanners still see the package when one misses, and you decide which tools you trust.

There is no hierarchy between scanners and none of them can veto another. If one started hiding findings, the others would still flag them, and you would see the disagreement directly rather than have us paper over it. A single number hides exactly the disagreement that matters most.

What happens when scanners disagree?

We show the disagreement. There is no tie-break and no scanner whose verdict wins: the conflicting scorecards sit side by side at the same rank, and you read both.

The composite is the only place the verdicts get combined, and it is a summary layered on top, never a replacement. Deselect a scanner you do not trust and the composite recomputes without it; the per-scanner scorecards are unchanged.

We do adjudicate individual findings, which is a different question and does not settle this one. Deciding whether one finding is real or an artefact of a documentation file never rewrites a scanner's verdict, its severity, or its rank beside another scanner.

Do you run your own scanners, or only other people's?

Both, and we label which is which. Most of the suite is off-the-shelf tooling that we pin and run as-is. Three of the scanners are Nerlo-original: one for behavioral analysis (obfuscated decode-then-exec, dynamic eval, hardcoded exfiltration); one for install-instruction analysis, which reads READMEs and install docs that direct you to execute a bundled or fetched file; and one that acquires the package from every distribution surface and reports behaviour present in what you install but absent from the source it claims to build from.

Our own detectors get no special weight. Provenance is a label, not a rank: an off-the-shelf CVE finding and a Nerlo-original behavioral finding count exactly the same, and every scanner carries its provenance tag on Scanners.

What is an "AI decision", and can I read one?

It is a point where the system changed the registry on its own: listed a package, held one back, archived it as its score decayed, delisted it after a rug-pull, or repaired its own pipeline. What makes it a decision rather than a log line is that nobody was asked. The trigger is a scheduled job, or a scan finishing (never a person clicking approve), and the record is written in the same transaction as the change, so it is a contemporaneous account rather than one reconstructed afterwards.

Autonomy is not total, and we would rather name the limits than have you find them. A Caution badge is never published automatically: it goes to a human review queue. Disabling a scanner for longer than a day takes a person. Removal does not: delisting is automatic, and so is making it permanent when the 48-hour window expires. What takes a person is the way back in. A removed package's source is denylisted in the same transaction that delists it, and only an authenticated, audit-logged operator can lift that denylist. Lifting it buys one fresh scan and never a reinstatement: if the new evidence still confirms the rug-pull, the source goes straight back on the denylist. For publish, archive, remove and repair, a deterministic rule engine makes the call and Gemini writes the explanation; when Gemini is unavailable the explanation is generated from the rule instead, and the record says which of the two produced it. Classifying a newly-crawled candidate is the one step where a model's own judgement is the input.

Every record names its actor: ai, operator, or system, so a machine's action is distinguishable from a person's and from bookkeeping. We do not file an AI action under system to soften it. Each carries the reason recorded at the time, and the narration is asked for three things: the concrete input signals, the rule that fired, and what would have changed the outcome, so a reason usually tells you what the decision turned on and not only what it concluded. On the rule-based fallback you get the signals and the rule without the prose.

You can read them without an account. /api/v1/servers/{server_id}/history returns one package's full lifecycle: every event with its actor, its reason, and the id of the decision-log entry behind it; /api/v1/decisions/stream is a live feed of autonomous decisions as they land (from the moment you connect; it does not replay history); and /api/v1/decisions/dashboard is a rolling 24-hour count of what was published, archived, removed, and repaired. And /api/v1/decisions is the platform-wide log as one browsable, filterable table, including the decisions where our own checks refused to act.

What is not public is the operations data attached to each row. /api/v1/audit/decisions is operator-only and returns 401 to everyone else, because it carries prompt hashes, which model answered, token counts, latency and cost: operations data rather than a transparency record. Explanations a model wrote about a third party's repository are not published either; the decision itself still is. This page used to describe the whole log as public when no browsable public view existed at all, and a single request would have shown it — the table is public now, and the sentence above is the narrower claim about what still is not.

How do I verify a scan myself?

Start at Trust. We publish the scanner manifest: every scanner with its pinned version, distribution source, and the checksum or lockfile that verifies it, plus the SHA-256 digest of the image every scan executes in, and a walkthrough for checking that attestation against the live endpoint yourself.

A registry that scores other people's supply chains should show its own. That page is unauthenticated and never quota-gated, so you do not need an account to audit us.

How often is a package re-scanned?

A change-detection cycle runs every day and takes the most overdue packages first. It is capped per cycle so that it always finishes, which means the whole registry is not covered in a single day. A package near the back of the rotation waits its turn. When a check finds that a package's code moved, it goes back in the scan queue.

A score therefore reflects the last version we scanned, not whatever was published on the day the package was first listed. Every package's detail page carries its own last-scanned timestamp, and that figure is worth more than any cadence we quote. The rotation is the same for everyone: change detection and public scores are the part we never charge for.

How do I get my package listed?

Submit it to the public registry. We acquire every distribution surface we can find (git source, GitHub release assets, npm tarball, pip wheel) inside a sandbox that never executes untrusted code, scan each surface independently, and diff them, so behavior present in a published package but absent from its source shows up as a finding. You can also submit from the command line with nerlo submit — see the CLI guide.

Submission is public (see the evasion-oracle answer below): the resulting per-scanner reports and composite badge land in the registry for everyone to read. Browse shows the shape of a completed scan, and Methodology covers how the verdicts are computed.

I think a finding on my package is wrong. What do I do?

Rescan it. Scores are recomputed from scratch every time, nothing is cached, and no penalty carries over — so if the finding was real, landing the fix is the whole remedy. If you believe it is a false positive, the package page names the scanner that produced the finding and the commit it ran against, which is what you need to reproduce it and take it up with that tool.

There is no appeal or dispute process. That is a decision, not a gap: we do not edit results on request, because a score an author could argue us out of would not be worth publishing. It moves when the code moves. Reading your own package's full detail is still free.

Can I scan private or internal packages?

Not today. Every scan we run today is public: submitting a package enqueues it into the public registry, where its verdict is visible to everyone. There is no private scan available now, and it will not be self-serve when there is — see the evasion-oracle answer for why that gate is the point rather than a limitation.

Private scanning of internal MCP servers, along with self-hosted and air-gapped deployment, is on the roadmap and is not available today. We would rather say that plainly than let “contact us” imply it already works.

Is there an API?

Yes, and the public data in it is free. The anonymous API gives read access to everything the site shows: every composite score, every per-scanner score, every finding, with per-IP rate limits and no account required. That is part of the transparency promise, not a paid unlock.

There is no paid tier today, so there is nothing behind a paywall: what the anonymous API serves is what we have.

How are API keys and authentication credentials secured?

Nerlo never stores plaintext API keys in the database. When you generate a key, the raw token is emitted once to your browser or CLI session and immediately hashed using SHA-256 before storage in Cloud SQL.

Even in the event of a total database breach, stored hashes cannot be inverted into valid tokens. Listing endpoints and the dashboard display only the first eight characters (e.g. nerlo_8f3a9e...) for visual identification. A key carries the authority of the account that generated it, and keys can be revoked instantly at any time. Full details are in our public Threat Model.

What does it cost?

Reading the registry is free forever and needs no account: all composite scores, all per-scanner scores, all finding detail, the change-detection rotation, each package's AI decision history with the reason recorded at the time, and the anonymous API. We do not monetize the scan data, and we never gate it by scanner.

Nothing is paid today. We are not selling anything: there is no checkout, no paid tier, and no part of the registry behind one. Convenience and governance features — personal API keys, email notifications, date-range history, team approval tooling — are what we expect to charge for eventually, and none of them is purchasable now.

Can an attacker use Nerlo to test whether their malware gets caught?

No, and the reason survives our Enterprise roadmap.

On the public registry, submitting a package is a public act with a public result. It enqueues the package into the public registry where the verdict is visible to everyone. There is no anonymous, requester-scoped scan: an attacker who submits malware to test it has published it to a registry that flags it, which is the opposite of a useful evasion oracle.

Private scanning for internal repositories is an Enterprise capability and is not available self-serve. It does not reopen the oracle, because it is restricted to repositories the customer has demonstrated they control, under a contract with an identified counterparty. An attacker cannot iterate an arbitrary payload against it; they would have to prove ownership of the repository holding that payload and do so under their own legal identity. Attribution is what makes an oracle worthless, and private scanning is gated on attribution rather than on secrecy.

In both modes, output is verdicts and findings only. We never publish a machine-readable map of which rules fired or missed, so there is nothing to grind against to reverse-engineer the detectors.

Do you track me?

No. This site loads no third-party trackers, no CDN-hosted fonts, and no cookie-setting widgets. The only cookies are the httpOnly session tokens set when you sign in, never marketing or analytics cookies. Privacy here is enforced structurally rather than promised.

The web frontend is a thin session-holder, not a data plane. It has no database access, no secret access, and exactly one outbound path (the API, over HTTPS) with every response validated against a schema. Even if the web tier were compromised, it cannot reach the database or read secrets; the blast radius is bounded by the API's own authorization checks. Privacy covers data handling in full.