At organization scale · mcp-audit Academy

Security teams already run vulnerability management: collect findings from many scanners, match them to assets, assign owners, track fixes against deadlines. MCP findings belong in that same process. These features make that possible.

Shadow server sweep

Organization scale

mcp-audit shadow

What: Finds every MCP server on a machine and sorts them into approved and unapproved (shadow) using your allowlist, with a risk level for each.
Why it matters: Security teams can't protect servers they don't know exist. OWASP lists this as MCP09.

Docs: shadow-mcp.md

Fleet merge

Organization scale

mcp-audit merge --dir ./scans

What: Combines scan results from many machines into one report, with duplicates merged.
Why it matters: One view of MCP risk across a whole team or company.

Docs: fleet-scanning.md

Vulnerability-management export

Organization scale

mcp-audit push-nucleus --url … --project-id …

What: Sends findings into Nucleus Security, the same pipeline that handles findings from Qualys, Tenable and 200+ other tools.
Why it matters: MCP risk gets owners, deadlines and tracking like every other vulnerability.

Docs: nucleus-integration.md

Forensic snapshot

Organization scale

mcp-audit snapshot --sign

What: Saves a time-stamped, optionally signed record of every server and finding on a machine.
Why it matters: After an incident you can show exactly what was installed and when.

Docs: snapshot.md

SBOM export

Organization scale

mcp-audit sbom

What: Produces a standard bill of materials listing every MCP server package and its dependencies.
Why it matters: Fits the supply-chain paperwork security and compliance teams already ask for.

Docs: supply-chain.md

Managed policy report

Checks in every scan

(every scan)

What: If your company controls which MCP servers Claude Code may load, shows which of your servers that policy allows or blocks.
Why it matters: Admins and developers see the same answer to “is this server allowed here?”.

Docs: permission-rules.md

Signed advisory feed

Organization scale

mcp-audit feed verify <dir>

What: CVEs cover code bugs, not poisoned descriptions, risky combinations or malicious packages. mcp-audit publishes advisories for MCP risks as standard OSV records, signed every week.
Why it matters: Other scanners, registries and gateways can consume one shared, verifiable feed.

Docs: advisory-feed.md

Under the hood: the advisory feed's guarantees

Records are deterministic: the same finding gives byte-identical JSON on every host, with IDs derived from ecosystem, package, rule and finding class, never from paths or timestamps. Signatures are detached and computed over RFC 8785 canonical bytes, so key rotation never rewrites a record. index.json is the integrity root: it carries each record's canonical_sha256, is itself signed, and holds freshness fields; feed verify fails on expiry, rollback, a missing signature or a file absent from the index. IDs use OSV's experimental x_MCPSA- prefix until MCPSA is registered upstream.

Check yourself

1. What is a shadow MCP server?

2. Why send MCP findings to a vulnerability-management platform?

3. Why does the advisory feed matter to the wider ecosystem?