On-Demand Demo

How KitOps v1.11 Makes Prompts Governable

The Problem

In an LLM system, behavior is not determined by the model alone. It is also shaped by the prompt layer: system prompts, agent rules, tool instructions, and templates. So production behavior can change without any code or weight updates, just by editing a prompt.

That is prompt drift. It is the new silent deployment: outputs change, but your normal release signals do not. No version bump, no image digest change, no PR that clearly explains the behavior shift. And because prompts often live in scattered places like docs, wikis, READMEs, chat history, or quick overrides in code, teams lose basic control.

When something breaks, you hit questions you cannot answer reliably:

Without those answers, incident response slows down. You cannot reproduce past behavior, so debugging becomes guesswork. Rollbacks turn into text hunting instead of reverting a versioned artifact. Audit trails are weak because the behavior change was never tracked like a real release input.

Your model didn't change. Your prompt did. Can you prove exactly what ran in production?

The Solution

The fix is not "write better prompts." It is to treat prompts as governed release inputs, the same way you treat code, container images, and model weights. If a prompt can change production behavior, it needs the same fundamentals: versioning, reviewable diffs, provenance, and the ability to roll back to a known-good state.

KitOps v1.11 adds prompt files as first-class ModelKit content. Prompts are no longer an informal pile of text scattered across docs and chat logs. They become explicit, declared artifacts in the Kitfile via a dedicated prompts: section.

A minimal Kitfile example looks like this (short on purpose):

manifestVersion: 1.0.0
package:
  name: my-agent
prompts:
  - path: CLAUDE.md
    description: "Agent instructions"

Two practical workflow improvements come with that:

  1. Prompts can be packaged and handled separately from other ModelKit content. The v1.11 release notes explicitly call out that prompt files can be stored as a distinct Kitfile section, and then "unpacked and read" separately from the rest of the ModelKit data.

  2. kit init can detect prompt files automatically. If you run kit init in a directory that contains common agent instruction files (for example CLAUDE.md) or files ending in .prompt, KitOps will classify them as prompts in the generated Kitfile instead of lumping them into generic code.

There is also a hard compatibility boundary: ModelKits that include prompts require KitOps v1.11 to unpack. Older versions will fail when unpacking a ModelKit that contains prompts.

Outcome: you can ship a single portable artifact that includes the behavior layer (prompts) alongside the rest of the release bundle, and then apply your existing engineering controls to prompt changes: diff in PRs, approvals, promotion tags, and rollbacks to a known-good prompt version. (Those controls are process choices, but v1.11 makes them possible by making prompts explicit, versionable content.)

How It Works Under the Hood

ModelKits + Kitfile as the "behavior bill of materials"

A ModelKit is KitOps' packaging unit, and the Kitfile is the manifest that declares what goes into that package. KitOps describes the Kitfile as the "blueprint" for an AI/ML project, a YAML manifest that defines what goes into a ModelKit and enables packaging/versioning for storage and deployment from OCI-compatible registries.

If you think in supply-chain terms, the Kitfile is effectively a bill of materials for your AI workload: it is the authoritative inventory of what the artifact contains and therefore what your release depends on. The KitOps docs list prompts as a first-class Kitfile section alongside model, datasets, code, and docs.

KitOps v1.11's key change is not "you can store text files." It is that prompt files are explicitly declared under prompts:, rather than being buried in "docs" or mixed into "code." This matters because once prompts are declared, you can build tooling around that declaration: selective extraction, prompt-specific checks, and clear diffs that are about behavior, not "some random markdown file changed."

Prompt packaging

In v1.11, prompt files live in the Kitfile under a dedicated prompts: section (as shown in the Kitfile example above). The official Kitfile reference defines prompts as an object array where each entry includes at least a path and optional description.

File naming is not a hard requirement, but it affects automation. kit init in v1.11 can detect prompt/agent instruction files and place them under prompts: automatically. The release notes mention common agent instruction files (example: CLAUDE.md) and files ending in .prompt.

Internally, the Kitfile generation logic also recognizes specific filenames like AGENTS.md, SKILL.md, and CLAUDE.md, and uses .prompt matching as part of detection.

Prompt-only workflows

v1.11's operational benefit is that prompts are now addressable as a distinct artifact subset. The release notes state that prompts can be unpacked and read separately from the rest of the ModelKit data.

Concretely, v1.11's unpack filters support the prompts type, for example:

That gives you a clean "prompt-only" workflow:

kit unpack my-registry/my-agent:prod --filter=prompts -d ./extracted-prompts

From there, a CI job can operate on only the extracted prompt files (linting, secret scanning, policy checks, review summaries) without needing to pull or unpack everything else in the ModelKit.

There is also a compatibility boundary. The v1.11 release notes state that attempting to unpack a ModelKit containing prompts using an older Kit version will fail, and that v1.11 is required for this functionality.

One more implementation detail that matters for engineers: prompts are not introduced as a new OCI layer media type. Internally, prompts are stored in existing "code" layers with an additional annotation identifying them as prompts (layer subtype). That is how KitOps can still do prompt-specific operations while keeping the underlying artifact format stable.

Prompt supply-chain gates

KitOps v1.11 does not magically enforce security policies on prompts by itself. What it does is make prompt files explicit and extractable, so you can apply your existing CI/CD and security controls to the prompt layer in a way that is reliable and repeatable.

A practical "prompt supply-chain gate" usually includes three classes of checks:

  1. Secret detection
    Prompt files are often copy-pasted from experiments and can accidentally include tokens, API keys, internal URLs, or sensitive snippets. Treat prompt artifacts like code: scan them before promotion.

  2. Policy linting
    This is org-specific, but common rules include required safety language, forbidden instructions (for example, "ignore previous instructions"), tool-use constraints, and standard headers. The motivation is real: OWASP's LLM Top 10 explicitly lists Prompt Injection and Supply Chain Vulnerabilities as core risk categories for LLM applications. (OWASP LLM Top 10)

  3. Approval + audit trail
    Because prompt changes can change production behavior, you typically want the same workflow you already trust for production-impacting diffs: code review, owner approval, and a record of "who approved what behavior change."

Finally, the "supply chain" story often breaks in enterprise because of registry TLS friction. KitOps v1.11 adds a --tls-cert flag for commands that communicate with a remote server, allowing Kit to verify self-signed or otherwise untrusted certificates without disabling TLS verification (as an alternative to --tls-verify=false or --plain-http).

ROI

Costs

The engineering cost is mostly process and a small amount of plumbing. You standardize where prompts live (file layout and naming), declare them under prompts: in the Kitfile, and add CI steps that unpack prompts and run checks. The ongoing overhead is the same overhead you already accept for production-impacting changes: review on diffs, required approvals, and clear release notes when behavior changes.

Benefits

Proof delivered

You end up with behavior that is easier to reproduce, changes that are governed, and a release discipline where prompt updates are handled like production-critical inputs, not informal text.

Implementation Plan

Phase 1: Start with one agent and inventory the prompt surface

Pick a single agent or LLM-backed service that is already in use. The goal is to make the prompt layer visible.

Deliverable: a clear prompt inventory for one service and a decision on "source of truth" locations.

Phase 2: Standardize the layout and naming

Before you package anything, normalize how prompts are stored so teams can navigate them consistently.

A simple convention is enough:

This aligns with how KitOps v1.11 can auto-detect certain prompt file patterns during kit init (for example CLAUDE.md and .prompt files). (KitOps v1.11 release notes)

Deliverable: prompts moved into a predictable structure with stable file names.

Phase 3: Package prompts into a ModelKit

Now make prompts explicit in the release artifact:

KitOps v1.11 introduced prompts: as a dedicated Kitfile section and supports packaging prompt files as part of the ModelKit. (KitOps v1.11 release notes)
The Kitfile format reference documents prompts entries with path and optional metadata like description.

Deliverable: one ModelKit that includes prompts as declared artifacts.

Phase 4: Add CI checks in audit mode

Once prompts are packaged and extractable, you can add checks without blocking delivery on day one.

The prompt support work in v1.11 includes prompt-focused unpacking via filters (so CI can pull just prompt content).

Deliverable: visibility into prompt issues without slowing teams down.

Phase 5: Enforce gates and make behavior changes reviewable

After you've tuned the checks and reduced noise, turn audits into enforcement.

Deliverable: prompt changes follow the same release discipline as code.

Phase 6: Operationalize across teams

Once one service is stable, scale it with templates and lightweight playbooks:

Deliverable: repeatable adoption path and an incident response workflow that treats prompt behavior as traceable, releasable input.

Takeaways

Prompts define behavior. In an agent system, they are production inputs, not documentation. That is why prompt drift matters: you can change outputs without changing code or model weights, and that creates a supply-chain gap if prompts are not versioned, reviewable, and recoverable.

KitOps v1.11 closes part of that gap by making prompts explicit in the release artifact through a dedicated prompts: section in the Kitfile, with support for packaging and prompt-focused workflows like independent unpack/read. Once prompts are treated as real artifacts, you can build prompt governance workflows on top: consistent versioning, CI gates, approvals, and auditable promotion/rollback.

Next steps

Bottom line: Prompts aren't "docs." They're deployable behavior. Treat them like the artifact they are.