Stage Six — Deployment and Release

15.1 What Changes at This Stage #

The release record must answer a question it was not designed to answer. Historically, “who wrote this” and “who approved this” were both answerable from the commit and review record, and both answers were people. The release record now needs to distinguish agent-authored from human-authored change, identify the model version and the authorizing human, and do so in a form that survives an audit eighteen months later. No SBOM format has a native construct for “this source file was generated by an AI agent”; both major formats describe models and datasets reasonably well and neither describes generated code provenance.^80,81 The gap is real and should be closed by convention plus attestation rather than waited out.

Rollback triggers do not fire on the failure that matters. In conventional progressive delivery the trigger is an error rate: a 5xx, a latency spike, a crash. A model-backed feature that degrades usually produces no error at all. The service returns 200 with a well-formed response that is now subtly worse. The rollback trigger must therefore be a distribution comparison against a baseline—evaluation score, judge score, refusal rate, tool-call error rate, task completion rate—rather than an error threshold. There is no published enterprise standard for this and no independent research on it; it is named here as an open problem in Section 23 and as a design requirement regardless.

Separation of duties is the regulatory pressure point. Article 17 of the DORA regulatory technical standards requires independence between the function approving a change and the functions requesting and implementing it.⁴ PCI DSS 6.2.3 requires pre-release code review, with 6.2.3.1 requiring a reviewer other than the originating author where the review is manual, and permitting automated review as an alternative.² SOC 2 CC8.1 requires authorization preceding implementation.³ An agentic pipeline satisfies all three only if the agent cannot approve its own change and cannot authorize its own workflow execution—which is why those two controls appear in Section 13 and are re-tested here.

The honest framing for an audit conversation is this: these criteria do not break under agentic delivery, but the control relocates. It moves from the individual change to the policy, the enforced ruleset, and the evidence pipeline governing the agent. That is an interpretive position, and it should be presented to auditors as one rather than as a settled reading.

Release governance now has a shipped reference implementation, and feature availability is not maturity. Platform capability in this area advanced substantially through 2025 and 2026—enterprise control planes for defining approved models, restricting which agents teams may use, managing agent identity, and configuring audit logging; source-controlled agent instruction files; and organization-wide code quality visibility.⁵² These are real capabilities. Whether an organization has configured them is a separate question from whether its vendor ships them, and the two are routinely conflated in maturity self-assessments.

15.2 Elements to Adopt #

Provenance in the release record. Every release carries a manifest identifying agent-authored components, the model versions involved, the authorizing humans, and the verification that ran. Where the toolchain supports build provenance attestation, emit it; the applicable standard defines a build track at levels 0 through 3 and, since November 2025, a source track at levels 1 through 4, where the highest source level requires “two trusted persons to review all changes to protected branches.”⁷² That source-track requirement is currently the strongest available control for agent-authored code precisely because it addresses the problem through review rather than through provenance metadata that does not yet exist.

A bill of materials that includes the AI dependencies. The general SBOM baseline was reissued in July 2026 with ten new fields including author signature, component hash and hash algorithm, component license, and generation context.⁸² Separately, a government-backed AI SBOM specification defines seven clusters (metadata, system-level properties, models, dataset properties, infrastructure, security properties, and key performance indicators) requiring documentation of model lineage and dataset provenance.⁸³ Both are voluntary. Adopt them anyway: the elements are agreed even though interoperability is not, and being early on this is cheap relative to being late.

Signed artifacts and verified provenance at the release gate. Keyless signing infrastructure has matured to the point where this is an ordinary engineering task rather than a program: short-lived certificates bound to a workload identity, with the signing event recorded in an append-only transparency log.⁸⁴ Model artifacts have a corresponding signing specification, PKI-agnostic and layered on the same envelope and statement formats, with contributions from most major infrastructure vendors.⁸⁵

Deployment authority separated from generation authority. An agent that writes code does not deploy it. An agent that deploys does not write. Where an organization wants both, they are two deployments with two identities, two tiers, and two owners. This is the cheapest structural control in the framework and it survives every subsequent argument about tooling.

Progressive delivery keyed to quality distributions. Canary and shadow deployment are mature practices and nothing about them changes mechanically. What changes is the promotion criterion: shift traffic on evaluation score distribution, refusal rate, and task completion rate rather than on error rate alone, and define the rollback trigger before the deployment rather than during the incident. Runtime configuration of prompts, instructions, and model selection outside the application binary is the capability class that makes this practical, since it allows a model or prompt change without a redeployment and a revert without a rebuild.⁸⁶

Model version changes treated as releases. A provider model change is a production change to your system, whether or not your code changed. It goes through the release gate, runs the evaluation suite, and is announced to whoever operates the service. A pinned dated snapshot is the baseline; aliases are prohibited in production paths.

Operational readiness for agent-touched systems. Before release, confirm that the system emits the telemetry Section 16 requires, that a kill switch exists for any agent operating against it with a measured time-to-effect, that on-call staff can distinguish a model failure from a code failure, and that the runbook covers the case where the agent’s own account of what happened is wrong. That last item is not hypothetical: in the Replit incident the agent reported that rollback was impossible when it was not.¹⁴

15.3 Controls #

15.4 Evidence to Request #

• A release manifest showing the agent-authored share and the model versions involved.
• A signature and provenance verification log for a recent release.
• The result of a quarterly separation-of-duties test—an actual attempt to have an agent approve or deploy its own change, and the record of it failing.
• The rollback trigger definition for a model-backed feature, and the last time it fired or was exercised.
• The SBOM for a shipped release, checked for whether AI components appear at all.

15.5 Failure Modes #

• The release record that cannot answer the authorship question. Discovered during an incident, an audit, or a legal inquiry, at which point it is not fixable retroactively.
• Rollback that handles unavailability and not degradation. The fallback path fires when the provider is down and never fires when the model is confidently wrong, which is the far more common and far more damaging failure.
• Separation of duties assumed rather than tested. Configured once, never verified, and quietly broken by a ruleset exception added eight months later to unblock a release.
• Alias drift in production. A floating model alias somewhere in the configuration means the provider changes the system’s behavior on their schedule. It is usually found because behavior changed, not because anyone audited for it.
• Feature availability recorded as maturity. The platform supports an agent control plane; nobody configured it; the maturity self-assessment claims it. Independent assurance exists to catch exactly this.