AI Agent Pre-Deployment Checklist: 10 Gates to Pass Before an Agent Touches Production

Launch day is the wrong moment to discover what an agent is allowed to do. By then the identity is whatever the code happened to send, the grants are whatever accumulated during development, and the spend limit — if there is one — has never been tested against a real breach. An AI agent pre-deployment checklist moves those discoveries earlier: ten gates, each with a checkable pass condition, that an agent must clear before it touches production. If a gate cannot be passed, the agent is not delayed by bureaucracy. It is blocked by missing evidence, and the block itself names what would unblock it.

The need is not theoretical. Builders on Hacker News have put the core question plainly: who can use which agent, and what can each agent access? And the Governed Agent Mesh Playbook records the failure mode on the money side — a runaway loop with no budget control, where one developer burned $700 in 72 hours. A pre-deployment pass is how you answer the first question before launch, and make the second failure structurally impossible instead of merely unlikely.

The AI agent pre-deployment checklist¶

1. Every actor holds an owner-scoped identity. List every agent, script, cron job, and scheduled workflow that can take an action in your stack, and assign each one an identity in the format agent:[OWNER]/[NAME]. Record it in the identity registry with the identity, the owner, the date issued, and its status. Then test the negative case: a request with no recorded identity must park as REQUIRES_OWNER_ACTION and appear in the owner's queue, and an anonymous or shared-identity request must be rejected at the dispatch path — a block, never a warning. An actor you cannot name is an actor nobody owns.

1. Every grant is a complete, expiring record. Each grant records capability, scope, issuing owner, date issued, expiry date, and the identity it is issued to. Walk the grant store before launch and check every record field by field. Shrink each grant to the minimum capability and scope the agent has demonstrated it needs — list capabilities the way agents actually invoke them, as tool names, API calls, and cron jobs, not the way an architecture diagram describes them. Permanent grants are prohibited, and auto-grant is prohibited: every grant requires an explicit issuance decision. A capability request outside any grant must be rejected, and the rejection recorded with the requesting identity.

1. Every workload validates as a bounded plan. A unit of work counts as a plan only when it states all of its bounds: plan and owner and agent identities, workload, data class, resources including a model allowlist and a maximum number of parallel calls, a time window, location, egress with allowed domains and a size limit, storage scope and limit, a cost ceiling, an expiry, and references to the grants it relies on. Validate at creation and reject what does not validate — that rejection is itself an audit row. Plans are immutable once execution starts; a changed bound means a new plan. If you cannot state the bounds, you do not have a plan yet.

1. Every capability is tiered by consequence. Walk every capability through the risk-tier worksheet before launch: Hard-gated for actions whose consequences are money, contracts, external outreach, credentials, permission changes, or legal exposure; Bounded auto for routine work inside an approved plan; Draft-only for preparing proposals and composing messages, which are recorded and never executed. Every row needs a tier, a named owner, and the evidence required to unblock it, signed off by that owner. When in doubt, tier up — and remember that downgrading a tier is itself a Hard-gated decision. Pay special attention to so-called read-only actions: exporting a customer list or reading a credential store is a read with write-grade consequences.

1. Every plan carries a spend ceiling and an expiry. Ceilings apply per plan, never per account, and spend is counted against the ceiling in real time. Give every plan an expiry date as well — a workload with no end date is a subscription you forgot you bought. Where a framework has no native budget controls, put a meter in front of it before launch and confirm the meter's counts reconcile with provider billing. Owner alerts at thresholds are information; the block is the control. Raising a ceiling is a Hard-gated action that requires human approval and a recorded reason, never an automatic adjustment made by the agent that hit the limit.

1. Hard gates are live, and denials persist. Implement the human approval path for every Hard-gated action and prove there is no auto-grant path around it: attempt one in a test and confirm it cannot succeed without a recorded human approval. The approver must be a human holding the approver role, and the acting agent can never approve its own action. Each approval is recorded with the approver's identity, the timestamp, the action reference, and the decision. Just as important, test the rejection path: a denied or missing approval must produce a recorded block with the exact blocked result — never a silent skip that later looks like the action simply did not happen.

1. Compose and send are separate actions. Route all proposal, message, and planning generation through draft-only paths: recorded, never executed, and never contacting anyone. Sending is a distinct Hard-gated action requiring its own approval, separate from the approval — if any — that produced the draft. Audit recent draft output before launch and confirm nothing draft-only reached an external party. This separation is what lets agents do useful preparatory work at full speed without that work quietly acquiring the power to commit the team to anything.

1. The audit log is hash-linked and verified. Every request, approval, block, and outcome writes an audit row, and each row's hash chains to the previous row: sequence numbers increment by exactly one, the first row uses GENESIS as its previous hash, and a row's hash is recomputed from its own contents plus the previous hash. Verify the chain end to end before launch, then tamper with a test row and confirm verification fails visibly — a bad row is never skipped silently. Label any synthetic or demo rows "synthetic demo," and keep secrets and credentials out of every row, always. An audit log you have never verified is a claim, not evidence.

1. No warning-only paths remain on side-effecting actions. Inventory every warning-only path in the stack — missing-identity warnings, soft budget alerts, unlogged rejections — and convert each one into a block with a recorded reason. When required evidence is missing, the action fails closed: it is blocked, recorded as blocked, and never retried automatically; a retry requires new evidence, not a timer. For every block type, write the exact evidence that would unblock it and surface that checklist to the owner at block time. Test this with a real owner: hand them a blocked action and confirm they can unblock it using only the checklist the block gave them.

1. The red-team sweep passes, and sign-off is recorded. Finally, attack the finished stack: no identity, an expired grant, a ceiling breach, an unapproved Hard-gated action, and a tampered audit row. All five must be blocked and recorded; fix anything that is not before launch. Then complete the acceptance checklist, sign it, date it, and archive it with the audit log. Sign-off is the row that proves a named human reviewed the evidence before production traffic arrived.

What breaks when you skip a gate¶

Each skipped gate fails quietly. Skip identity and an anonymous actor can act with no owner to alert. Skip the grant pass and yesterday's broad development permissions become today's production permissions. Skip plan bounds and nobody can say what a workload may touch or spend. Skip the ceiling test and the first proof your limit works is a real runaway loop. Skip chain verification and the first recomputation happens during an incident review — the worst moment to discover a broken link. The system keeps working until the day it does something it should never have been able to do.

Before you call it ready¶

Ready does not mean the agent works. It means the controls around it have each been exercised — including the negative cases: the rejection, the denial, the breach, and the tampered row. Pass all ten gates, and the launch question changes from "what might this agent do?" to "here is what it is allowed to do, and here is the row that proves it."

Put this into practice¶

The ten gates above are a pass/fail summary. The Governed Agent Mesh Playbook — Studio Edition (https://ghostcorpnet.gumroad.com/l/hdigmr) gives you the working documents behind each one: the six adopt-as-is policies, the plan-bound and audit-row schemas, the risk-tier worksheet with example rows, and the 14-day rollout that installs identity, grants, audit, spend limits, and approval gates in order, ending in the same red-team sweep and acceptance checklist. Run the rollout once, then use this checklist as the gate for every agent that follows.