AI Agent Security Checklist: 12 Checks Before Production

An AI agent security checklist has to start from one uncomfortable fact: the model at the center of your agent cannot reliably tell instructions from data. The UK National Cyber Security Centre puts it plainly. Current large language models do not enforce a security boundary between instructions and data inside a prompt. NCSC Once you accept that, a lot of agent security stops being about clever prompts and becomes ordinary engineering: what can the agent touch, as whom, with whose approval, and who is watching.

This checklist is built from three primary sources: the OWASP Top 10 for LLM Applications (2025 edition, risk LLM06 Excessive Agency), the OWASP Top 10 for Agentic Applications for 2026, and the NCSC's December 2025 blog post on prompt injection. The twelve checks are our own synthesis of what those documents recommend. We have not tested these controls on a live system for this article, and where a point is our judgment we say so.

Why agents change the risk

OWASP describes a typical agent as an LLM-based system that has been given the ability to call functions or interface with other systems, which it calls extensions, tools, skills or plugins. The choice of which tool to call may be delegated to the model itself, and agent systems typically make repeated calls using the output of earlier ones. Source

That is why OWASP defines Excessive Agency as the vulnerability that lets damaging actions happen in response to unexpected, ambiguous or manipulated model output, whatever is causing the model to misbehave. Triggers include hallucination and direct or indirect prompt injection, including from a malicious tool or, in multi-agent systems, a compromised peer agent. Source

The NCSC adds the consequence. When a system calls tools or APIs based on the model's output, an attacker can coerce it to use them, so the impact of prompt injection becomes whatever the worst case would be if the attacker had direct access to those tools. Source

You probably cannot fully fix prompt injection

The NCSC argues against treating prompt injection like SQL injection. SQL injection can be fixed at the root with parameterised queries, because a database engine can be made to never read input as an instruction. Inside an LLM there is only "next token," so the NCSC says prompt injection may never be totally mitigated in the same way. Source

Its suggested framing is to see prompt injection as an "inherently confusable deputy." A classic confused deputy flaw can be fixed, but the NCSC argues LLMs are inherently confusable, so the work is to reduce risk and impact. If the system's security cannot tolerate the remaining risk, the NCSC says it may not be a good use case for LLMs. Source

For design, the NCSC says protections should focus on deterministic, non-LLM safeguards that constrain what the system can do, not only on trying to keep malicious content away from the model. It also quotes a simple rule from a public discussion between two practitioners: when an LLM processes information from a party, its privileges drop to those of that party. So an LLM reading emails from outsiders should not have privileged tools. Source

Two cautions from the same post are useful. Filters that block known-bad phrases such as "ignore previous instructions" are a weak defense, because there are endless ways to rephrase an attack. And products that claim to "stop" prompt injection deserve suspicion, while those that explain how they reduce it are more credible. Source

The checklist

1. List every tool the agent can call, and remove the ones it does not need

OWASP's first mitigation for Excessive Agency is to minimize extensions. If the system does not need to fetch URLs, it should not be offered a URL-fetching tool. It also lists a common cause: an extension tried during development and dropped for a better one, but still available to the agent. Source

2. Shrink what each tool can do

A tool built to summarize email only needs to read email, so it should not contain functions to send or delete. OWASP also advises avoiding open-ended tools such as "run a shell command" or "fetch any URL" and replacing them with narrow ones, such as a function that only writes a specific file. Source

3. Give each tool the least permission downstream

OWASP's example: an agent that makes purchase recommendations may only need read access to a products table, and that should be enforced through the database permissions of the identity the tool uses, not through the prompt. OWASP GenAI The Agentic Top 10 repeats this as per-tool least-privilege profiles covering scopes, maximum rate and egress allowlists, ideally written as access policy attached to each tool. Source

4. Run tools as the user, not as a master account

OWASP lists a generic high-privilege identity as a cause of excessive permissions: a tool meant to read the current user's documents that connects with an account that can read everyone's. The fix it gives is to execute actions in the specific user's context with minimum privileges, for example through OAuth with the smallest scope needed. Source

5. Give the agent its own identity, with short-lived credentials

The Agentic Top 10 says that without a distinct, governed identity, an agent operates in an attribution gap that makes true least privilege impossible. Its mitigations include short-lived, narrowly scoped tokens per task, per-agent identities, and binding permissions to subject, resource, purpose and duration. Source

6. Check every privileged action outside the model

OWASP calls this complete mediation: do authorization in downstream systems instead of relying on the LLM to decide if an action is allowed, and validate every request against security policy. OWASP GenAI The Agentic Top 10 describes a policy enforcement point that treats planner output as untrusted, validates intent and arguments, enforces schemas and rate limits, and issues short-lived credentials. Source

7. Require human approval for high-impact actions

Both OWASP documents ask for a human in the loop for actions that are destructive or hard to undo, such as delete, transfer or publish. The Agentic Top 10 adds that the person should see a pre-execution plan or a dry-run diff before approving. OWASP Agentic Top 10 In OWASP's mail example, the user manually reviews and presses send on every drafted message. Source

8. Cut the privileges of anything that reads untrusted content

This is the NCSC rule applied directly. An agent that reads outside emails, web pages, tickets or uploaded files should not hold tools that can send data out, spend money or change records. If one agent must do both jobs, split it into two with a narrow, checked handoff. The split is our reading of the principle. Source

9. Sandbox code execution and limit outbound network access

The Agentic Top 10 recommends running tool or code execution in isolated sandboxes, with an outbound allowlist that denies destinations not approved. OWASP Agentic Top 10 Its examples of tool misuse include an agent passing untrusted model output to a shell, or a research agent following a malicious link. Source

10. Treat memory and retrieved context as an attack surface

OWASP's Memory and Context Poisoning entry covers conversation history, memory tools and retrieval stores. Attackers can corrupt or seed that context with misleading data, which biases later reasoning, planning and tool use. Uploads, API feeds, user input and peer-agent exchanges may be untrusted or only partly validated. OWASP Agentic Top 10 Decide what can write to memory, and who can review or clear it.

11. Set budgets and rate limits

The Agentic Top 10 includes loop amplification among its examples: a planner repeatedly calling costly APIs and causing a denial of service or a bill spike. It recommends usage ceilings on cost, rate or tokens, with automatic throttling or revocation when exceeded. OWASP Agentic Top 10 OWASP's Excessive Agency page also says rate limiting will not prevent the problem but gives more time to catch it through monitoring. Source

12. Log enough to see an attack, and watch failed calls

The NCSC suggests logging enough to spot suspicious activity, potentially including the full input and output of the model along with tool use and API calls. It notes an attacker will probably have to refine the attack, so failed tool or API calls can reveal early stages. NCSC OWASP likewise recommends logging and monitoring extension and downstream activity. Source

A worked example from OWASP

OWASP's own scenario makes the checklist concrete. An assistant is given access to a mailbox to summarize incoming mail. The extension the developer chose also includes a send function, and the app is vulnerable to indirect prompt injection. A crafted email tells the model to scan the inbox for sensitive data and forward it to the attacker. Source

OWASP's fixes map onto checks 2, 4 and 7: use an extension that only reads mail, connect through OAuth with a read-only scope, and require the user to review and press send on any drafted message. It adds that rate limiting on the sending interface could reduce the damage. OWASP GenAI Notice that none of the fixes depend on detecting the malicious email.

Where to go from here

None of these sources can tell you which of the twelve checks your system fails today. That takes a look at your actual tools, identities and logs. If you want a place to start on the MCP side, see our post on MCP server security best practices, and for how permission gaps appear on a cloud platform, our look at agent permissions in AWS AgentCore. Our AgentOps services page covers tool access, permissions and monitoring for agents in production.