Should AI Agents Have Version Control and Signing? A Practical Guide to OCI Packaging

When Models Are Tightly Governed, Agents Are Running Naked

Model management in AI engineering has matured considerably. Most teams have established model registries, versioning mechanisms, and even signature verification. You can clearly see which version of a model is running in production, where it came from, who reviewed it, and whether it's been tampered with.

But when we turn our attention to the Agents that actually call those models, the picture looks completely different. A Reddit user cut straight to the point in a recent discussion: Agents are often just "a folder of prompts, a few MCP server configs, and some skills cobbled together from various places" — and nobody can accurately say which version of an Agent is actually running in production.

This disconnect is genuinely dangerous. Models are treated as first-class citizens with strict governance, while the Agents that actually interact with users and external systems — the ones that determine behavioral logic — remain stuck in a "git clone and go" primitive state.

Why Agents Are Hard to Version

The fundamental difference between Agents and models is that an Agent is a composite artifact, not a single weights file. A complete Agent typically consists of several layers:

• Prompts: Define the Agent's behavior, role, and constraints
• MCP Server configurations: Interface definitions connecting external tools and data sources
• Skills: Capability modules from various sources that may be updated at any time
• Policies: Permission, security, and compliance rules

These components are often scattered across different repositories, config files, and external dependencies. Any small change in any part of the stack — a skill quietly updated upstream, or a prompt manually edited — can significantly alter the Agent's actual behavior without leaving a clear version trail.

Compare this to the model scenario: the hash of a .safetensors file is deterministic. But an Agent's "state" is assembled from multiple dynamic parts. This is the core challenge of Agent versioning: you're not packaging a single file — you're packaging an entire runtime context.

MCP (Model Context Protocol) is an open protocol released by Anthropic in late 2024, designed to standardize how AI models connect to external tools and data sources. Similar to how USB-C unified device interfaces, MCP aims to provide a universal interface specification for Agent "tool calls," enabling different Agent frameworks to reuse the same tool integrations. An MCP Server is the server-side component implementing this protocol, exposing specific capabilities to Agents (such as file I/O, database queries, and API calls). Since MCP Servers are independently deployed external services, their versions and behavior can change without the Agent being aware — this is the "quietly updated upstream" problem mentioned in the article, and one of the key reasons why Agent version management is far more complex than model version management.

Using OCI Artifacts to Treat Agents as Deployable Artifacts

To address this problem, the original poster shared their team's practical approach: packaging the entire Agent as a single OCI artifact.

The tool they use is KitOps — an open-source project under the CNCF (Cloud Native Computing Foundation). The approach involves bundling all components of an Agent (the Agent itself, MCP servers, skills, prompts, and policies) into a single OCI artifact, then:

1. Signing the artifact
2. Pushing it to the same registry used for models
3. Running verification checks before loading it at runtime

The value of this workflow is that it elevates Agents to the same governance tier as models and container images. OCI (Open Container Initiative), as the standard format for the container ecosystem, natively supports version tags, content addressing, and signature verification. By reusing existing registry infrastructure, teams don't need to build a separate management system just for Agents.

What Real Problems Does This Solve?

Treating Agents as deployable artifacts directly addresses several critical production requirements:

• Traceability: Every Agent deployed to production has a clear version number and content hash
• Tamper resistance: The signing mechanism ensures the loaded Agent matches what was published, with no substitution in transit
• Auditability: Pre-load verification meets security and compliance requirements
• Consistency: Every environment runs the same immutable artifact, eliminating the "works on my machine" problem

OCI (Open Container Initiative) is an open standards organization jointly founded in 2015 by Docker, CoreOS, and others, aimed at defining universal specifications for container images and runtimes. OCI Artifact is an extension of this specification that allows arbitrary types of artifacts (not just container images) to be stored and distributed in a standardized format. Its core advantages include: content addressing (uniquely identifying content via SHA256 hash), immutability (the same digest always refers to the same content), and compatibility with existing container registries (such as Docker Hub, Harbor, and AWS ECR). Mature supply chain security tools like Sigstore/Cosign also natively support signing and verifying OCI Artifacts, meaning that once an Agent is packaged as an OCI Artifact, you can directly reuse the entire cloud-native security ecosystem — without having to reinvent a signing mechanism specifically for AI artifacts.

From "Clone and Go" to Engineering Governance

At the end of the post, the author raises a question worth the entire industry reflecting on: Are teams already treating Agents as deployable artifacts — or are they still at the stage of git cloning straight to production?

This question reveals a real gap in current AI engineering practice. As Agents move from demo prototypes to production systems taking on increasingly critical business responsibilities, the "cobbled-together" approach is no longer sustainable. When an Agent exhibits abnormal behavior, if you can't even identify its exact version, incident investigation and rollback become impossible.

Bringing mature software supply chain practices — version control, signature verification, artifact repositories — into the Agent domain is a necessary path toward making AI systems reliable, trustworthy, and maintainable. The emergence of tools like KitOps is a reflection of this trend: they aim to let AI artifacts reuse the governance capabilities that the cloud-native ecosystem has accumulated over years, rather than starting from scratch.

For teams building Agent systems, this discussion offers a pragmatic starting point. You don't need to adopt any specific tool right away — but you should at least start asking: What version of the Agent is actually running in your production environment? Can you prove it hasn't been tampered with? If the answer is no, it may be time to bring Agents into a formal artifact governance system.