If your store publishes an ARD manifest, the trustManifest.attestations field can now be read two ways, and the spec says they are not interchangeable. A compliance certificate describes your company. A scan result describes one specific artifact. Agents and registries are told to treat them that way.

What changed

On 2026-10-11 the Agentic Resource Discovery (ARD) spec repository merged pull request #80. The merge message calls it an “editorial clarification and conformance example only (non-normative spec change)”. It adds one paragraph to section 4.5.2 of the spec and a worked example.

The paragraph lists five scopes an attestation can carry:

  • Organizational compliance, for example SOC2-Type2 or HIPAA-Audit.
  • Artifact security scans, for example SARIF analysis of the artifact’s content.
  • Build provenance and SBOMs, for example SLSA or in-toto DSSE.
  • Transparency-log receipts, for example SCITT registrations.
  • Runtime evaluations.

The rule that matters

The spec text says an organizational compliance attestation “applies to the publisher’s control environment rather than the safety of a specific artifact”. Artifact-scoped attestations, such as scans or build provenance, “should identify the evaluated artifact by cryptographic digest inside the referenced attestation document so the claim cannot be reattached to a modified artifact” (spec/ard.md, section 4.5.2).

The example in the repository makes it concrete. One entry carries a SOC2-Type2 PDF and a SARIF scan file side by side. Its README says the SOC 2 certificate “does not make a claim about the artifact itself” and that the same certificate could appear unchanged on every entry the publisher lists (scan-attestation example).

A detail that is easy to get wrong

The digest field on an attestation item covers the attestation document itself, not the scanned artifact. The link to the scanned artifact sits inside the SARIF file, under runs[].artifacts[].hashes. The README also notes that a scan is “bounded by its ruleset and scanner”, so a consumer should read the scope rather than treat an attestation as a blanket safety verdict.

What this means for a store

The example describes an MCP server entry, not a shop. The spec says nothing about merchants specifically, and it does not say which registries verify attestations today. The reading below is ours:

  • Claim only what the document proves. If you list a compliance certificate, expect it to be read as a statement about your organization.
  • If you attach a scan or audit result about a page, feed or endpoint, make sure the file names what was evaluated and when. A result that cannot be tied to the current artifact is the “reattached” claim the spec warns about.
  • Treat the manifest as a hook, not a badge. The spec says relevance scores from search “MUST NOT be interpreted as a trust, compliance, or safety judgment”.

The same scope question applies to any readiness score, including ours: a number describes what was measured, on a date, against a ruleset.

FAQ

Does an ARD attestation prove my store is safe?

No. ARD says an organizational compliance attestation applies to the publisher’s control environment, not to the safety of one artifact. A scan attestation is bounded by the ruleset and scanner named in the referenced scan document.

What does the digest field in an ARD attestation cover?

It covers the referenced attestation document itself. The binding to the scanned artifact lives inside that document, for a SARIF scan under runs[].artifacts[].hashes, so a changed artifact no longer matches.

Is this a new requirement for merchants?

No. The merged change is described as editorial and non-normative, and ARD v0.91 is still marked Proposal. It clarifies how attestations should be read, without adding a new mandatory field.

Sources

For the path change in the same spec, see ai-catalog.json is now ard.json. A trust claim only helps if the transaction behind it works, which is the part AgentReady audits.