The method, in the open.

How a scan works

1. Prepare the room. A fresh home folder is filled with fake credentials, a certificate authority is created for this scan only, and an internal network is built with one other host: the sinkhole.
2. Install. The package is installed with its normal installer (npm or pip) inside the sandbox. Install scripts run and are watched like everything else.
3. Run. An MCP client starts the server, lists its tools, resources and prompts, and calls every tool with realistic arguments.
4. Observe. Runtime hooks record files opened, programs started and environment variables read. The sinkhole answers every DNS, HTTP and TLS request and writes it down.
5. Grade. Rules turn events into findings with evidence, then into a score and a letter. The room is destroyed.

Isolation

Untrusted code runs under gVisor (runsc), a user-space kernel that stands between the package and the host. In the cloud each scan gets a throwaway virtual machine with no IAM role, no public IP and no route to the internet; it is terminated after the scan, and a reaper kills any worker older than 15 minutes.

Containers also drop every Linux capability, cannot gain privileges, and are limited in memory, CPU and processes. Reports produced without gVisor are marked development only.

Bait credentials

Each scan plants new fake secrets where real ones usually live: ~/.aws/credentials, ~/.ssh/id_ed25519, a .env with GitHub and API tokens, and a few environment variables. They are unique to the scan, so if one shows up in the sinkhole, even base64, hex or split across DNS names, it is proof the server tried to steal it.

Bait values are masked in public reports.

What we observe

A benign tool that clearly declares a behavior (a weather tool calling its weather API, an SSH helper reading ~/.ssh/config) is judged in that light.

Grading

The score starts at 100. Each finding removes points: critical 100, high 35, medium 15, low 5, multiplied by the confidence of the finding. Points are counted once per category, so ten copies of the same event do not sink a server alone.

When fewer than 70% of the tools could be exercised, the report and the badge say low coverage.

Not graded

If the server could not start or listed no tools, or if the network self-test failed, HIA did not see enough to judge. Such a scan gets no letter and no score, because "no findings" would wrongly read as safe. A leaked bait secret is still an F: proof does not need a complete scan.

Rug pulls

Every scan keeps a snapshot: tool descriptions and schemas, hosts contacted, programs started, finding categories. A new version is compared with the previous one. HIA flags a suspected rug pull when a description gains instructions or hidden characters, a new flagged tool appears, a new network tool is started, or new hard proof shows up. Benign edits are listed too, quietly.

Badge

Each server has a badge that follows its latest scan. Add it to a README:

[![HIA grade](https://hia.example/data/badges/<server>.svg)](https://hia.example/report.html?id=<scan-id>)

The exact snippet for a server is on its report page. The badge only ever contains a grade from a fixed set.

Report safety

A report shows text written by the package author, who may be hostile. So the site never interprets it: every string is inserted as plain text, hidden characters appear as ⟨U+XXXX⟩, scripts only come from this site, and local paths and raw install logs are never published.

Standards

Every finding links to the OWASP Top 10 for Agentic Applications (2026), to its CWE weakness and to the part of the MCP specification it concerns. The table is static, so every link can be checked.

FAQ