Helmwart
← Atlas · Mitigations Tier 2 · Real-composable

MITIGATION · m-mcp-server-attestation

MCP server attestation — cryptographic proof of server identity and binary integrity

An MCP client connecting to a server has no built-in way to verify that the server at a given address is the expected workload or that its binary has not been replaced. An attacker who can intercept or substitute the server exploits that gap directly. MCP server attestation closes it by requiring the server to present cryptographic proof of two properties before the connection proceeds: that it holds a valid workload identity bound to a trusted certificate, and that its binary matches a signed hash recorded at build time.

Last reviewed 2026-05-14 · Status: published · Evidence →

At a glance

MATURITY
Tier 2
Available off-the-shelf or as a documented pattern, but newer or less broadly proven. Expect integration work and some operational nuance.
PLACES ON
node
Restricted to node kinds: tool-bus, external-system
COVERAGE
2 threats
T40 · T47
TRADE-OFFS
LAT
low
COST
low
UX
low
DEV
medium
Latency · cost · UX friction · dev effort.
TL;DR
  • Requires the MCP server to prove two things cryptographically before the client connects: that it holds a valid workload identity, and that its binary matches the signed hash recorded at build time.
  • Composes SPIFFE SVIDs for workload identity, Sigstore keyless signing for binary-hash attestation, and TUF for secure distribution of the trust root that the other two layers depend on.
  • The MCP specification does not mandate attestation today; the client must implement the verification at the integration layer.
  • Directly addresses T40 (MCP Client Impersonation) and T47 (Rogue MCP Server in Ecosystem), the two OWASP MAS threats that exploit the implicit trust a client places in whatever server answers a connection.

How it behaves

MCP client initiates a connection to a server endpoint.
Verify SPIFFE SVID against the trust bundle during the mTLS handshake, then call `cosign verify-blob` to compare the running binary hash against the Rekor inclusion proof.
Connection proceeds; client uses the attested server.
Connection rejected. Log the failure with the server URL and reason; do not proceed.
Fail-closed: a server that cannot produce valid attestation material is treated as a rogue server regardless of network reachability.

What it is

An MCP client connecting to a server has no native mechanism to verify that the process at the target address is the expected workload or that its binary is intact. The MCP specification does not require the server to prove either property; the client trusts whatever answers the connection. That implicit trust is the surface that T40 (MCP Client Impersonation) and T47 (Rogue MCP Server in Ecosystem) exploit.

MCP server attestation requires the server to prove two distinct properties before the connection proceeds. The first is workload identity: the server holds a SPIFFE Verifiable Identity Document (SVID), a short-lived X.509 certificate issued by a SPIRE control plane and bound to the server's workload identity. The client verifies the SVID against the SPIFFE trust bundle during the mTLS handshake. The second is binary integrity: the server binary is signed at build time using Sigstore's keyless pipeline, which produces an ephemeral signing key from an OIDC token, records the signed binary hash in the Rekor public transparency log, and outputs a bundle file containing the signature, Fulcio-issued certificate, and Rekor inclusion proof. At connection time the client calls cosign verify-blob against the running binary; a substituted binary fails the hash comparison.

A third layer closes the bootstrap gap: the SPIFFE trust bundle and the Sigstore Rekor public key are themselves distributed to clients via The Update Framework (TUF), which uses threshold signing and key-rotation guarantees to prevent an attacker from substituting the trust root that the other two layers depend on.

IETF RFC 9334 (RATS Architecture) provides the formal model for this composition: the MCP server is the Attester, the client is the Relying Party, and the attestation evidence is the SVID combined with the binary hash and Rekor proof bundle.

Detection signals

  • Attestation verification failures per connection attempt. A sustained non-zero rate indicates impersonation attempts or key and binary drift in a deployed server.
  • Connections to MCP servers that did not complete attestation. Any non-zero count is an operational gap; the expected value is zero in a fully enforced deployment.

Threats it covers

  • T40 MCP Client Impersonation −2 severity steps

    WHY IT HELPS MCP client impersonation is the threat where an attacker operates a server that passes as a legitimate one to an unsuspecting client. Cryptographic attestation makes impersonation structurally infeasible: the attacker must produce a valid SPIFFE SVID issued by the trusted SPIRE control plane and a Rekor-anchored binary hash matching the expected binary, neither of which is available without access to the signing infrastructure.

  • T47 Rogue MCP Server in Ecosystem −2 severity steps

    WHY IT HELPS Rogue MCP server substitution is the threat where an attacker replaces a legitimate server in the MCP ecosystem, either at the network layer or in a registry, so that clients resolve to the attacker-controlled binary. A client that verifies the SVID and binary hash before connecting will reject the substituted server because it cannot produce attestation material issued against the original binary.

Principle coverage

Defence-in-Depth stage: Prevent — and it advances:

  • Zero Trust Zero Trust requires that no server identity is accepted on the basis of network reachability alone. MCP server attestation enforces that principle at the connection boundary: the client makes an explicit cryptographic verification of both workload identity and binary integrity before any data is exchanged, so reaching the expected address grants nothing without valid attestation material.
  • Supply-chain Security Supply-chain integrity requires that every component in the pipeline be verifiable back to a trusted build. MCP server attestation closes the deployment-time gap by anchoring the server binary hash in the Rekor public transparency log at build time, so any substitution between build and deployment is detectable before the client connects.

Design & governance principles (open design, economy of mechanism, accountability, …) are architectural, not advanced by a single placed control.

Implementation options

Five verified implementation options covering workload identity, binary-integrity attestation, pipeline-level provenance, the formal attestation architecture, and trust-root distribution. Deploy at minimum options 1 and 2 together: they address the two distinct properties (identity and binary integrity) that attestation must prove. Option 5 closes the trust-root-substitution gap the other four leave open.

SPIFFE / SPIRE The MCP server receives a short-lived SPIFFE SVID from a SPIRE Agent via the Workload API. The client verifies the SVID against the SPIFFE trust bundle during the mTLS handshake. SPIRE is CNCF Graduated.

Why choose it: Best as the identity layer for any cloud-native or containerised MCP deployment. SPIRE automates SVID rotation and key management; the short-lived certificate limits key-compromise blast radius. Draft-klrc-aiagent-auth-00 (March 2026) formally composes SPIFFE, WIMSE, and OAuth 2.0 into an Agent Identity Management System targeting MCP workloads specifically.

More details:

Sigstore cosign sign-blob The MCP server binary is signed at CI time using Sigstore keyless signing (Fulcio CA, Rekor transparency log). The bundle file consolidates the signature, certificate, and Rekor inclusion proof. The client calls cosign verify-blob at connection time; a substituted binary fails the hash check.

Why choose it: Best as the binary-integrity layer. No long-lived signing key is required: the ephemeral key is produced per signing event from an OIDC token. The bundle file (--bundle mcp-server.sigstore.json) is a single artefact that can be published alongside the release binary and verified by any third party against the public Rekor log.

More details:

in-toto Attestation Framework Captures authenticated metadata about each step in the MCP server build pipeline (fetch, compile, package, publish) as signed link metadata. The client verifies the in-toto layout before connecting. CNCF Graduated; bindings for Go, Python, Rust, and Java.

Why choose it: Best when the threat model includes supply-chain compromise at build time, not just binary substitution at deployment. in-toto proves the binary was produced by the expected pipeline steps from the expected sources, extending binary-hash attestation upstream into the build process. Compose with Sigstore for the binary-integrity layer and in-toto for the pipeline-provenance layer.

More details:

IETF RATS RFC 9334 Defines the Attester / Verifier / Relying Party roles and the Evidence to Endorsement to Attestation Results flow. Applied to MCP: the server is the Attester, the client is the Relying Party. Informational RFC, IESG-approved, published January 2023.

Why choose it: Best as the architectural vocabulary for teams building custom attestation infrastructure or integrating with hardware-rooted attestation (TPM, TrustZone). RATS provides the formal evidence-flow model that SPIFFE and Sigstore implement informally. draft-novak-rats-twi-attestation (November 2025) extends RATS to trustworthy workload identity, directly applicable to MCP server registration.

More details:

TUF, The Update Framework Distributes SPIFFE trust bundles and Sigstore public keys to MCP clients with threshold signing, key rotation, and freshness guarantees, closing the trust-root-substitution attack vector that the other four options leave open.

Why choose it: Best as the bootstrap layer composed with any of the four options above. An attacker who can replace the Sigstore public key or the SPIFFE trust bundle breaks the attestation chain without touching the MCP server binary. TUF is a CNCF project specifically designed to prevent this class of attack for software distribution; the same pattern applies to attestation-material distribution.

More details:

Trade-offs

  • SVID verification is part of the TLS handshake and adds no measurable latency. Rekor proof verification adds a single HTTP round-trip (roughly 200 to 500 ms) performed once at connection establishment.
  • SPIFFE/SPIRE, Sigstore, in-toto, and TUF are all open-source with no licensing cost. The primary operational burden is SPIRE deployment and registration-entry management.
  • Binary signing requires CI pipeline integration. Every build that produces a deployable binary must run the cosign sign-blob step; omitting it causes the next connection-time verification to fail.
  • The MCP specification does not currently mandate attestation, so the client must implement verification proactively. Until the spec requires it, there is no ecosystem-level enforcement.

When NOT to use

  • Impractical for rapidly-iterating development environments where the server binary changes multiple times a day. Requiring a fresh Sigstore signature on every build is achievable in CI but adds Rekor round-trip overhead that disrupts the fast inner loop. Apply to production builds; accept unsigned connections in non-production with documented risk acceptance.
  • Not a useful first step for organisations without an existing SPIFFE/SPIRE deployment. The operational overhead of standing up SPIRE correctly is substantial; adopt it as part of a workload-identity programme first, not solely for MCP attestation.

Limitations

  • Attestation proves the server is the right binary at connection time. It does not verify runtime behaviour: a correctly attested server can still behave adversarially if its code is malicious. Pair with m-tool-scope to bound what the server's tools can do.
  • The MCP specification does not mandate attestation. Until it does, any MCP client that does not implement this control will connect without verifying identity or binary integrity.
  • Key compromise or trust-root substitution breaks the attestation chain without producing an obvious signal. TUF addresses the trust-root problem; SPIRE's automatic SVID renewal addresses the identity-key rotation problem.

Maturity tier reasoning

  • Tier 2 because SPIFFE/SPIRE, Sigstore, and TUF are individually production-mature (CNCF Graduated). The composition for MCP server attestation requires integrating three separate pipelines that do not yet have an MCP-specific reference implementation.
  • Expected to advance to Tier 1 once the MCP working group formalises attestation requirements and major MCP client libraries ship built-in verification support.

Last verified against upstream docs: 2026-05-30.