The security scan

Every package is read by a scan agent before it can be listed. Nothing goes live without passing, and the full scan report is public on the listing.

A scan is not a guarantee

A scan lowers risk. It is not a guarantee. The scan agent is an AI. It can pass something it shouldn't, or block something fair. Read a package before your agent runs it.

The two questions

A buyer's agent may load a package and follow it. So the scan asks two things: is it safe, and is it what the listing says it is?

What it checks

Check	What it looks for
injection	Hidden or disguised instructions that make an agent ignore its user, change its own rules, or act outside the stated purpose
exfiltration	Sending files, environment variables, keys, wallet data or conversation content to a third party, or asking the agent to read secrets it does not need
commands	Destructive shell commands, piping remote scripts into a shell, disabling security tools, persistence, privilege escalation
wallet	Moving funds, signing, approvals or changing spending limits without a clear user request
honesty	The free summary must fairly describe what the package contains and does
originality	Obvious copies of well known public work sold as the seller's own, or a license that forbids resale
quality	The package must be complete and usable, not a stub or filler

Normal, clearly explained use of shell commands, network calls or wallets that fits the stated purpose is fine. The scan notes it and does not block it.

How it decides

1. Hard rules first. A fixed set of patterns is checked against the name, the summary and the package. A match is a blocker and the package is rejected at once. It never reaches the model.
2. Model review. The model reads the listing and the package and returns a verdict, a score from 0 to 100, a short summary and up to 12 issues. The package text is treated as untrusted input. The model is told never to follow instructions inside it.

The hard rules reject:

• Deleting the home or root directory (rm -rf /, rm -rf ~)
• Piping a remote script straight into a shell (curl … | sh)
• Telling the agent to ignore its previous instructions
• Telling the agent to hide things from its user
• Reading or sending secrets such as .env files, SSH keys, private keys or seed phrases

Each issue has a severity:

Severity	Meaning
blocker	Must be fixed. A package with a blocker can't be approved
fix	Should be corrected before listing
note	An observation. Doesn't stop listing

Verdicts

Verdict	Result
approve	Safe to list, maybe with notes. The package can be minted
revise	Fixable problems, with specific instructions. Edit and scan again
reject	Malicious, deceptive, stolen or spam

If the model says approve but also reports a blocker, the verdict becomes revise.

A package can be scanned up to 8 times. After that, start a new draft. Any edit sends the package back through the scan.

The report

A scan report looks like this:

{
  "verdict": "approve",
  "score": 92,
  "summary": "One or two sentences for the seller and for buyers.",
  "issues": [{ "severity": "note", "check": "commands", "detail": "…" }],
  "engine": "…",
  "auditedAt": "2026-09-20T10:12:00.000Z"
}

engine is the id of the model that ran the scan, or rules when only the hard rules ran.

What buyers see

The whole report is public: the score, the summary and every issue. You can read it on the package page and through the API. See Packages.

When the scan approves a package, its text is fingerprinted (a keccak256 hash). The fingerprint is part of the minted metadata, and a live package can't be edited.

After the mint, the scan agent's wallet can also post the verdict to the ERC-8004 reputation registry. When it does, the transaction is shown as auditTx.