AI Agent Security Checklist: 15 Checks Before You Ship

Why agents need their own checklist

Normal application security asks, "Can someone break into this software?" That still matters. But with AI agents, the bigger question is different: what can this agent actually do with everything it has been given?

An agent can have a valid API key, approved tools, and clean code, and still be talked into doing something you never intended. The model reads text from users, websites, emails, and documents, and it can't reliably tell your instructions apart from instructions hidden in that text. So the safety of an agent depends less on how well it behaves on a good day and more on how much harm it can do on a bad one.

The OWASP Top 10 for LLM Applications names this risk directly as "excessive agency": giving a model more tools, permissions, or independence than its job needs. Most of the checks below are about shrinking that.

Tools and permissions

1. List every tool and what it can touch

Write down every tool, function, plugin, and MCP server the agent can call, and what each one can read, change, or send. Include anything a tool can reach indirectly. A "search docs" tool that runs on a server with database access is effectively a database tool. You can't secure what you haven't listed, and this list usually turns up a tool nobody remembers adding.

2. Give each tool the smallest permission that works

If the agent only needs to read orders, its credentials should not be able to delete them. Use separate, narrowly scoped keys per tool instead of one admin key for everything. Wildcard scopes such as *, admin, or full_access are the most common problem we find.

3. Separate reading from doing

Split tools that look things up from tools that change things. A "manage customer" tool that can both read and delete is harder to limit than a get_customer tool and a separate, tightly guarded delete_customer tool. Small, single-purpose tools make every later check easier.

4. Put hard limits on where money and data can go

For any tool that pays, refunds, transfers, emails, or exports, set limits the agent can't talk its way around: a maximum amount, an allowlist of destination accounts or email domains, and a cap per day. These limits belong in your code or in the downstream service, never only in the prompt.

Secrets and credentials

5. No secrets in the code or config

API keys, database passwords, and payment keys should come from a secrets manager or environment at runtime, never from source code, notebooks, or checked-in config files. Hardcoded keys are exposed to anyone with access to the repository, its history, or a leaked copy of it.

6. Never put secrets where the model can see them

Don't paste keys, tokens, or internal URLs into the system prompt or the agent's context "so it can use them." Anything in the context can be repeated back to a user who asks cleverly. Let your tool code hold the credentials and let the model ask the tool to act.

7. Scope, expire, and rotate agent credentials

Give each agent its own credentials, so you can see what it did and shut it off without breaking anything else. Prefer short-lived tokens, and have a tested way to rotate every key the agent uses.

Untrusted input and prompt injection

8. Treat everything the agent reads as untrusted

User messages are obvious. Less obvious: web pages, emails, PDFs, support tickets, calendar invites, file names, and the results of other tools can all carry hidden instructions. This is called indirect prompt injection, and it's the main way agents get turned against their owners. Assume any outside text may be trying to give your agent orders.

9. Keep instructions and data apart

Mark clearly which parts of the context are your instructions and which are outside content, and tell the model never to follow instructions found in the outside content. This won't stop a determined attacker, but it cuts down on accidental and low-effort attacks. Our guide on stopping prompt injection goes deeper.

10. Check every tool call in code before it runs

The model chooses which tool to call and what arguments to pass. Your code should check that choice before acting on it: is this tool allowed for this user, are the arguments within limits, is the target on the allowlist? Treat the model's output like input from an untrusted user, because after a prompt injection, that's exactly what it is.

Approvals for high-risk actions

11. Require a human for actions you can't undo

Decide which actions are high-risk, such as payments, deletes, sending outside the company, changing permissions, and deploying code, and require a person to approve them. Show the approver exactly what will happen ("Refund $480 to card ending 4421"), not just "the agent wants to issue a refund."

12. Make approvals impossible to fake or replay

An approval only helps if the system that carries out the action checks it. The approval should be tied to the exact action and amount, expire quickly, and work only once, so a captured request can't be sent again to repeat a transfer. This is what A2SPA does: every high-risk action carries a signed approval, and the protected system refuses anything without a valid one. "No signature, no execution."

Limits and logging

13. Cap how much the agent can do

Set rate limits, timeouts, maximum steps per task, and spending caps on model and API usage. Without them, a loop or an attack can run up a large bill or hammer a downstream system. OWASP calls this "unbounded consumption."

14. Log every action with enough detail to investigate

For every tool call, record which agent made it, for which user, with what arguments, whether it was allowed or blocked, and what happened. If something goes wrong, this log is how you find out what the agent did and what it touched. Keep it somewhere the agent itself can't edit.

15. Test it like an attacker, on every release

Before launch, try to break it: hide instructions in a document the agent will read, ask it to reveal its prompt, ask it to act for another user, and push its limits. Then automate a scan so every new tool or permission is checked before it ships. Agents change often, and each new tool can reopen a hole you closed.

The whole checklist on one screen

• Every tool, and what it can reach, is listed.
• Each tool has the smallest permission that works. No wildcard or admin scopes.
• Reading tools and doing tools are separate.
• Money and data have hard limits and allowlists in code.
• No secrets in code, notebooks, or checked-in config.
• No secrets in the prompt or context.
• Each agent has its own short-lived, rotatable credentials.
• All outside content is treated as untrusted.
• Instructions and outside data are clearly separated.
• Every tool call is checked in code before it runs.
• A human approves actions that can't be undone.
• Approvals are tied to the exact action, expire, and work only once.
• Rate limits, timeouts, step limits, and spending caps are set.
• Every action is logged where the agent can't change it.
• The agent is attack-tested before launch and scanned on every release.

If you can tick all 15, you're ahead of most teams shipping agents today. If you can't, start with checks 2, 4, 5, and 11. They prevent the most expensive failures.

Common questions