# AI agent deployment checklist

Source page: "AI agent deployment checklist: 41 checks before production", Volans Aquilae, https://www.volansaquilae.com/guides/ai-agent-deployment-checklist/

Version 1.0, 19 October 2026. Sources checked on 19 October 2026.

## How to use it

1. Fill in item 2 first. Every check applies to that one release: its model ID, prompt version, commit, tools and MCP servers.
2. Tick an item only when you can point to the evidence on the line below it, and note where that evidence is kept.
3. Mark an item that doesn't apply as "n/a" and give the reason in the sign-off block.
4. An unchecked item is a finding. Give it a severity from the table below, the evidence and a suggested fix.
5. Sign off at the end. Any change on the reopen list (item 38) reopens the sign-off.

## Scope and ownership

- [ ] 1. The scope is written down: tasks the agent handles, tasks it must refuse or hand over, and its users and channels.  
  Evidence: a dated scope page approved by the product owner.
- [ ] 2. The release is pinned: model ID, prompt version, commit, and each tool, MCP server and model provider with its owner.  
  Evidence: a version block that matches a staging or production trace.
- [ ] 3. Named people own the agent in production and sign this checklist off, with customer owners for customer-side items.  
  Evidence: the names on the sign-off block and in the runbook.

## Evals and quality thresholds

- [ ] 4. Golden cases come from real failures (traces, tickets, scripted attacks), grouped into a failure taxonomy with a count per class.  
  Evidence: the taxonomy, and case files each linked to a trace or ticket.
- [ ] 5. Each failure class that could stop a launch has a pass threshold, agreed before the baseline run.  
  Evidence: the thresholds, dated before the run report.
- [ ] 6. The baseline meets every threshold over several trials per case; customer-facing classes pass a case only if all trials pass (`pass^k`).  
  Evidence: the run report: suite commit, model and prompt versions, trials, per-class results.
- [ ] 7. Graders check outcomes in code (tool, arguments, record changed), and each LLM-as-a-judge is calibrated against human labels.  
  Evidence: the grader code, and each judge's labelled set and agreement rate.
- [ ] 8. The suite runs in CI on every model, prompt, tool or scope change, and a class below threshold blocks the release.  
  Evidence: the CI job, and a deliberately broken change it blocked.

## Tools, permissions and MCP connections

- [ ] 9. Every tool and MCP server has an access record: credential, token audience, scopes held and needed, write actions, owner.  
  Evidence: one record per tool; scopes needed come from tool calls in traces.
- [ ] 10. No credential holds scopes its tools don't use: no wildcard or omnibus scopes (`*`, `all`, `full-access`), no unused write scopes.  
  Evidence: scopes held compared line by line with scopes needed.
- [ ] 11. Every MCP server rejects tokens issued for another audience and calls downstream APIs with its own credential, never a forwarded token.  
  Evidence: a 401 for a token minted for another resource, and the upstream call in code.
- [ ] 12. Writes run as the end user or with a short-lived, task-scoped token, and the downstream system authorises every call.  
  Evidence: the token lifetime and scopes, and a test where user A can't change user B's record.
- [ ] 13. Tool arguments pass schema checks before execution, and customer and account IDs come from the session rather than the model.  
  Evidence: the schema per tool, and a refused out-of-range argument.
- [ ] 14. Third-party MCP servers and tool definitions are pinned to reviewed versions, local servers run sandboxed, and a changed definition fails CI until reviewed.  
  Evidence: pinned versions, sandbox settings and a tool-definition snapshot with a CI diff check.
- [ ] 15. MCP servers and proxies you run pass the confused deputy, SSRF, state handle, request state, retry and cache rows of our [MCP server security checklist](https://www.volansaquilae.com/guides/mcp-server-security/).  
  Evidence: each row's dated test result.

## Prompt injection and data exposure

- [ ] 16. Scripted attacks plant instructions in each untrusted input the agent reads, aimed at each write tool and each way data can leave.  
  Evidence: the attack cases in the suite, with results over several trials.
- [ ] 17. Every action that changes customer data or money, or sends data out, needs a confirmation the model can't give itself.  
  Evidence: the confirmation per write tool (user, staff approver or rule in code), and an attack it stopped.
- [ ] 18. The interface loads images only from your domains and shows each link's full address, so output can't quietly send data out in a URL.  
  Evidence: the Content Security Policy, and a planted image URL carrying conversation data that never loads.
- [ ] 19. Replies hold only data the signed-in user may see: retrieval and tools filter by that user's permissions first.  
  Evidence: user A asking for user B's records and getting none.
- [ ] 20. The system prompt holds no credentials or secrets, and no access rule relies on the model obeying it.  
  Evidence: the system prompt, with each access rule mapped to the code that enforces it.

## Data protection and privacy

- [ ] 21. A data protection impact assessment covers the agent, or your data protection lead has recorded why none is needed.  
  Evidence: the DPIA or the dated screening decision.
- [ ] 22. Every model provider and hosted tool receiving personal data has a processor contract, a sub-processor listing and recorded retention and training terms.  
  Evidence: the contract reference, the sub-processor entry and the provider's retention setting.
- [ ] 23. Traces, logs and eval cases have a retention period, restricted access and redaction, and deletion requests reach them.  
  Evidence: the retention settings, the access list, a redacted trace and a test deletion.
- [ ] 24. Users are told they are dealing with an AI system, and when a person takes over.  
  Evidence: the disclosure and hand-off text in the interface.

## Human escalation and approvals

- [ ] 25. Approvers see the exact tool call and arguments (amount, recipient, record) beside the agent's summary, and an unanswered approval expires to no action.  
  Evidence: a screenshot of the approval screen, and a timed-out approval that ran nothing.
- [ ] 26. The agent hands off to a named, staffed queue with the conversation history: on request, after repeated failures and before high-risk actions.  
  Evidence: a test hand-off per trigger, the tickets created and the queue's rota.

## Monitoring, alerting and the kill switch

- [ ] 27. Production traces record every model call, tool call, tool result and hand-off, with model and prompt versions and a correlation ID.  
  Evidence: a sample production trace with those fields.
- [ ] 28. Graders run on sampled live conversations with an alert per critical failure class, and users can flag a bad answer.  
  Evidence: the sampling rate, alert rules, and a test alert and flag that reached a person.
- [ ] 29. One switch turns off write tools and another the whole agent, both without a deploy, and users then see a fallback message.  
  Evidence: the staging record with each switch's time, and a screenshot of the fallback.
- [ ] 30. A named person watches the launch, and an on-call rota and runbook say who can pull each switch and revoke each credential.  
  Evidence: the rota, the runbook and a timed credential rotation.

## Rollout and rollback

- [ ] 31. The launch starts with a limited group (pilot accounts, one customer or a share of traffic), with written criteria for widening it.  
  Evidence: the rollout plan, the group list and the criteria.
- [ ] 32. Prompt, model ID, tool definitions and scopes ship as one versioned release unit, and rollback to the previous unit is tested and timed.  
  Evidence: the release record, and the rollback test with its time.
- [ ] 33. Every action a rollback can't undo (refunds paid, emails sent, records changed) has an owner and a way to reverse or compensate it.  
  Evidence: the list, with a procedure and owner for each.

## Cost and rate limits

- [ ] 34. Cost per conversation is known at the median and 95th percentile, within a budget, with a spend alert and a per-conversation cap that stops loops.  
  Evidence: cost figures from traces, the budget, the alert rule and a capped test loop.
- [ ] 35. Rate limits per user, tenant and tool are tested at the limit, and provider 429 and overload errors get backoff and a user message.  
  Evidence: the limit settings, and test results that include a throttled provider.

## Model updates and change control

- [ ] 36. Production sends an exact model ID from one configuration value, never an alias.  
  Evidence: the configuration, and a production trace showing the ID.
- [ ] 37. Each model in use has a recorded retirement date and owner, someone reads each provider's deprecation notices, and the suite has run on any announced replacement.  
  Evidence: the model register, and the replacement's run report.
- [ ] 38. The sign-off lists what reopens it: a new model or snapshot, or a changed prompt, tool, scope or data source.  
  Evidence: the reopen list on the sign-off.

## Evidence for your customers' security reviews

- [ ] 39. A data-flow description shows what data reaches each provider, tool and log store, where, and for how long.  
  Evidence: the dated diagram or table.
- [ ] 40. This checklist's evidence is filed with dates and versions: eval report, access records, attack results, and switch, rollback and limit tests.  
  Evidence: an evidence-pack index whose versions match item 2.
- [ ] 41. An incident runbook covers agent failures (a wrong refund, a cross-customer leak, a successful injection): who is told, how fast, and how customers hear.  
  Evidence: the runbook, with one agent scenario rehearsed.

## How unchecked items count

| If unchecked | Items | Why |
|---|---|---|
| Blocker | 6, 10, 11, 17, 19, 29 | The five typical blockers on the verdict scale below, plus another customer's data (item 19). |
| Blocker where the law applies | 21, 22, 24 | Needed before processing or launch; your data protection lead or counsel decides whether each applies. |
| Blocker or condition | 12, 13, 15, 18, 20 | A blocker when this gap alone exposes customer data, money, a token or a secret. |
| Condition | 1–5, 7–9, 14, 16, 23, 25–28, 30–38, 41 | Met by a date with an owner, often behind a pilot group, a lower limit or human approval. |
| Note | 39, 40 | A condition when a customer's security review is pending. |

Item 6 is a blocker when the top failure class is far below its threshold, and item 29 when nothing turns the agent off quickly. A small gap below threshold, or a missing write-tools switch beside a working agent switch, is a condition.

## Sign-off

- Release (item 2): model ID, prompt version, commit, tools and MCP servers:
- Date:
- Owner in production (name, role):
- Signed off by (name, role):
- Customer owners, for a customer launch (name, role, items):
- Verdict (go / go with conditions / no-go):
- Blockers (item, evidence, fix):
- Conditions (item, owner, date, evidence that will close it):
- Notes (item, evidence):
- Residual risks (risk, owner, review date):
- Items marked n/a (item, reason):
- Changes that reopen this sign-off (item 38):

The verdict scale:

- Go: no open blockers. Every critical failure class passes its agreed threshold. Every tool connection holds only the access it needs. Residual risks are named with an owner.
- Go with conditions: no blockers, but named conditions must be met by a date, each with an owner. Examples: launch to a pilot group only; human approval before refunds.
- No-go: at least one blocker. Typical blockers: a prompt-injection path to an action that changes customer data or money, with no confirmation step; a tool credential much broader than the task needs; token passthrough; the top failure class far below threshold; no way to switch the agent off quickly.

Evals show that failures exist; they can't prove their absence. A sign-off applies to one release on one date. This checklist isn't a penetration test, legal advice or a certification.

## References

All pages accessed 19 October 2026. OWASP IDs are from the 2025 LLM list; the 2026 edition renumbers them, so write the edition next to every ID.

- Scope and ownership: NIST AI RMF 1.0 (NIST AI 100-1, 26 January 2023), GOVERN 2.1. https://tsapps.nist.gov/publication/get_pdf.cfm?pub_id=936225
- Evals: Anthropic, "Demystifying evals for AI agents", 9 January 2026. https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents
- Tools and MCP: OWASP LLM06:2025 Excessive Agency, https://genai.owasp.org/llmrisk/llm062025-excessive-agency/ ; MCP Security Best Practices, revision 2026-07-28, https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices
- Prompt injection and data exposure: OWASP LLM01:2025, LLM05:2025, LLM07:2025 and LLM08:2025, https://genai.owasp.org/llm-top-10/ ; Meta, "Agents Rule of Two", 31 October 2025, https://ai.meta.com/blog/practical-ai-agent-security/
- Data protection: ICO, when a DPIA is needed, https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/data-protection-impact-assessments-dpias/when-do-we-need-to-do-a-dpia/ ; ICO, contracts with processors, https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/contracts-and-liabilities-between-controllers-and-processors-multi/when-is-a-contract-needed-and-why-is-it-important/ ; EU AI Act Article 50, https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-50 , and Article 113, https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-113
- Human escalation: OpenAI, "A practical guide to building agents", https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf ; OWASP Top 10 for Agentic Applications for 2026 (9 December 2025), ASI09, https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/
- Monitoring and the kill switch: NIST AI RMF MANAGE 2.4; OWASP agentic list ASI10; OpenAI, "Safety best practices", https://developers.openai.com/api/docs/guides/safety-best-practices
- Rollout and rollback: Google, The Site Reliability Workbook, chapter 16, "Canarying Releases", https://sre.google/workbook/canarying-releases/ ; OWASP agentic list ASI04.
- Cost and rate limits: OWASP LLM10:2025 Unbounded Consumption, https://genai.owasp.org/llmrisk/llm102025-unbounded-consumption/ ; Anthropic, "Rate limits", https://platform.claude.com/docs/en/api/rate-limits
- Model updates: Anthropic, "Model deprecations", https://platform.claude.com/docs/en/about-claude/model-deprecations ; OpenAI, "Deprecations", https://developers.openai.com/api/docs/deprecations
- Customer security reviews: NIST AI RMF GOVERN 6.1.