Threat Model
Define the attacker model and defense scope precisely.
Attacker Model: Who Are We Defending Against?
Assumptions:
- Attacker controls the package registry: Can publish malicious versions of npm packages.
- Attacker can MITM network traffic: Can intercept downloads (mitigated by HTTPS).
- Attacker does NOT have the private key: The signing key is secure.
- Attacker does NOT have access to the CI environment: GitHub Actions secrets are protected.
In-Scope Threats
| Threat | Attack Vector | Defense Mechanism |
|---|---|---|
| Supply chain drift | Server silently adds exec tool | mcptrust diff detects schema change |
| Lockfile tampering | Attacker modifies mcp-lock.json to add unauthorized tools | Ed25519 signature verification |
| Bundle corruption | Attacker modifies approval.zip in transit | Signature verification on lockfile inside bundle |
| Registry substitution | npm serves different tarball than expected | mcptrust artifact verify --deep checks SHA-256 |
| Provenance spoofing | Fake attestation claims package came from trusted CI | mcptrust artifact provenance verifies Sigstore attestation |
Out-of-Scope Threats
| Threat | Why Out of Scope | Mitigation (Outside MCPTrust) |
|---|---|---|
| Malicious implementation | We verify interface, not code | Code review, sandboxing |
| Runtime prompt injection | Agent-tool conversation is opaque | Output filtering, guardrails |
| Key compromise | Private key is assumption-secure | HSMs, key rotation, Sigstore (no keys) |
| MCP protocol exploits | Trust the protocol | Upstream MCP security |
| Compromised CI | If CI is owned, attacker can sign | RBAC, branch protection, SOC2 |
Defense-in-Depth Recommendations
MCPTrust is One Layer. Complete your security posture with:
- ✅ Use MCPTrust for supply chain verification
- ✅ Sandbox MCP servers (Docker, nsjail, Firecracker)
- ✅ Apply network policies (block outbound from servers)
- ✅ Implement output filtering on agent responses
- ✅ Monitor with SIEM (mcptrust supports JSONL logging)