MCP Attestation Methodology

What the attestation covers

Five deterministic checks run against a single commit SHA. Each check is independently reproducible — anyone can re-run it from the same source and should produce the same evidence bytes. The checks are:

1. 1. dependency-security

   Static security scan of the resolved dependency tree against pinned versions. Surfaces known-vulnerable packages, license-incompatible dependencies, and packages flagged by the standard advisory databases. Fails closed on any critical advisory.

2. 2. sbom-presence

   Confirms a Software Bill of Materials is present and parseable (CycloneDX or SPDX), and that it accurately reflects the resolved dependency tree. An SBOM is the precondition for any later supply-chain provenance work.

3. 3. signed-tag

   If the attested commit corresponds to a published release, checks for a cryptographically signed git tag and/or sigstore provenance metadata. Absence is not failure — many maintainers don't sign tags — but presence is recorded as positive evidence.

4. 4. mcp-protocol-conformance

   The server's manifest resolves, the server starts in an isolated sandbox, the tools it advertises are enumerable via the standard MCP discovery flow, and the tool signatures (parameter schemas) match the last attested version. Signature drift across versions is recorded.

5. 5. known-cve

   Cross-references the dependency tree against the public CVE database (NVD + GHSA) at attestation time. The result is a snapshot — new CVEs disclosed after the attestation timestamp do not retroactively invalidate it but do trigger a delta record on the next attestation.

What the attestation explicitly does NOT cover

This list is as load-bearing as the in-scope list. If you read a Delimit attestation as proof of any item below, you have read it incorrectly.

• Absence of vulnerabilities

  A clean known-CVE check at time T does not mean no vulnerabilities exist. It means none were disclosed against the dependency tree at time T.

• Trustworthiness of the maintainer

  Attestations sign evidence about code, not about people. A maintainer can produce clean attestations and later act maliciously.

• Safety of MCP tool side-effects

  A tool that exposes file-system writes, shell access, or network egress will pass these checks if it is structurally sound. The blast radius of what an MCP tool can do is the operator's responsibility, not ours.

• Security of operator-supplied secrets

  How an operator wires API keys or credentials into the server is outside the attestation perimeter.

• Future versions of the server

  An attestation pins to one commit SHA. The next commit can change tool signatures, add network calls, or introduce vulnerabilities. Re-attestation is required.

• Runtime behavior outside the sandbox

  Conformance is verified in an isolated environment with a fixed set of test tool calls. Production runtime may differ.

• License / IP / legal review

  We record license identifiers from the SBOM but make no claim about license compatibility with your use case. Consult a lawyer.

Reproducibility

Every Delimit attestation is signed by Delimit's key. The underlying evidence is independently reproducible — you can re-run the same checks against the same commit and verify the same bytes come out. The signature certifies we ran the checks, not that the checks themselves are infallible.

The replay UI at delimit.ai/att/<id> displays the full bundle, the canonical hash, and a verify-locally code block. If you re-run the same checks at the same commit and get different bytes, that is a finding worth reporting.

Versioning

This is methodology v1, frozen as of 2026-04-30. v1 is immutable; future revisions will ship as v2 (additive checks) or v1.x (clarifications without semantic change). A v1 attestation will always be replayable against the v1 methodology in perpetuity.

New attestation surfaces (per-PR review attestations, per-release attestations) will publish their own methodology documents under delimit.ai/methodology/. The attestation primitive is shared; the claims and checks differ per artifact class.