Part 2: The Model and the Toolset Are Artifacts Too

Pull an agent’s container image and you can check its signature against a maturing standard. Pull its weights and, increasingly, you can do the same. Pull the tool definition that tells it what it’s allowed to call, and today there is nothing to check at all.

That asymmetry, not a blanket absence of AI provenance, is Part 2’s actual subject.

Three artifact classes, one asymmetry#

What an agent does is shaped by three things it depends on: the container it runs in, the weights it reasons with, and the tools it’s permitted to call — the three dependencies that ship as digest-addressed OCI artifacts, not the complete behavioural picture. Part 1 showed that OCI already has a mechanism — the subject field plus the Referrers API — for attaching a signature, SBOM, or attestation to any digest-addressed artifact without touching it. That mechanism doesn’t care what the artifact is. Whether it actually gets used is a per-artifact-class question, and the answer currently splits two-for-one.

The container has the oldest, deepest provenance tooling of the three — cosign, SLSA provenance, years of production hardening. It is the one class where content-level attestation is routine: in-toto’s Vulnerability predicate (https://in-toto.io/attestation/vulns, modelled on cosign’s vulnerability-attestation spec, naming Grype and Trivy), binding a scanner’s output to an image digest as a separate, verifiable record. Settled ground; this series doesn’t re-litigate it.

The weights are newer, and the honest news is good: model signing is solved well enough to name as solved. KitOps packages a model as an OCI artifact — kit pack, kit push, kit pull mirror the container verbs — and Sigstore’s model-transparency project reached v1.0, wrapping in-toto statements in sigstore bundles, with documented adoption at NVIDIA NGC. CycloneDX’s ML-BOM (modelCard) separately carries performance-metric fields — a BOM-centric analogue for what an eval predicate could contain, though CycloneDX does not itself ship an in-toto-aligned attestation of it.

That format has a standards-body home worth naming precisely. CNCF ModelPack was accepted to CNCF Sandbox on 13 May 2025 — two months after KitOps, itself accepted to Sandbox on 4 March 2025 — largely from the same contributor set (Red Hat, PayPal, ANT Group, ByteDance). Sandbox is CNCF’s earliest tier: initial due-diligence only, no code-quality, security, or governance bar beyond that. Say “CNCF Sandbox project,” not “a CNCF project” — the shorthand is directionally true and materially overstates the maturity bar it implies. KitOps describes itself as ModelPack’s “reference implementation” and “the only enterprise implementation” — that framing is KitOps’/Jozu’s own, not an independent verdict, even though the underlying donation into the CNCF spec is corroborated.

The tools are where the asymmetry lands. An agent’s tool surface — MCP server definitions, skill files, tool manifests — is where this series applies Part 1’s mechanism somewhere it hasn’t been tried yet: a tool definition is a document, a document can be an artifact, an artifact can carry attachments. Nothing in the spec restricts subject to container images or model weights.

What the official registry actually checks#

The official MCP Registry — in preview since September 2025, API frozen at v0.1 — validates namespace ownership at publish time: a GitHub login or a DNS proof that the publisher controls the name they’re claiming. As of this writing, that is what it checks. No signature, SBOM, or attestation travels with the server.json definition itself. A published server is one whose name has been vouched for, not one whose contents have been.

That’s a narrower, more useful claim than “no standard exists for AI artifact signing” — which is false, given the model-layer answer above — and it’s worth stating precisely rather than loosely: the gap is the tool/manifest layer specifically, not AI provenance in general. The MCP spec’s largest revision to date is at release-candidate stage as this is written, with finalization targeted for 28 July 2026; nothing here asserts what that finalized text does or doesn’t add, and this claim gets re-checked against the final spec before publish, not assumed to still hold.

Naming the actual hard part#

Even once a tool definition can carry a signature, the harder question sits one layer up: what should an attestation over a tool definition actually assert? “This tool definition was signed by its author” is cheap and weak — it confirms provenance, not behaviour. “This tool was evaluated and stays within these bounds” is what a deployment actually wants, and nobody has a general, standard answer for what that predicate should contain, who’s qualified to issue it, or how it should be re-verified as the tool changes. That’s not a gap this post closes. Naming it precisely — rather than ignoring it or hand-waving a solution — is the honest place to leave it.

What this means operationally#

This isn’t only a supply-chain argument — it’s also a deployment-shape one. The AI-Native Factory Stack already makes the case that runtime, data, and models can share one lifecycle on a single edge box; sovereign, on-box inference is what that shared lifecycle serves in production. Neither of those posts re-litigates provenance — they’re about what runs where. This post is about what you can trust about what’s running, once it’s there. The two questions compose: a box that pulls its runtime, its model, and its tool definitions through the same registry is also a box where “what changed since last week” is a single query away, for whichever of the three artifact classes actually carries an attachment.

Once weights and tools both travel as digest-addressed artifacts with attachments, the substrate claim Part 1 made stops being about deployment convenience and starts being about coverage: one registry, one signed lifecycle, one restore path for everything an agent depends on — provided every class of artifact in it actually carries the attachments the mechanism allows. Today, two of three classes do. Part 3 asks what that coverage is worth against an external clock that doesn’t care whether the tooling is ready.