Model Provenance & Securing the AI supply chain - DevOps as the Control Plane
# DevOps
# AI
The advent of AI Agents driven by models has re-defined software development and delivery processes in the last two years. DevOps is no exception.
October 8, 2026
Debashis Bhattacharyya
Model Provenance & Securing the AI supply chain - DevOps as the Control Plane
A. Introduction Summary
The advent of AI Agents driven by models has re-defined software development and delivery processes in the last two years. DevOps is no exception. The next frontier of DevOps is knowing exactly what model went into production, where it came from, what data shaped it, how it was built, and whether it is still trustworthy. It is Provenance. In this blog, we will discuss model provenance in detail and its impact on DevOps processes.
B. DevOps and Model Provenance
For years, DevOps has transformed software delivery by answering a fundamental question: Can we trace what is running in production back to its source?
Source control, CI/CD pipelines, artifact repositories, SBOMs, security scans, deployment gates, and observability collectively created a chain of evidence around software.
AI is now creating a similar and significantly more complex supply-chain problem.
A production AI system may depend on a foundation model, datasets, fine-tuning code, model weights, prompts, embeddings, libraries, inference configurations, evaluation results, guardrails, and infrastructure.
So, in AI’s context, the question changes to: "What exactly are we running, where did it come from, what influenced it, and can we prove that it has not been tampered with?"
That is the problem of model provenance.
C. From Software Provenance to Model Provenance
Software provenance establishes the origin and history of an artifact.
The Supply-Chain Levels for Software Artifacts (SLSA) specification defines provenance as verifiable information that tracks an artifact through the moving parts of its supply chain, including how and where it was produced.
AI needs the same concept, but the artifact is different.
A conventional software artifact’s lineage:
An AI model may have a lineage more like:
This lineage becomes heavily complicated when a model is downloaded from an external model hub, fine-tuned internally, combined with retrieval data, wrapped with an agent, and exposed through an API.
D. What Should Model Provenance Capture?
A meaningful model provenance record should answer at least six questions.
Question | Objective | Answers necessary for provenance |
1. Where did the model come from? | Model source should be identifiable | Was it -
|
2.What went into the model? | Establish the authenticity and integrity of ML artifacts across supply chain. | Includes -
|
3.How was it produced? | How was the model produced and deployed in the model registry | Establish with proof -
|
4.Was it evaluated? | A model version should carry evidence of its evaluation. | Were the following tests performed –
A model that passes an evaluation but is subsequently modified should not automatically inherit the previous approval. |
5.Who approved of it? | Production deployment should be tied to explicit policy for approval. | A model should go through multiple policy checks like · Provenance verified · Signature verified · Dataset policy · Security scan · Evaluation threshold · Risk classification · Production approval |
6.What is actually running? | Continuous monitoring of the model in Production. | The model approved in the registry, would be the model running in production. This warrants the Continuous monitoring for · Drift · Bias · Configuration change · Security vulnerabilities |
E. DevOps as the Control Plane
DevOps is an existing entity in organizations working on top of models. This makes the pathway easier. Rather than creating a separate AI Governance Pipeline, organizations can extend their existing DevOps control plane.
1. Illustrative Pipeline Architecture
The traditional pipeline can evolve as depicted below -
A conceptual architecture is depicted below:
2. Model Signing - AI Equivalent of Artifact Integrity
OpenSSF's Model Signing specification provides a mechanism for cryptographically signing ML artifacts. So, their origin and integrity can be verified now. This is particularly important when the organization deploying a model is different from the organization that trained it.
Provenance tells us how the model came to exist. Signing helps establish that the model we received is the model that was produced and trusted.
3. AI-BOM - Part of the Pipeline
Traditional SBOM tells us what software components are inside an application. AI requires an expanded view. Let’s call it AI-BOM
This creates a model lineage which is far more essential that a model version number. It matters more in the Agentic world as agents are dynamically making probabilistic decisions and taking business decisions followed by execution, some of which are non-idempotent or volatile.
Organizations using models, during incidence triaging, should be able to determine -
- Which model made the decision?
- Which version was running?
- What data did it access?
- Which tools did it invoke?
- What prompt/context influenced it?
- Which policy allowed the action?
- Which model or tool version changed?
- Was the model itself authentic?
- Was the deployment approved?
Without provenance, incident response becomes forensic archaeology. With provenance, it becomes traceable engineering.
Traditional DevSecOps | AI DevSecOps |
Source control | Model + data lineage |
CI/CD | AI build pipelines |
Artifact repository | Model registry |
SBOM | AI-BOM / ML-BOM |
Artifact signing | Model signing |
SAST/SCA | Model/data/security evaluation |
Security gates | AI risk gates |
Deployment approval | Model approval |
Release traceability | Model provenance |
Runtime monitoring | Model/drift monitoring |
Incident response | Model lineage + rollback |
4. AI Centric Definition of "Deployable"
In traditional DevOps, an artifact becomes deployable when it passes the required build, quality, security, and release controls.
For AI, that definition needs to expand. A model should be considered deployable only when:
This is particularly aligned with the broader AI risk-management approach promoted by NIST, which emphasizes managing risks across the AI lifecycle rather than treating AI risk as a one-time assessment.
F. Conclusion
The future of DevOps is not delivering software faster anymore; AI agents will ensure that. It will become the trust infrastructure for digital systems. Code, Containers and Dependencies required provenance. Now in 2026 - Models need provenance.
As AI becomes embedded in applications, APIs, autonomous agents, and business processes, the question of "Can we trust this?" cannot remain a manual governance exercise.
It needs to become an automated embedded repeatable and scalable engineering process. In AI DevSecOps, these properties are important as they convey important details about the model in question.
The DevOps control plane connects all four into a verifiable chain of trust. Hence as the significance of provenance grows, DevOps will evolve - from securing the software to securing the AI supply chain.
Sign in or Join the community
Where conversation, connection, and real-world practices come together.
Create an account
Where conversation, connection, and real-world practices come together.
Like
Comment (1)
Popular
Dive in
Related
Blog
I Asked More Than 50 DevOpsDays Attendees One Question
By Marc Hornbeek • Oct 12th, 2026 • Views 8
Blog
The Top 5 Things to Watch in DevOps in 2027
By Debashis Bhattachary... • Sep 23rd, 2026 • Views 112
Blog
I Asked More Than 50 DevOpsDays Attendees One Question
By Marc Hornbeek • Oct 12th, 2026 • Views 8
Blog
The Top 5 Things to Watch in DevOps in 2027
By Debashis Bhattachary... • Sep 23rd, 2026 • Views 112