AI agent security: a 10-point checklist before your agent goes live
Ten checks we run before an AI agent gets real tools and real users: what it can reach, where outside text gets in, permissions, approvals, secrets, MCP servers, logs and tests.
Hussain C · 5 min read
Most AI agent security problems are decided before anyone writes a prompt. They come from what the agent is allowed to reach, and who gets to put text in front of it.
This is the checklist we run before an agent gets real tools and real users. If you can answer all ten with confidence, you're in better shape than most teams we meet.
The checklist at a glance
| # | Check | Why it matters | How we test it |
|---|---|---|---|
| 1 | What can the agent reach? | You can't protect what nobody has listed | Map every tool, database, inbox and MCP server |
| 2 | Where does outside text get in? | Every one is a way to slip in instructions | Trace emails, uploads, web pages and tool results |
| 3 | Does each tool have the least power it needs? | A tricked agent can only do what its tools allow | Try to make each tool act outside its job |
| 4 | Do risky actions wait for a person? | Approval turns a breach into a blocked request | Attempt sends, refunds and deletes without approval |
| 5 | Are secrets out of the model's reach? | Anything in the prompt can be talked out of it | Ask for keys, prompts and config in many ways |
| 6 | What does each MCP server expose? | It sets what the AI can read and change | Review sign-in, scopes and every tool it lists |
| 7 | Is every tool call logged? | Without logs you can't tell what happened | Check one attack shows up end to end |
| 8 | Has someone attacked it on purpose? | Users will find what the team didn't | Hand-written and automated prompt injection |
| 9 | Does the test run again on every release? | New prompts and models reopen old holes | Attacks kept as tests in CI |
| 10 | What happens when something gets through? | Speed matters more than blame | Walk through the plan with the team |
1. What can the agent reach?
Write the list down. Every tool, every API key, every database table, every inbox and every MCP server. Teams are often surprised by its length, because tools get added one sprint at a time and nobody steps back.
The list is also your blast radius. If the agent is fooled tomorrow, this is everything the attacker gets to use.
2. Where does outside text get in?
Prompt injection is instructions hidden in text the agent reads. OWASP ranks it as the top risk for apps built on language models, and it can arrive anywhere the agent reads something your company didn't write: customer emails, uploaded PDFs and CVs, web pages it browses, even a product review pulled from your own database.
We trace each of these paths before testing anything. The chat box is usually the least interesting one.
3. Least power for every tool
A tool that reads orders shouldn't also cancel them. A support agent should only see the customer it's talking to. Split broad tools into narrow ones, and check permissions on the server, inside the tool, every time it runs. A permission that only exists in the prompt is a suggestion.
4. A person before anything risky
Anything that sends a message outside the company, moves money, deletes data or changes a permission waits for a click from a human. It feels slow at first. In our projects the approvals come off one at a time, once the logs show a given action is reliably right.
5. Secrets stay out of reach
API keys, database passwords and internal URLs belong in the tool code and environment settings, never in the prompt or the context. If the model can't see a secret, no clever message can get it to repeat one.
6. Review every MCP server
An MCP server is a standard connector that lets AI apps like Claude or ChatGPT use your systems. It's also a door. We check that each person signs in, that the server starts read-only, that each tool does only what its name says, and that third-party servers aren't given more access than the job needs. See MCP server development for how we build them.
7. Log every tool call
Who asked, which tool ran, with what input, and what came back. When something odd happens, this is the difference between an answer in ten minutes and a week of guessing.
8. Attack it on purpose
Before launch, someone should try to break the agent the way a stranger would. We write attacks for your specific tools by hand, because those find the serious problems, then add automated runs of known patterns for breadth. All of it runs on a staging copy, so nothing real is sent, deleted or charged.
9. Test again on every release
Every successful attack becomes a test. Those tests run in CI before each release, so a new prompt, a new tool or a model upgrade can't quietly reopen a hole you already closed.
10. Know what you'll do when one gets through
Who gets told, how you switch off a tool quickly, and how you check what the agent did in the meantime. Write it down and walk through it once. We learned the same lesson building the guardrails for an AI platform where non-coders build businesses: when people can't read what the AI made, the checks have to live in the platform.
Where to start if you're short on time
Do numbers 4 and 5 this week. An approval step on risky actions and secrets moved out of the prompt close the worst cases quickly. Then book the rest.
If you'd like a second pair of eyes, our AI security testing runs this whole list against a copy of your system, fixes what we find and hands the attacks over as tests. Or tell us what your agent can do and we'll say where we'd look first.
Frequently asked questions
How do you secure an AI agent?
Limit what each tool can do, ask a person before anything that sends, pays or deletes, keep secrets out of the model's reach, treat any text from outside the company as data, log every tool call, and test the agent with real attacks before launch and on every release.
What is the biggest security risk for AI agents?
Prompt injection: instructions hidden in text the agent reads, like an email, web page or uploaded file, that the model then follows. OWASP ranks it first on its list of risks for applications built on large language models. It matters most when the agent has tools that can act.
Do MCP servers need a security review?
Yes. An MCP server decides what an AI app can read and change in your systems, so it deserves the same review as any API you'd open to a new employee: sign-in, per-person permissions, read-only by default and a log of every call.
How often should an AI agent be security tested?
Before launch, then again whenever it gets a new tool, a new data source, a new model or a big prompt change. Keeping the attacks as an automated test set makes the re-test cheap enough to run on every release.