Chapter 12. Deployment Authorization: S7 and Gate G3
The most sharply tier-differentiated decision in the framework, and the point at which machine-readable boundaries must exist.
12.1 What G3 authorizes
G3 records a Decision: this system, in this configuration, at this tier, is authorized to operate in production, by this named person, on this evidence. It is the record every subsequent drift comparison refers back to.
Table 35. What G3 authorizes
| Element | Content |
|---|---|
| Purpose | Authorize production deployment on assurance evidence |
| Entry criteria | Completed assurance results; control-to-risk mapping; confirmed tier |
| Required evidence | Assurance results; Control Matrix; named accountable owner; human oversight point confirmation at Tier 2+; machine-readable permission boundary for agentic systems |
| Decision authority | Tier 1: System Owner. Tier 2: System Owner with AI Governance Lead notified. Tier 3: AI Governance Body. Tier 4: AI Governance Body plus Enterprise Governance Sponsor |
| Outcomes | Approve / Approve with conditions / Remediate / Escalate / Reject |
| Automation | Low at Tier 3–4 by design; moderate at Tier 1–2 where automated evidence checks pre-clear routine cases |
12.2 Machine-readable permission boundaries
For any system with agentic capability, G3 requires the authority boundary to be recorded in a form a machine can evaluate, not only in prose.
The reason is detection, not formality. A boundary written as “the agent may read claims data and draft recommendations but may not approve payments” cannot be compared against an IAM grant automatically. A boundary expressed as an explicit tool and permission list can be, which means an unauthorized expansion becomes detectable rather than merely prohibited.
This requirement was added during the framework’s revision precisely because a prohibition nobody can detect the violation of is not a control.
[Practice recommendation] Express the boundary in whatever policy language your enforcement point already understands, and store the ADR-referenced version alongside it. Two representations of the same boundary that can drift apart is a worse position than one, so generate the human-readable version from the machine-readable one instead of maintaining both.
12.3 Kill-switch conditions
At Tier 3–4, G3 must pre-approve any condition under which automated shutdown is permitted. This is the single principled exception to the framework’s default prohibition on automated corrective action for high-tier systems (Chapter 18, §18.4).
A valid kill-switch condition has three properties. It is objectively evaluable — no judgment required at trigger time. It is defined in advance at G3, never invented at runtime. And it is narrow — matched to a specific catastrophic pattern rather than to general anomaly.
Example. Agent attempts a transaction above its approved value limit, or to a counterparty outside its approved list. On trigger: suspend agent, revoke tool access, alert Agent Owner and AI Governance Lead, preserve state for investigation.
What is not a valid kill-switch condition: “the agent behaves anomalously,” “error rate exceeds normal,” or anything requiring the Control Plane to judge whether behavior is acceptable. The kill switch fires on a pre-agreed pattern, and its firing is always traceable to a human decision made at G3.
12.4 Conditions, and the discipline of not accumulating them
Conditional approval at G3 carries more risk than at G1, because the system is going live. A condition that must be satisfied after deployment is, in effect, an accepted risk with a promise attached.
Two rules keep this honest. Any G3 condition must have a named owner and a date. And any condition still open at its date escalates automatically to the authority that granted it, instead of lapsing quietly.
[Practice recommendation] Report open G3 conditions as a portfolio metric alongside open exceptions. Both represent governance debt, and both are invisible unless counted.