Key insight
Three delivery models are viable for a tenant-deployed AI agent. A fourth is common in the wild and silently destroys chain of custody. Picking the right one on day one is a five-minute decision; living with the wrong one can become a multi-quarter cleanup.
Why delivery model is a first-order decision
Every other release-engineering decision in this series — chain of custody, image signing, pin files, bootstrap repos, CI runner topology, pre-flight checks, rollback playbooks — is downstream of how you choose to put the bits in front of the customer. A delivery model is a contract. It tells the customer’s compliance team what they will see, tells your operations team what to maintain, and tells future-you whether your source code is still yours.
There are three sound delivery models for a tenant-deployed agent and one common anti-pattern. The three models differ in how much source the customer sees, how much chain-of-custody overhead you carry per release, and how many customers the approach scales to.
The three viable models, at a glance
| Model | What the customer sees | Source IP protection | Per-release effort | Right for |
|---|---|---|---|---|
| A. Full-history mirror | Every commit, every author, every internal tag. | Weak — they have your full history. | Minimal — one git push. | A single trusted partner where source is not commercially sensitive. |
| B. Squashed-release handoff | One synthetic commit per shipped release, on a polished release branch. | Moderate — dev noise is gone; the source itself is still readable. | A few minutes per release, scripted. | One to three trusted clients who want a clean linear history and where you are still comfortable sharing source. |
| C. Signed-image appliance | A signed container image plus a small bootstrap repo containing only install scripts and a pin file. No application source. | Strong — source stays in your organisation. | Fully automated after first-time setup. | Three or more customers, regulated industries, or any setting where source is the intellectual property. |
The three are not exclusive. Most projects begin with A or B for their first one or two customers and move to C as the customer count or compliance bar grows. The architectures coexist; nothing about adopting C breaks an existing A or B deployment.
The anti-pattern: source-ZIP upload
Anti-pattern
The Source-ZIP Upload
Definition. Downloading a source archive from a release page and uploading it into a customer-controlled repository as the delivery mechanism for an AI agent.
What it destroys. The git history (all of it). The signed tag. The signed-build provenance. The SBOM. Every dependency-alert correlation. Every future ability for the customer to git pull a fix. Every trace from a running binary back to a specific commit.
Why it is hazardous. The customer’s auditors will eventually ask “what produced this binary?” A directory tree of files with no commit history has no answer. The conversation that follows is unpleasant and tends to end with a re-platforming.
Avoid by. Choosing any of the three viable models below before the first delivery.
Model A — Full-history mirror
Add the customer’s git remote to your repo and push main with tags. Their repository mirrors yours, commit for commit. Per release, the operator runs one command.
The strengths are real. Traceability is maximal — a hash reported from a running container resolves directly to a tag in the customer’s own repository, with no translation step. Auditor-friendliness is high; there are no synthetic constructs to explain. The operations cost is essentially zero per release.
The weaknesses are also real and structural. The customer sees every commit your team has ever written, including the early debugging messages, the late-night fix-ups, and the internal release-engineering notes. Internal tags travel with the push, which can confuse the customer’s version story. And most importantly, the customer has every file your repository has ever had at every point in history — this is the model with the weakest source-IP protection.
Choose model A when: you have a single trusted partner, your source is not commercially sensitive, and you are comfortable with the customer’s audit team seeing your development process.
Model B — Squashed-release handoff
You keep your full development history in your own repository. A second branch — an orphan branch with no shared commits — carries exactly one synthetic commit per shipped release. You push only this branch to the customer’s remote. They see a tidy linear history: v1.0.0 → v1.0.1 → v1.1.0, no dev noise.
The mechanics, in shape: when a release tag exists in your development branch, you check out the release branch, squash-merge the new release, commit it with a clean message, tag it, and push. Your development repository keeps the rich detail; the customer sees only the milestones.
There is a real gotcha. The running container will report the hash of the squashed commit — a hash that exists only in the customer’s repository. When the customer reports an incident referring to that hash, you cannot search for it directly in your development repository. The standard fix is a small release-map file that records both hashes per release; translation between them becomes a one-line lookup.
Choose model B when: you have one to three trusted clients, you want a polished customer-facing history, and you are willing to share source but want some narrative control over what they see.
Model C — Signed-image appliance
The customer never receives application source. They receive a signed container image, published to a registry, plus a small bootstrap repository containing install scripts, documentation, and a single pin file that names the exact image digest to install. The bootstrap repository is on the order of a few dozen kilobytes; the application source remains entirely within your organisation.
At install time, the customer clones the bootstrap repository, runs the install script, and the script verifies the image signature against your build identity before importing the image into the customer’s registry. The signature, the image digest, and the build provenance are the only artefacts the customer needs to satisfy their audit team that what they are running is what you intended to ship.
The first-time cost of setting up model C is real — on the order of one to two days for an experienced operator to wire up the build pipeline, signing, transparency-log integration, and the bootstrap repository. The per-release cost after that, however, drops to near zero. Every additional customer is essentially free.
Choose model C when: you have three or more customers, source is your intellectual property, or your industry has IP-segregation requirements (regulated finance, healthcare, government contracts). The remaining chapters of this series describe model C in depth because it is the model that scales.
Side-by-side comparison
| Aspect | A. Full history | B. Squashed | C. Signed appliance |
|---|---|---|---|
| Customer sees source | Yes | Yes (cleaned) | No |
| Hash traceability | Direct | Needs a release-map | Direct via image digest |
| Source IP protection | Weak | Moderate | Strong |
| First-time setup | Minutes | An afternoon | One to two days |
| Per-release effort | One command | Few minutes, scripted | Fully automated |
| Multi-customer scale | Each customer carries full history | History drifts across customers | One image fits all |
| Audit handoff | Direct read of git history | Direct read plus map | Image signature, SBOM, attestation |
| Rollback | git checkout + re-deploy | git checkout + re-deploy | Re-install previous digest |
A recommended adoption path
For a project starting with one customer and scaling later:
- Ship the first release via model A or B. Both are inexpensive to operate while you are still learning the customer’s environment, and either can carry you through the first few iterations without strain.
- Introduce model C in parallel for a subsequent release. The new path runs alongside the existing one; the existing customer is unaffected. The deploy script handles either delivery mode, gated by a single parameter.
- Once model C has carried two or three releases successfully, onboard new customers directly onto it. Existing A or B customers can migrate when convenient or stay where they are — the patterns coexist forever.
The point is that model C is additive. It is not a forklift change. You can adopt it without breaking anything you already ship.
Conclusion
Three delivery models. One anti-pattern. The decision is small if you make it before the first delivery and expensive if you make it after. The remaining chapters of this series describe what each model implies for chain of custody, signing, pin files, repository layout, CI infrastructure, release hygiene, and operations. The right reading order depends on the model you choose; for model C, read in order. For models A and B, chapters 2 (chain of custody) and 7 (pre-flight hygiene) are the highest-value items.
References & further reading
- OCI Image Specification (the format the three models all eventually converge on). github.com/opencontainers/image-spec
- SLSA (Supply-chain Levels for Software Artifacts) framework. slsa.dev
- NIST Secure Software Development Framework (SSDF, SP 800-218), which discusses the “protect software” tasks that include preserving an authoritative source. csrc.nist.gov/Projects/ssdf