When I first wrote about post-quantum readiness in AI infrastructure, the artifact plane appeared as one of three surfaces under pressure, named, defined, and then largely left to the reader to develop. That was intentional. The argument I needed to make at the time was about cryptographic exposure across all three planes, not a deep treatment of any one. But the artifact plane deserves its own examination, because the failure modes there are distinct, the institutional responses have lagged the furthest, and the stakes are higher than most teams have modeled.

What the Artifact Plane Actually Contains

The three-planes framework I introduced in the post-quantum piece maps the surfaces where pressure accumulates differently in AI systems. Control planes govern coordination and trust. Data planes move information at throughput. Artifact planes are where the outputs of investment, the things you built, live, move, and accumulate exposure over time.

AI systems invert the typical artifact lifecycle. The artifacts that matter most, training corpora, fine-tuned weights, embeddings, human feedback datasets, intermediate checkpoints, are long-lived by design. Their value accumulates over time rather than depreciating. A training corpus that took two years to assemble and annotate does not expire when the first model trained on it ships. The weights of a model fine-tuned on proprietary customer interaction data carry that sensitivity indefinitely. These artifacts move continuously: across training clusters, into registries, out to inference endpoints, across regional replicas, into partner integrations, through CI/CD pipelines, and into audit systems. Each movement is an exposure event. Most organizations have modeled none of them.

Provenance Is the Security Primitive the Artifact Plane Requires

The control plane security primitive is identity: who is this actor and what are they allowed to do. The data plane security primitive is confidentiality and integrity in motion: is this traffic encrypted, is it being tampered with. The artifact plane security primitive is provenance: what produced this artifact, what has happened to it, what assumptions does it carry, and are those assumptions still valid.

Provenance is the chain of custody and the chain of causality. It answers different questions than access control does. Not “who can read this model” but “what training data produced these weights, under what conditions, with what preprocessing, validated by whom, updated when.” Not “is this artifact encrypted” but “has this artifact been modified since it was signed, and if so by what process.”

When a company I worked for acquired a forensic SaaS platform built around cloud-scale packet storage and security analytics, I was one of the engineers handed the integration work. The due diligence had been thorough. The product did what it claimed. What the evaluation had not surfaced was the deployment model leadership intended: not SaaS, but hardware appliance. The architect who assessed the product was never told. The platform worked because cloud storage was elastic. On fixed hardware, the full-fidelity capture the product was designed for was not achievable. By the time the constraint was understood, the acquisition had closed, the engineers had relocated, and the marching orders had been issued. The artifact, in this case the product itself and all the assumptions baked into its architecture, had been evaluated against a deployment context that never existed. Provenance is not only about what produced an artifact. It is about what assumptions the artifact carries, whether those assumptions were ever made explicit, and whether the environment receiving it was built to honor them.

That failure predates AI infrastructure by years. The artifact plane does not introduce the failure mode, it amplifies it by orders of magnitude. The number of artifacts carrying implicit assumptions, the rate at which those artifacts proliferate across systems, and the duration over which they remain in production have all increased dramatically.

The Lifecycle Surface Nobody Manages

Most artifact governance frameworks address the creation event. A model is trained, evaluated, signed, registered. The pipeline that produces it has been reviewed. The evaluation benchmarks have been passed. From a compliance standpoint, the artifact is approved.

The creation event is the smallest part of the lifecycle surface.

Artifact lifecycle diagram showing governance covering only the creation stage while exposure accumulates across distribution, operation, and retirement.
Figure 1 — Governance frameworks address the creation event. Exposure accumulates across everything that follows.

After creation, a model enters a distribution phase: replicated to inference endpoints, cached at regional PoPs, pulled into partner integrations, forked into fine-tuning pipelines. Each copy is a new node on the provenance graph with its own exposure surface. Most organizations have no inventory of these nodes. They know where the canonical version lives. They have limited visibility into where derived or cached versions exist, and no automated mechanism for propagating revocation when one is needed.

This is not a hypothetical gap. In federated learning and multi-party training contexts, model weights and gradient updates cross organizational boundaries, traverse networks with varying security postures, and land in environments the originating organization cannot audit. The artifact’s lifecycle has escaped the creating organization’s control plane. The cryptographic assumptions protecting it in transit are what the three-planes section of the post-quantum piece addressed directly. The governance assumptions about where it ends up, what it carries, and what happens to it after transfer are a separate and largely unaddressed problem.

After distribution comes the longest phase: production operation. Artifacts accumulate operational history. They interact with live data, produce outputs that feed downstream systems, and carry an implicit claim that their behavior is still acceptable given current conditions. That claim degrades. Datasets drift from the distributions they were collected under. Models trained on historical data encounter novel input patterns. Embeddings generated against an older semantic space are queried against content from a different era. None of this surfaces as a failure event in monitoring. It surfaces as degradation, inconsistency, and the kind of gradual behavioral shift that gets attributed to everything except the aging artifact.

The retirement event is where lifecycle management fails most visibly, because for most organizations it does not exist. Artifacts are superseded rather than retired. The old model stops receiving traffic when the new one is deployed, but the weights remain in the registry indefinitely. The training corpus is archived. The intermediate checkpoints persist in object storage because storage is cheap and deletion feels risky. What accumulates is a growing inventory of artifacts whose security assumptions are no longer being evaluated, whose access controls may not have been revisited since the team that created them changed, and whose exposure surface continues to grow.

The Post-Quantum Update

When I published Post-Quantum Readiness in AI Infrastructure, I focused on AI assets specifically, model weights, training corpora, embeddings, as the primary argument for why harvest-now-decrypt-later is a present risk rather than a future one. That framing was accurate but narrow.

The artifact plane extends well beyond AI assets. Firmware images, cryptographic key material, certificate chains, signed software releases, regulatory audit records, embedded database snapshots distributed across a product install base, these are all long-lived artifacts whose security assumptions include the strength of the cryptographic primitives protecting them. The AI infrastructure argument is the most immediately legible because the asset values are high and the accumulation rate is accelerating. But the underlying problem is the same wherever artifacts outlive the cryptographic assumptions of their creation context. Post-quantum readiness is not an AI security problem that happens to have implications elsewhere. It is an artifact lifecycle problem that AI infrastructure has made newly urgent.

What Mature Artifact Governance Looks Like

The practices are not exotic. Most of the components exist. The work is composition and discipline.

Signing at creation is table stakes and largely understood. Every artifact that enters a registry should have a cryptographic signature establishing what produced it and when. Frameworks like Sigstore and SLSA provide the plumbing; the gap is organizational rather than technical. Most teams that have not done this find that the blocker is not tooling but policy: no one owns the requirement.

Inventory that persists beyond deployment is less common. Organizations that do this well maintain a running manifest of where artifacts exist across environments, including cached, forked, and partner-held copies. The manifest is not maintained manually, it is generated from the pipeline events that create each distribution node. Revocation is only meaningful if the inventory is accurate, and manual inventory degrades immediately.

Provenance verification at inference time is rare, and the failure mode when it is absent is not always dramatic. A storage component we shipped at line rate achieved its throughput target by disabling fsync. The artifact passed every benchmark. It passed integration testing. Nothing in the verification chain could have detected what it carried, because the guarantee it violated was not a correctness property but a durability contract, invisible until a client’s power went out. The failures that followed were intermittent, took months to diagnose across a dispersed install base, and had nothing in the artifact to inspect. An inference endpoint should be able to answer, given the model currently loaded: what is its lineage, when was it last evaluated, against what benchmark, and is it the version that was approved. Most endpoints answer none of these. The operational value of being able to answer them is highest precisely when something unexpected is happening and the answer is not in the artifact itself.

Table comparing what questions a governed inference endpoint can answer versus what most endpoints can answer, across four provenance dimensions.
Figure 2 — A governed inference endpoint can answer four questions about the model it is serving. Most endpoints answer none of them.

Retirement as a first-class operation, rather than gradual decay into irrelevance, is almost entirely absent from how organizations manage artifacts today. A retired artifact should have its access controls explicitly revoked, its copies inventoried and disposition recorded, and its provenance chain preserved for audit purposes. The cost of doing this is low. The cost of not doing it, assets accumulating in environments that are no longer being governed, is paid during incidents and regulatory reviews.

Why This Has Lagged

The honest answer is incentive structure. Creating a model and shipping it to production generates visible organizational progress. Governing its lifecycle, managing its distribution, validating its provenance at inference time, and retiring it properly generates nothing that appears on a roadmap. It looks like overhead until it is not overhead anymore.

The security practices that develop around new infrastructure surfaces follow a consistent pattern: early deployments prioritize functionality, incidents reveal systemic weaknesses, standards and tooling eventually converge. The artifact plane in AI infrastructure is early in that cycle. The incidents that will make the governance gap obvious have not yet become widely known. But the exposure is accumulating now, at the rate at which models are trained, distributed, and left in production indefinitely.

The organizations that build artifact governance before they need it will find the work cheap. Those that build it in response to an incident will find it expensive and urgent simultaneously.

Sean O'Hara

Sean O’Hara

Technology leader and Founder of Arbor Engineering Group. He writes about infrastructure, engineering organizations, and the decisions that compound quietly before they surface. Find him at CTO Insights on LinkedIn or on GitHub.