Blocked package policy

What mcp-scan saw

The scanner resolved a package name from the server's npx or npm args (the first argument that does not start with a dash) and compared it, plus the server's config key, against the blockedPackages array in .mcp-scan.json. The comparison is exact string equality on the raw argument, with no version stripping and no wildcards.

Why it fires

This is your own policy file firing, not a threat detection. It runs after every scanner so a package your team banned is still reported when all other checks come back clean. It is pushed at CRITICAL so mcp-scan ci exits non-zero and the pipeline stops.

When this is a false positive

• The ban targeted one bad release, but matching ignores versions entirely, so a patched version in the same package name still trips it.
• blockedPackages holds an npm package name and your server's config key happens to be the same string. The key is checked independently of the package, so an unrelated local server gets flagged.
• You copied .mcp-scan.json from another repo where the entry existed for licensing or vendor reasons, not security, and it is now blocking a package this project is allowed to use.

How to fix it

1. Open .mcp-scan.json at the repo root and read the blockedPackages array. The finding text names the exact string that matched.
2. If the ban is still correct, remove the server from the client config or replace it with the approved alternative.
3. If the ban is stale, delete the entry from blockedPackages and commit the change so the whole team picks it up.
4. If you only ever wanted to ban one version, note that this rule cannot express that. Pin the safe version in your args and drop the blockedPackages entry.
5. To keep the ban but stop it failing CI, add 'blocked-package-policy' to suppressRules in .mcp-scan.json, or add it to .mcp-scan-ignore to downgrade it to INFO with a [SUPPRESSED] prefix.