Skip to content

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 guide 2026 — prompt injection, least privilege and human approval

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:

  1. Access to private data
  2. Exposure to untrusted content
  3. 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.

Share
Working on something similar?

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

Leave a Reply

Your email address will not be published. Required fields are marked *