Security Model

How MCPTrust guarantees integrity and authenticity in the agent supply chain.

Threat Model

MCPTrust is designed to protect against specific supply-chain attacks targeting Model Context Protocol servers. We assume the following threats:

  • Upstream Compromise: An attacker pushes malicious code to a repository you depend on, changing tool behavior.
  • Drift: A legitimate update changes a tool's schema or description (which LLMs rely on) without review.
  • Man-in-the-Middle (Artifacts): An attacker modifies the lockfile or server definition in transit.
  • Spoofing via ID Collision: Malicious servers trying to guess host request IDs to inject fake responses. (Mitigated by ID Translation).
  • Denial of Service (OOM/Sat): Malicious servers sending unlimited data or hanging requests forever. (Mitigated by line limits and timeouts).

Adversarial Stress Testing

We don't just hope for security; we engineer it. Every commit runs through "The Gauntlet"—our internal suite of 17 adversarial test phases designed to break runtimes.

  • Timing Attacks: Servers that artificially delay bytes to exploit race conditions.
  • Schema Drift: Servers that change their tool definitions mid-session.
  • Protocol Confusion: Servers that mix JSON-RPC versions to bypass parsing logic.
  • Resource Exhaustion: Servers that attempt to OOM the proxy with infinite streams.

Additional Protections

Beyond the core threat model, MCPTrust implements depth-in-defense features often missing from standard runtimes:

  • SEC-01: Host ID size validation
  • SEC-02: CEL cost limits (DoS protection)
  • SEC-03: ID type canonicalization
  • SEC-04: Duplicate response detection
  • SSRF Protections: Blocking private IPs
  • Line Limits: 10MB NDJSON cap
  • Integrity: Checksum verification

Security Guarantees

Understand exactly what MCPTrust provides—and what it doesn't.

What it Proves
Cryptographic assurances provided by MCPTrust

Integrity

Signed lockfile tamper detection ensures files haven't changed.

Authenticity

Cryptographic proof that the lockfile was approved (signed) by the holder of the signing key.

ID Translation

Server never sees host request IDs, preventing spoofing attacks.

Fail-Closed

Unknown/duplicate responses dropped. Deny on saturation.

Runtime Enforcement

Proxy blocks all unapproved tools and resource access.

The Gauntlet

17-phase stress test suite run on every commit.

What it Doesn't
Explicit non-goals and limitations

Internal Logic

Does not verify the internal correctness of the server code (unless pinned/verified).

Sandboxing

Does not firewall tool execution side-effects (e.g., file deletion) if authorized.

Key Security

Trust depends entirely on private key management practices.

Key Management

Security relies entirely on the safety of your signing keys.

  • Private Key (private.key): Keep this offline or in a secure secrets manager (Vault, 1Password). Never commit it to git.
  • Public Key (public.key): Commit this to your repo. It is used by CI and verifiers to check signatures.

Verification Nuance

The verify command performs a purely cryptographic check of the lockfile against the signature. It does not talk to the live MCP server.

To check if the live server matches the lockfile, you must use the diff command.

Disclosure & Reporting

If you find a security vulnerability in MCPTrust itself, please do not open a public issue. Email us at security@mcptrust.dev or use ourGitHub Security Advisory form.