An AI agent deployment checklist is a production readiness checklist for one agent release. It lists the tests the agent must pass before real users meet it, each with the evidence that proves it. Run it before a first customer launch, a new enterprise customer or a move from pilot to full rollout. The engineer who owns the agent works through it, the person accountable for the launch signs it off, and in a customer launch the customer signs for their side. Our guide to production-ready AI agents explains the gates and verdict rubric behind it.

Each section opens with the risk behind its checks and a source naming it, and each item gives the check, then its evidence. Tick an item only when you can show that evidence. An unchecked item is a finding, graded under how unchecked items count. Most of the checks apply to any LLM feature that calls tools, agent or not. Download the checklist as Markdown. The download adds a sign-off block to keep with each release.

Scope and ownership

Every later check runs against one release with named owners. GOVERN 2.1 of NIST’s AI Risk Management Framework (AI RMF 1.0, 26 January 2023) asks for those roles and responsibilities to be documented.

  • 1. The scope is written down, with the tasks the agent handles, the 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, recording the 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

Build cases from real failures, as in how to build a golden dataset from production failures, and grade outcomes in code. Anthropic’s guide to agent evals (9 January 2026) says “it’s often better to grade what the agent produced, not the path it took”.

  • 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, and customer-facing classes pass a case only if all trials pass (pass^k).
    Evidence: the run report, with suite commit, model and prompt versions, trials and 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 (how to calibrate a judge).
  • 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

Injected instructions can use every tool the agent has. OWASP’s LLM06:2025 Excessive Agency traces the harm to excessive functionality, permissions and autonomy. The MCP Security Best Practices for revision 2026-07-28 forbid servers to accept tokens not issued for them.

  • 9. Every tool and MCP server has an access record listing its credential, token audience, scopes held and needed, write actions and owner.
    Evidence: one record per tool, with the scopes needed taken from tool calls in traces.
  • 10. No credential holds scopes its tools don’t use, so there are no wildcard or omnibus scopes (*, all, full-access) and 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.
    Evidence: each row’s dated test result.

Prompt injection and data exposure

Any text the model reads can carry instructions. OWASP’s LLM01:2025 Prompt Injection says it is unclear whether fool-proof prevention exists, so these checks limit what injected text can do. Meta’s Agents Rule of Two (31 October 2025) says an agent that reads untrusted input, reaches private data and can change state or communicate externally “should not be permitted to operate autonomously”. Items 18 to 20 follow OWASP’s LLM05:2025, LLM08:2025 and LLM07:2025.

  • 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, with retrieval and tools filtering 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

Agents copy personal data into traces and send it to model providers. The UK Information Commissioner’s Office says AI can need a data protection impact assessment before processing starts, and every processor a written contract. For EU users, Article 50(1) of the AI Act requires providers to tell people they are dealing with an AI system unless that is obvious, from 2 August 2026 (Article 113).

  • 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

In OpenAI’s practical guide to building agents, the two triggers for a human are exceeding failure thresholds and high-risk actions such as large refunds. The OWASP Top 10 for Agentic Applications covers the approver’s side in ASI09 Human-Agent Trust Exploitation, where fluent agents talk people into approving actions they haven’t checked.

  • 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. On request, after repeated failures and before high-risk actions, the agent hands off to a named, staffed queue with the conversation history.
    Evidence: a test hand-off per trigger, the tickets created and the queue’s rota.

Monitoring, alerting and the kill switch

An HTTP 200 can carry a wrong refund, so quality signals belong in monitoring. NIST’s AI RMF asks for ways “to supersede, disengage, or deactivate AI systems” (MANAGE 2.4), the agentic list for kill switches and credential revocation (ASI10 Rogue Agents), and OpenAI’s safety best practices for a way users can report problems.

  • 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

Google’s SRE workbook defines canarying as “a partial and time-limited deployment of a change in a service and its evaluation” (Canarying Releases). ASI04 in the agentic list adds, “Pin prompts, tools, and configs by content hash and commit ID.”

  • 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

OWASP’s LLM10:2025 Unbounded Consumption includes Denial of Wallet attacks on pay-per-use pricing. Providers limit you too. Anthropic’s API returns a 429 error when you exceed a rate limit.

  • 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

Anthropic deprecated claude-sonnet-4-5-20250929 on 30 September 2026 and retires it from the Claude API on 30 November 2026, and OpenAI announced on 14 October 2026 that snapshots of GPT-4o, GPT-4o mini, GPT-4.1 and GPT-4.1 mini shut down on 14 January 2027. Our model deprecation dates tracker lists the retirement dates for Claude, OpenAI and Gemini models across their cloud platforms, and switching models has its own regression testing runbook.

  • 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 the changes that reopen 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

Your customer’s frameworks point at you. NIST’s AI RMF asks for policies on third-party AI risk (GOVERN 6.1). Our AI vendor security questionnaire guide lists buyers’ questions and the evidence to attach.

  • 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, covering the 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), saying who is told, how fast, and how customers hear.
    Evidence: the runbook, with one agent scenario rehearsed.

How an unchecked item counts as a blocker, condition or note

On our verdict scale a blocker alone means no-go, a condition must be met by a date with an owner, and a note goes on the record.

If unchecked Items Why
Blocker 6, 10, 11, 17, 19, 29 Our scale’s five typical blockers, plus one we add for 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.
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.

A small gap below threshold (item 6), or a missing write-tools switch beside a working agent switch (item 29), is a condition. Our sample go/no-go verdict shows findings written this way.

The five checks we’d run first

With one day, we’d run these five, in order. Each is a blocker alone, and the first three cover tools that move money or touch customer data, where mistakes can’t be undone.

  1. Item 17, confirmation on writes: plant one instruction per write tool in content the agent reads and see what stops the call.
  2. Item 10, scopes against traces: any scope with no matching call in a recent trace export is a finding.
  3. Item 19, the cross-customer test: two test accounts, one request for the other’s records.
  4. Item 29, the switches, timed in staging: every later finding is cheaper once the agent can be turned off without a deploy.
  5. Item 6, the top failure class: 20 to 50 cases from real failures, the start Anthropic’s guide suggests, each run several times.

The rest mostly produces conditions, which a limited launch can carry. If you run an MCP server, add item 11, because token passthrough is a blocker on its own.

What this checklist won’t tell you

  • A ticked item shows one check passed on the cases you tried, not that no other case fails.
  • It won’t set your thresholds. How many wrong refunds you accept is a business decision.
  • Its threat lists are dated (MCP 2026-07-28, OWASP’s agentic list of December 2025, its 2025 LLM list), and the 2026 LLM list renumbers its entries, so Excessive Agency becomes LLM03:2026. Our guide to the OWASP Top 10 for Agentic Applications gives a test for each agentic risk and both sets of LLM IDs.
  • OWASP is unsure prompt injection can be fully prevented, so passing items 16 to 20 covers the routes you found and tested.
  • It isn’t a penetration test (our comparison of AI red teaming and penetration testing says when you need one), legal advice or a certification.
  • A sign-off covers one release on one date, and any change on the reopen list (item 38) reopens it.

If you’d rather we did this

Our ten-day production readiness review runs the eval, tool and MCP, prompt injection and operational checks on this list for a fixed USD 10,000, and ends in a written go/no-go verdict. The eval suite stays in your repository and CI.

Sources

All pages accessed 19 October 2026.