When an AI agent moves from a demonstration into a customer’s production tenant, the technical surface stays roughly the same — a container, an identity, a tool catalogue, a model deployment — but the obligations change category. Procurement, compliance, audit, and operations teams all start asking questions that have nothing to do with model accuracy. They ask about traceability, signing, provenance, rollback, and what happens on the day the agent does something unexpected. This series catalogues the eight architectural decisions that decide whether those questions have good answers.
Each chapter is written to be read independently. Chapters can be skimmed in twenty minutes apiece; together they form a coherent template for shipping any agentic AI workload to a customer environment, regardless of the cloud, the framework, or the model provider.
Foundations
-
Chapter 1
Choosing a Delivery Model for an AI Agent
The three viable patterns — full-history mirror, squashed-release handoff, signed-image appliance — with a decision table by customer count, source-IP sensitivity, and audit posture. Includes the “source-ZIP upload” anti-pattern that quietly destroys chain of custody.
-
Chapter 2
Chain of Custody — Making Every Running Binary Traceable to a Source Tag
The three questions every compliance team eventually asks, the small
/versionendpoint that answers them, and why container digests beat tags when the question is “what is running, right now?”
Architecture
-
Chapter 3
The Signed-Image Appliance Pattern
Cryptographically signing a container image at build time and verifying it at install time. OIDC-keyless signing, the Sigstore transparency log, SLSA build-provenance attestations, and what a customer actually verifies before installing.
-
Chapter 4
The Pin File — A Small JSON Contract Between Build and Deploy
One versioned JSON document with the image digest, signing identity, and SBOM URL. The cheapest interface between an internal build pipeline and a customer-facing deploy step — and the most under-rated.
-
Chapter 5
The Bootstrap-Repo Architecture — Separating Source from Distribution
Why a small companion repo containing only the deploy scripts and the pin file beats every variant of single-repo distribution. What to copy in, what to deliberately leave out, and how to keep the two repos honest with each other.
Operations
-
Chapter 6
Ephemeral CI Runners When Hosted Runners Are Disallowed
Enterprise CI policies often disable hosted runners. The ephemeral container-job pattern — scale-to-zero, no Docker-in-Docker, identity-only auth — lets you keep the rest of the pipeline unchanged. Offloading the actual image build to a cloud builder keeps the runner role tiny.
-
Chapter 7
The Pre-flight Hygiene Checklist for Customer Releases
The half-dozen checks you run on the working tree before every push to a customer-facing remote: internal documentation excluded, secret scan clean, tag selection deliberate, no tenant identifiers in history.
-
Chapter 8
Release Cadence, Rollback, and the 2 a.m. Playbook
What “release day” actually looks like for a tenant-deployed agent. The pre-cut, cut, and post-cut checklists; the rollback playbook; the smoke tests that should pass before you tell the customer it is done; the customer-facing release-note template.
How to use this series
If you are starting a new agent project, read in order. The decisions in chapters 1 to 5 compound — the right delivery model makes the chain-of-custody chapter trivial; the signed-image appliance gives the pin file something meaningful to point at; the bootstrap-repo architecture stops the pin file from leaking source.
If you have an existing agent shipping today and you want to improve what you have, start at chapter 2 (chain of custody) and chapter 7 (pre-flight hygiene). Both are inexpensive to retrofit and pay back the first time an auditor or a procurement team asks “how do you know what is running?”
If your CI is blocked by enterprise policy and that is why your release is stuck, jump to chapter 6.
About this series
This series is vendor-neutral. It uses container images, OCI registries, Sigstore signing, SLSA provenance, CycloneDX and SPDX SBOMs, and OAuth token-exchange flows as its primitives because these are the open standards every modern release toolchain converges on. Where a worked example would help, the example is drawn from the public capabilities of a mainstream cloud (typically GitHub plus a managed container runtime), and the surrounding text explicitly notes that the pattern works the same way on every other major platform.
The references in each chapter point to a small, stable set of public sources — Sigstore, the SLSA framework, the OCI Image Specification, the OWASP and NIST AI risk materials, and the relevant IETF RFCs — chosen because they are the sources procurement, audit, and regulators are most likely to ask about.
More field guides
-
Field guide
Anti-Patterns Catalogue
Fourteen named security failure modes in agentic AI, each with a definition, a hypothetical scenario, and a layered remediation grounded in current industry frameworks.
-
Playbook
Self-Test Playbook
A paste-ready prompt pack you run against your own agent’s code, with thirteen targeted security checks and a red-team prompt.