EVIDENCE TRAIL
MCP server attestation
Verbatim excerpts from the upstream sources cited on the mitigation page, with what each source does and does not prove. The primary threat upstream is T47 (Rogue MCP Server in Ecosystem) from OWASP MAESTRO v1.0; the attestation architecture (SPIFFE + Sigstore + TUF) is Helmwart's composition of three independently-standardised primitives. The IETF RATS Architecture (RFC 9334) provides the formal vocabulary for the attester / relying-party model.
Last cross-checked against upstream sources: · 7 sources
References
Each entry shows what the source supports and what it does not prove.
OWASP MAESTRO — Multi-Agentic System Threat Modeling v1.0
§5 "Threat Modeling Anthropic MCP Protocol using MAESTRO Framework" — T40 MCP Client Impersonation, Layer 6 (Agent Identity Management)
"Identity Management (T40 - MCP Client Impersonation): An attacker impersonates a legitimate MCP client to gain unauthorized access to an MCP server and its resources. This could involve stealing client credentials or exploiting vulnerabilities in the client authentication mechanism."
Supports: Names T40 as an identity-management threat against MCP, establishing that server-side identity verification is a first-class control in this threat model. The control inverts the attack surface: attestation prevents a rogue server from exploiting a client that lacks a means to verify identity.
Does not prove: T40 describes client impersonation of a server, not rogue-server substitution. Helmwart applies server attestation symmetrically to address both directions; T40 alone does not cover T47.
OWASP MAESTRO — Multi-Agentic System Threat Modeling v1.0
§5 "Threat Modeling Anthropic MCP Protocol using MAESTRO Framework" — T47 Rogue MCP Server in Ecosystem, Layer 7 (Agent Ecosystem)
"Agent Identity Management (T47 - Rogue MCP Server in Ecosystem): An attacker deploys a malicious MCP server that masquerades as a legitimate server, providing seemingly valid but actually harmful services or data. Agents connecting to this rogue server are then compromised. This is an ecosystem-level attack targeting the trust model of MCP."
Supports: Primary upstream threat this control addresses. Verbatim names rogue-server substitution as an ecosystem-level identity attack. Cryptographic attestation is the structural countermeasure: a client that verifies the server's signed identity and binary hash before connecting will reject a rogue server that cannot produce a valid attestation.
Does not prove: Does not specify which attestation primitive (SPIFFE, Sigstore, TUF) to use; the protocol is not mandated. The MDX's composition of three primitives is Helmwart's design, not MAESTRO's.
IETF RFC 9334 — Remote ATtestation procedureS (RATS) Architecture
§1 Introduction — core definition of remote attestation procedures
"In remote attestation procedures, one peer (the "Attester") produces believable information about itself ("Evidence") to enable a remote peer (the "Relying Party") to decide whether or not to consider that Attester a trustworthy peer."
Supports: Provides the formal vocabulary the MDX uses: MCP server as Attester, MCP client as Relying Party, attestation evidence as the SVID + binary hash + Rekor proof bundle. Establishes that the Relying Party's trust decision is evidence-driven rather than network-address-based.
Does not prove: RFC 9334 is a general architecture for remote attestation; it does not address MCP specifically, nor does it mandate SPIFFE, Sigstore, or TUF as implementation choices.
MITRE ATLAS AML.M0014 — Verify AI Artifacts
AML.M0014 description — from ATLAS.yaml dist
"Verify the cryptographic checksum of all AI artifacts to verify that the file was not modified by an attacker."
Supports: Direct upstream mandate for binary-integrity verification via cryptographic checksum — exactly the property Sigstore's cosign sign-blob and Rekor inclusion proof establish for the MCP server binary. Technique AML.T0011.000 use: "Introduce proper checking of signatures to ensure that unsafe AI artifacts will not be executed in the system."
Does not prove: Scoped to AI artifacts (models, datasets); does not specifically address MCP server binaries or workload identity. Helmwart extends the pattern to server-binary attestation at connection time.
MITRE ATLAS AML.M0023 — AI Bill of Materials
AML.M0023 description — from ATLAS.yaml dist
"An AI Bill of Materials (AI BOM) contains a full listing of artifacts and resources that were used in building the AI. The AI BOM can help mitigate supply chain risks and enable rapid response to reported vulnerabilities."
Supports: Establishes supply-chain provenance as a canonical ATLAS mitigation. Sigstore's Rekor transparency log and the cosign signature bundle are the implementation of BOM provenance for the MCP server binary: they record what was signed, by whom, and when — providing the audit trail AML.M0023 describes.
Does not prove: AML.M0023 focuses on training-time artifact provenance; it does not address runtime attestation at connection time. The connection-time verification step is Helmwart's extension.
Sigstore — Rekor Transparency Log
Rekor overview — core description of purpose and guarantee
"Rekor provides an immutable, tamper-resistant ledger of metadata generated within a software project's supply chain. Rekor fulfils the signature transparency role of Sigstore's software signing infrastructure."
Supports: Names the exact guarantee this control relies on: an immutable, tamper-resistant ledger that records binary signatures. The append-only property means a substituted binary — one not signed at build time — cannot retroactively produce a valid Rekor inclusion proof. This is the structural basis for "binary has not been tampered with since signing."
Does not prove: Rekor records that a signature was made; it does not independently verify that the running server process matches the signed binary. The client must perform the hash comparison step described in the MDX.
The Update Framework (TUF) Specification
TUF Specification §2.3 (PKI Goals) — independence of trust root from external PKI
"The root of trust must not rely on external PKI. That is, no authority will be derived from keys outside of the framework."
Supports: Establishes why TUF is used for distributing the attestation trust root (SPIFFE trust bundle + Sigstore Rekor public key): TUF's design explicitly decouples its trust root from external PKI, making it resilient against CA compromise. §1.5 additionally mandates threshold/quorum signing: "must support roles with multiple keys and threshold/quorum trust to minimize key compromise impact."
Does not prove: TUF is a distribution framework; it does not provide workload identity (that is SPIFFE's role) or binary signing (that is Sigstore's role). The MDX is correct to describe TUF as the trust-root distribution layer, not the attestation layer itself.