AI Agent Security: How to Deploy AI Agents Without Handing Attackers the Keys
Agents that read email, query your CRM and call APIs can be talked into things by a single document. Here are the risks that matter in 2026 and a practical checklist to deploy AI agents safely.
AI agent security is no longer a research topic. The moment an AI agent can read your inbox, query your CRM or call an API on your behalf, it inherits the same question every employee with system access raises: what is the worst thing it could do, and what stops it? The difference is that an agent can be talked into things by a web page, a PDF or an email it was only supposed to summarise.
This guide explains the risks that matter for businesses deploying agents in 2026, the frameworks security teams now use to reason about them, and a practical checklist you can apply before an agent touches production data.
Why AI agents need a different security model
A classic chatbot answers questions. An agent acts: it chooses tools, reads documents, writes to systems and chains those steps together without a human approving each one. That changes the threat model in three ways:
- Instructions and data share one channel. A language model cannot reliably tell the difference between “the user asked me to do this” and “a document I just read told me to do this”. Everything is text in the same context window.
- Agents hold real permissions. API keys, OAuth tokens and database credentials give the agent the same reach as the account it runs under.
- Mistakes compound. One wrong step in a multi-step plan feeds the next. A poisoned input early in the chain can steer everything after it.
Prompt injection: the risk that sits at the top of every list
Prompt injection is ranked first (LLM01) in the OWASP Top 10 for LLM Applications 2025. It comes in two forms:
- Direct injection — a user types instructions designed to override the system prompt (“ignore previous instructions and…”).
- Indirect injection — the malicious instruction is hidden in content the agent processes: a web page, a support ticket, a calendar invite, a product review, white text inside a PDF. The user never sees it; the agent does.
Indirect injection is the one that matters for agents. A support agent that reads incoming tickets and can also issue refunds is one cleverly written ticket away from issuing a refund nobody asked for.
The uncomfortable part: there is still no filter that solves this. In late 2025, a 14-author paper with researchers from OpenAI, Anthropic and Google DeepMind, The Attacker Moves Second, used adaptive attacks to bypass 12 recently published defences, most with success rates above 90%, as summarised by Simon Willison. The practical conclusion is to design systems that stay safe even when the model is fooled, rather than trying to make the model unfoolable.
Two mental models that actually help
The lethal trifecta
Simon Willison’s “lethal trifecta” describes when data theft becomes possible. An agent is at risk of leaking data when it combines all three:
- Access to private data
- Exposure to untrusted content
- The ability to communicate externally (send email, call a URL, post a message)
Remove any one leg and the exfiltration path closes.
Meta’s Agents Rule of Two
In October 2025 Meta proposed a broader version: within a single session, an agent should have no more than two of these three properties:
- (A) processes untrustworthy inputs
- (B) has access to sensitive systems or private data
- (C) can change state or communicate externally
If a workflow genuinely needs all three, it should not run autonomously — a human approves the risky step. This is a design rule you can apply in a planning meeting, before any code is written.
The OWASP Top 10 for Agentic Applications
In December 2025 the OWASP GenAI Security Project published the OWASP Top 10 for Agentic Applications, the first widely adopted checklist written specifically for agents. In plain language:
| ID | Risk | What it looks like in a business |
|---|---|---|
| ASI01 | Agent goal hijack | A document or email redirects the agent to a different task |
| ASI02 | Tool misuse | A legitimate tool (delete, refund, send) used in a harmful way |
| ASI03 | Identity & privilege abuse | The agent runs with an admin token it never needed |
| ASI04 | Agentic supply chain | A third-party plugin or MCP server behaves maliciously |
| ASI05 | Unexpected code execution | Generated code or commands run without a sandbox |
| ASI06 | Memory & context poisoning | False “facts” stored in memory influence later sessions |
| ASI07 | Insecure inter-agent communication | One agent trusts another agent’s output blindly |
| ASI08 | Cascading failures | A small error spreads across chained steps and systems |
| ASI09 | Human-agent trust exploitation | Users approve actions because “the AI said it was fine” |
| ASI10 | Rogue agents | An agent acting outside its intended scope over time |
A practical AI agent security checklist
These are the controls we apply when building agentic systems and MCP servers for clients. None of them depends on the model behaving perfectly.
1. Least privilege, per tool
Give the agent its own service account, never a human’s admin credentials. Scope each tool narrowly: “read invoices for this customer” instead of “query the database”. If a tool only needs to read, it should be physically unable to write.
2. Separate reading from acting
Split workflows so the component that reads untrusted content (emails, web pages, uploads) is not the same one that holds write permissions. Pass structured, validated data between them — an extracted amount and invoice number, not free text.
3. Human approval for irreversible actions
Payments, deletions, external emails, contract changes and anything above a value threshold go through an approval step. The agent prepares; a person confirms. This is the simplest way to satisfy the Rule of Two.
4. Close the exfiltration paths
Restrict outbound network calls to an allowlist. Don’t let the agent render arbitrary images or links in output that could carry data in a URL. Block tools that send messages to addresses outside your domain unless approved.
5. Treat MCP servers and plugins as dependencies
Every MCP server you connect is code with access to your agent’s context. Use servers you control or have reviewed, pin versions, and review tool descriptions — they are also instructions the model reads.
6. Validate every tool call
Check parameters server-side exactly as you would for a public API: types, ranges, ownership (“does this customer ID belong to the logged-in user?”), rate limits. Never trust a value just because the model produced it.
7. Log everything, and review it
Keep an audit log of every prompt, tool call, parameter and result. You will need it for debugging, for incident response and, for some systems, for compliance with the EU AI Act.
8. Test like an attacker
Before launch, red-team the agent with injected instructions in every input channel it reads. Re-run those tests after every model, prompt or tool change. Add them to the same evaluation suite you use for answer quality.
Example: securing an invoice-processing agent
Consider an agent that reads supplier invoices from a shared inbox and prepares payments — a common AI invoice processing project.
- Untrusted input: yes — anyone can email an invoice.
- Private data: yes — supplier records and bank details.
- State change: yes — payments.
All three properties, so it cannot run fully autonomously. A safe design: the extraction step reads the PDF and outputs structured fields only. A separate validation step matches the supplier against the existing vendor list and flags any changed bank account. Payments are drafted, never sent, until a finance user approves them. The agent saves hours of data entry; a fake “please update our IBAN” email still can’t move money.
Frequently asked questions
Can prompt injection be fully prevented?
Not with today’s models. Filters and guard models reduce risk but adaptive attackers get past them. Robust systems limit what a fooled agent can do: narrow permissions, approval for risky actions and no open exfiltration channels.
Is a private or self-hosted model safer?
It helps with data residency and confidentiality, but it does not fix prompt injection. A self-hosted model can be manipulated by a malicious document exactly like a hosted one. See our guide to a private LLM for business.
Are MCP servers a security risk?
They are an access path, like any API integration. A well-built MCP server with scoped permissions, input validation and logging is a safer way to connect AI to your systems than giving an agent raw database or admin access.
How much does it cost to secure an AI agent?
Most of the cost is design, not tooling: deciding permissions, approval steps and logging up front is far cheaper than retrofitting them. See our breakdown of AI agent cost for where the budget usually goes.
Build agents that are useful and safe
Shkulaku designs and builds AI agents and RAG systems with permissions, approvals and audit logs built in from day one — not bolted on after an incident. If you are planning an agent that will touch customer data, payments or internal systems, tell us what it needs to do. We will map the risks with you, suggest where a human should stay in the loop, and give you a clear written estimate. You can also review our starting prices for AI agents and MCP servers.
I take on a small number of projects at a time. Tell me what you are building and I will tell you honestly whether I am the right person for it.
Get in touch →
4 comments