An AI agent go-live approval checklist is the final gate before an agent acts in production. It lists each approval required, its evidence and the named signatory: role charter, certification on real cases, red-team results, access review, human approval routes, monitoring, rollback and accountable owner. If any line is unsigned, the agent does not go live.
What does go-live approval prove?
That every bound the agent will run under has been set, tested and owned. Go-live approval is not a celebration of the build. It is the moment the business accepts accountability for what the agent does next, and the checklist is the record of who accepted what.
It also proves human approval is in the right places. Some actions must never run without a person, regardless of how well the agent tests. Which actions fall into that group is covered in when an AI agent can act without human approval.
When should you use it?
At first go-live, and again before each widening: a new capability, a higher depth, a new channel or a new customer population. A widening is a new go-live for that capability. For customer-facing agents, the checklist also covers the channel connection, such as connecting an AI agent to your live chat platform.
How do you fill in each line?
Charter confirms the role charter is signed and matches what was built.
Certification must come from replaying the agent against real cases from your own operation, scored against a floor. Vendor demos and synthetic prompts do not count.
Red-team covers deliberate attempts to make the agent misbehave: prompt injection, social engineering, requests just outside scope. The method is in how to red-team an AI agent before go-live.
High-impact actions lists every action that moves money, changes records that are hard to restore, or communicates externally, and confirms each is held for a person or refused. This is the control for the risk OWASP calls excessive agency; see OWASP excessive agency and human approval for high-impact actions.
Access confirms a completed AI agent access review.
The checklist
| No. | Approval | Evidence | Signed by |
|---|---|---|---|
| 1 | Role charter signed and matches build | Charter, build summary | Accountable owner |
| 2 | Inventory entry complete | Inventory record | Governance lead |
| 3 | Risk assessment complete, residual risk accepted | Risk assessment | Risk owner |
| 4 | Certification on real cases passed | Test report, floor, results | Quality lead |
| 5 | Red-team completed, findings closed or accepted | Red-team report | Security lead |
| 6 | High-impact actions held or refused | Action list with verdicts | Risk owner |
| 7 | Access review complete | Access review checklist | IT risk |
| 8 | Data protection assessment complete where needed | DPIA reference | Data protection officer |
| 9 | Customer disclosure in place where people interact with it | Disclosure wording | Compliance |
| 10 | Named approvers and cover in place | Approver roster | Operations lead |
| 11 | Monitoring and daily review owner set | Runbook | Operations lead |
| 12 | Rollback and suspension tested | Test record | Operations lead |
| 13 | Staff briefed | Briefing record | Team manager |
| 14 | Final approval | All above | Accountable executive |
A filled sample
A hypothetical payments firm's merchant onboarding agent, first go-live.
| No. | Evidence | Signed by |
|---|---|---|
| 1 | Charter v2: collect application, check documents, draft risk summary | Head of merchant onboarding |
| 4 | 600 past applications replayed; document check depth 3 passed; risk summary depth 2 passed | Quality lead |
| 5 | 40 attack prompts including fake document instructions embedded in uploaded PDFs; two findings fixed, re-tested | Security lead |
| 6 | Approve merchant: refused, person decides. Set processing limits: held for risk analyst. Send rejection: held | Head of risk |
| 8 | DPIA completed for document processing | Data protection officer |
| 9 | Applicants told in portal that an AI agent checks documents first | Compliance |
| 12 | Suspension tested: agent stopped, queue returned to analysts within five minutes | Operations lead |
| 14 | Approved for document checking and risk summary only | Chief operating officer |
Line 14 approves less than the team asked for. Approval can be partial; the checklist makes that explicit rather than blocking the whole launch.
Where Pryme fits
In Pryme, line 4 is an Attest run: the agent is replayed against your own cases and must clear seven gates, each on its own. The certificate sets the agent's depth, lapses after 90 days, and drops to depth 1 the same day if a run clears no depth. The governance guide, agent governance is a bound, not a model, covers how the bounds combine.
Questions people ask
Who should give final go-live approval?
The senior person accountable for the business area where the agent works. In firms with named-accountability regimes, that is usually the senior manager responsible for that function.
Can go-live be approved with open red-team findings?
Only if each finding is rated low and formally accepted by the risk owner, with a date to close it. Any finding that lets the agent exceed its bounds must be closed first.
How long should go-live approval take?
The signatures take a day if the evidence is ready. Most delay comes from certification and red-teaming, so start those early.