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.
If those terms are new, here is the one-line version of each. An OCI registry (Open Container Initiative) is the standard store that container images are pushed to and pulled from. Sigstore is an open system for cryptographically signing software so its origin can be verified. SLSA (Supply-chain Levels for Software Artifacts) is a graded framework for proving how a build was produced. An SBOM (Software Bill of Materials), in the CycloneDX or SPDX format, is the itemised list of everything that went into a build. And OAuth token exchange is the standard way one workload trades one short-lived credential for another without a stored password. Each chapter re-introduces the terms it relies on, so you do not need to memorise this list first.
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
Twenty-five named security failure modes in agentic AI (across twenty-six articles), 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 twenty-five targeted security checks and a red-team prompt.
-
Field guide
Supply-Chain Trust
Judging third-party code, packages, actions, images and models before you trust them — provenance signals, independent verification, danger-surface review, and safe handling, grounded in OpenSSF, SLSA, NIST, OWASP and MITRE.
-
Field guide
Getting Quantum-Safe
A vendor-neutral post-quantum readiness field guide: what quantum computers break (RSA, ECC, TLS, PKI), the finalised NIST standards (ML-KEM, ML-DSA, SLH-DSA), a five-phase readiness assessment with a CBOM and maturity model, migration on real platforms, and what it all means for AI.