Secure AI agent deployment checklist: what to check before launch

How to use this AI agent security checklist

Work through each item before launch and record the answer, the owner and the evidence, such as a screenshot of a permission setting or a test result. An item nobody can answer counts as a finding. The list follows the main risks in the OWASP Top 10 for LLM Applications (opens in a new tab) (LLM stands for large language model) and the joint guidance on deploying AI systems securely (opens in a new tab) from cyber agencies in the United States, the United Kingdom, Australia, Canada and New Zealand.

Scope and ownership

Security starts with knowing what the agent is for and who answers for it.

• The agent's purpose, users and channels (voice, chat, email) are written down.
• A named business owner approves what the agent may do, and a named technical owner runs it.
• The tasks the agent must refuse or pass to a person are listed and agreed.
• Every system, tool and data source the agent touches is recorded in an inventory.
• A risk assessment covers what could go wrong with each task and who would be harmed.
• The agent has a version number, and each change to the model, prompts or tools is recorded.

Identity and access

Give the agent the access its task needs and nothing more. This principle, called least privilege, limits the damage when the agent is manipulated or makes a mistake. OWASP calls the risk of giving an agent too much power excessive agency (opens in a new tab) and traces it to too many tools, too many permissions or too much autonomy.

• Each agent has its own service account, separate from staff accounts and from other agents.
• Each integration uses its own credentials with the narrowest scope that works, for example read-only access to orders.
• No shared passwords, and no keys or tokens written into prompts, code or configuration files.
• Secrets live in a secrets vault or credential management system, are rotated on a schedule and are revoked when no longer needed.
• Where possible, the agent acts with the permissions of the customer or employee it serves, not with admin rights.
• Staff who administer the agent use multi-factor authentication (MFA), and admin access is separate from normal use.
• Access is reviewed before launch and again whenever a tool is added.

Our guide to AI agent permissions shows how to design these limits task by task.

Data protection

An AI agent reads and writes business data at high volume, so the rules for that data need to be explicit.

• The agent receives only the data its task needs. For personal data, this matches the data minimization principle in Article 5 of the GDPR (opens in a new tab).
• Retention periods are set for transcripts, recordings, logs and agent memory, and data is deleted when the period ends.
• You know where each provider processes and stores data, and the region matches your contracts and legal duties.
• The AI services run under business terms that, where available, exclude your inputs and outputs from model training.
• A data processing agreement (DPA) is in place with every provider that handles personal data on your behalf.
• The knowledge base respects existing access rights, so the agent cannot retrieve documents the user could not open.
• Payment card numbers, passwords and other secrets are masked or kept out of prompts and logs.

Tool and action controls

Tools let an AI agent act, not only answer. Control what it can call, what limits apply and when a person must approve.

• The agent can call only the tools and actions on an allow-list. Anything else is blocked.
• Code outside the model checks every tool input, for example amount limits, allowed account IDs and allowed email domains.
• Payments, refunds above a set amount, deletions, data exports and messages to outside recipients wait for a person's approval.
• The approval screen shows the person exactly what will happen, not only the agent's summary.
• Rate limits and spend caps apply per user, per conversation and per day, with an alert when a limit is reached.
• Any code the agent runs executes in an isolated sandbox with no access to internal systems.

Spend caps matter because attackers can run up your AI usage costs on purpose. OWASP calls this denial of wallet, part of its unbounded consumption (opens in a new tab) risk.

Prompt injection defenses

Prompt injection means tricking an AI with hidden instructions, typed by a user or hidden in an email, document or web page the agent reads. The UK's National Cyber Security Centre (NCSC) warns that it may never be fully mitigated (opens in a new tab), because language models do not reliably separate instructions from data. Plan for it to succeed sometimes, and limit what it can achieve.

• All outside content, including emails, files, web pages, tickets and tool results, is treated as untrusted.
• Content from untrusted sources cannot trigger high-impact actions without an approval or a code-level check.
• Untrusted content is clearly marked and kept apart from the agent's instructions in the prompt.
• Inputs are screened for known injection patterns, and suspicious ones are logged.
• The agent can send data only to addresses and links on an allow-list, which blocks a common way to move stolen data out.
• The system prompt holds no secrets, so a leak exposes no keys or internal data.

Our prompt injection guide covers attack examples and defenses in more depth.

Output safety and hand-off to a person

• The agent says it is an AI at the start of each conversation or call.
• It stays within its approved topics and declines legal, medical, financial or other advice outside its scope.
• It cannot promise prices, refunds, discounts or dates beyond your written policy.
• Answers come from approved sources, and the agent says so when it does not know.
• Output is checked before it reaches other systems, for example escaped before it appears in a web page or goes into a database. OWASP lists this as improper output handling (opens in a new tab).
• A customer can reach a person at any time, and that person receives a summary and the full history.
• Staff know that summaries can contain text written by the customer, and they verify claims such as identity before they act.

Logging, monitoring and alerting

The joint guidance advises collecting logs that cover inputs, outputs, intermediate states and errors, with automated alerts. Without them, you cannot investigate an incident or prove what the agent did.

• Each conversation is logged with its inputs, outputs, tool calls, approvals and errors.
• Logs are protected from changes and kept for a set period that fits your privacy rules.
• Alerts fire on unusual tool calls, injection attempts, volume spikes and sudden rises in AI usage costs.
• Someone reviews a sample of conversations every week and after each change.
• Quality measures, such as correct answers and hand-off rate, are tracked so a drop is visible.

Testing before launch

• The agent has been attack-tested for prompt injection, data leaks, tool misuse and jailbreaks. Our AI red teaming guide explains the method.
• Findings are fixed and retested before launch.
• A regression set of prompts and known attacks runs after every change to the model, prompts or tools.
• A model update gets a full evaluation, security tests included, before it goes live, as the joint guidance advises.
• An external team tests agents that handle payments, personal data or regulated work. The joint guidance recommends external experts for audits and penetration tests of AI systems.

Incident response and a kill switch

Decide before launch how you will stop the agent and what happens next.

• A kill switch lets a named person pause the agent, or disable single tools, within minutes and without a code release.
• When the agent is paused, customers reach a person or see a clear message.
• You can roll back to the last known good version of the model, prompts and configuration.
• The incident plan covers AI cases: prompt injection, data leaks, harmful output and runaway costs.
• The plan names who revokes credentials, who informs customers and who decides on reporting to regulators.
• The team has practiced the plan at least once, for example in a tabletop exercise.

Vendor and supply chain

An agent depends on a model provider and often on plug-ins, third-party tools and Model Context Protocol (MCP) servers, which connect agents to outside tools and data. Each one adds code and permissions your team did not write. OWASP lists supply chain risks for both LLM applications and AI agents.

• Every model, plug-in, MCP server and third-party tool is listed with its owner, version and permissions.
• Components come from trusted sources, and versions are pinned so updates are reviewed before use.
• Each component's permissions are checked against what the agent needs.
• Tool descriptions and results from third-party servers are treated as untrusted input.
• Each vendor's security, data handling and model training terms are reviewed and kept on file.

Our MCP security guide covers the checks for tool servers in detail.

Compliance touchpoints

The rules depend on where you operate and what the agent does. Check at least these points with your legal adviser:

• EU AI Act transparency: Article 50 of the AI Act (opens in a new tab) has applied since August 2, 2026. Providers must design AI systems that interact directly with people so those people know they are dealing with an AI, unless that is obvious. The information must be given at the latest at the first interaction. Our Article 50 guide explains who must do what.
• GDPR: if the GDPR applies to your processing, check your lawful basis, data minimization, retention limits, data protection by design (Article 25) and your contracts with processors (Article 28).
• Sector rules: health, financial, legal and other regulated data can bring extra duties, such as consent, record keeping or stricter access controls.
• Contracts: customer contracts and security questionnaires may ask how you test, monitor and control AI.

How we apply the checklist in our projects

In the secure launch stage of our projects, we go through each item with your team, close the gaps and attack-test the agent before it talks to a single customer. The agent runs on your own accounts, so you keep control of the keys, the logs and the kill switch. To record your answers, use the AI agent launch checklist template.