MCP Package Security Methodology
By Michael K Onyekwere
AgentScore is the public security memory for MCP packages. This page explains what the system measures, how package scores and verdicts are derived, how repo dossiers are assembled, and where the limits are.
Scope
- Scans published npm packages used in MCP ecosystems.
- Performs static metadata and published source-code checks. npm tarballs are downloaded and scanned in memory, capped at 4 MB of source for analysis.
- Extracts MCP tool definitions when present and maps them into capability categories for package reports and repo dossiers.
- Tracks change over time: scan history, advisories, repo exposure, and maintainer-response artifacts where available.
- Does not execute code, inspect runtime behavior, or observe network traffic.
- Scores are screening heuristics, not security guarantees.
Six Evidence Dimensions
AgentScore is package-first. The unit of analysis is the published artifact and the changes it undergoes over time, not a self-reported story about what the package claims to be.
Dimension 1: Published artifact and metadata
What does the package declare about itself before we read any source?
Package name, version, description, repository linkage, license, dependency count, runtime dependency names and ranges, install-script presence.
Metadata can be incomplete, misleading, or absent. A package with clean metadata can still contain dangerous source.
Dimension 2: Install-time behavior
What runs when a consumer installs the package?
preinstall, install, postinstall, and uninstall hooks. Network-touching or registry-modifying scripts are weighted more heavily than plain echo-like scripts.
Static analysis only. We do not execute install scripts or watch side effects in a sandbox.
Dimension 3: Static source patterns
Does the published source contain dangerous code patterns?
Regex-based detections for command injection, unsafe eval, hardcoded secrets, sensitive file access, suspicious URLs, and prompt-injection patterns in metadata or script content.
Regex is bounded. It can miss data flow across files and can misclassify context without mitigators. The scanner does not claim full semantic understanding.
Dimension 4: Publisher posture
How trustworthy does the publish path look?
npm provenance attestations, trusted publishing, repository linkage, and basic release hygiene.
Weak posture is not proof of malicious intent. Strong posture is not proof of safety.
Dimension 5: Tool and capability surface
What powers would an agent inherit by installing this package or repo stack?
Best-effort extraction of MCP tools from published source, manifest hashing, and mapping into capability categories such as shell execution, filesystem access, browser automation, email messaging, or network egress.
Tool extraction is best effort. If a package defines tools through patterns we do not parse, capability coverage becomes incomplete rather than magically correct.
Dimension 6: Change over time
What changed between versions, and did anyone respond?
Scan history, risk changes, advisory issuance, capability drift, repo exposure snapshots, and public maintainer-response artifacts such as issues or case studies.
History only exists after monitoring begins. Earlier versions may be absent or sparse.
Score And Risk Model
Package scans start at 100 and subtract severity-weighted finding penalties:
- CRITICAL: minus 30
- HIGH: minus 20
- MEDIUM: minus 10
- LOW: minus 5
Risk bands are then assigned from the final score:
- 85 to 100: LOW
- 70 to 84: MODERATE
- 50 to 69: ELEVATED
- 30 to 49: HIGH
- 0 to 29: CRITICAL
Verdict Logic
The Policy Gate and repo dossiers consume scan results and reduce them to a simple verdict:
- BLOCK if score is below 30
- WARN if score is below 70
- WARN if any HIGH finding remains
- WARN if publisher posture is weak across all three core signals: no provenance, no trusted publishing, and no repository
- ALLOW otherwise
Repo-specific exceptions can soften the effective verdict, but the original scanner output remains part of the audit trail.
Continuous Monitoring And Advisories
Monitoring turns one-off scans into a time series. When a watched package republishes, AgentScore stores the new scan, compares it with the prior baseline, and can publish a public advisory when score, risk, or capability surface changes materially.
That historical layer is what powers package dossiers, repo dossiers, exposure lookups, case studies, and the ecosystem research pages. The gate is downstream of that record, not a substitute for it.
Precision And Limits
The scanner is regex-based. When a finding fires near a known sanitizer wrapper or test-fixture marker, severity is downgraded by a context mitigator. Every mitigator added so far is recorded publicly at /scanner/precision.
Precision is bounded by what regex can express. A renamed sanitizer, a different parser pattern, or a multi-file data flow can still defeat detection or create a false positive. That is why the correction path is public and why the lineage page exists.
OWASP MCP Top 10 Coverage
The OWASP MCP Top 10 is a public framework for the most critical MCP-enabled system risks. AgentScore is not affiliated with the OWASP project. The table below is our own coverage map showing where the current monitoring stack has meaningful evidence and where coverage is partial.
| OWASP Risk | Coverage | How |
|---|---|---|
| MCP01: Token Mismanagement | Covered | Hardcoded-secret detection, provenance checks, publisher posture |
| MCP02: Privilege Escalation | Partial | Capability mapping and repo dossier aggregation, not full runtime privilege flow |
| MCP03: Tool Poisoning | Partial | Prompt-injection patterns in metadata plus tool extraction and manifest hashing |
| MCP04: Supply Chain Attacks | Covered | Install-script detection, dependency monitoring, exposure API, provenance posture |
| MCP05: Command Injection | Covered | Static source analysis for exec, spawn, and unsafe-eval patterns with mitigators |
| MCP06: Intent Flow Subversion | Partial | Metadata prompt-injection detection. Runtime intent hijacking is out of scope. |
| MCP07: Insufficient Auth | Partial | Trusted-publishing and posture signals, not full runtime auth review |
| MCP08: Lack of Audit | Covered | Scan history, advisories, repo inventory, and public correction lineage |
| MCP09: Shadow MCP Servers | Partial | Repo dossiers and exposure mapping surface hidden or drifted package use, not full environment discovery |
| MCP10: Context Injection | Partial | Metadata prompt-injection patterns only. Runtime context analysis remains out of scope. |
Reference: OWASP MCP Top 10. Coverage reflects the current MCP package monitoring stack, not a claim of complete MCP-system coverage.
Legacy Note
Older experimental agent-screening endpoints still exist under /api/verify*. They are not the main product frame. The center of gravity is the package-monitoring record: scans, dossiers, advisories, repo exposure, and the gate that consumes them.