AI Agent Security Risks (2026): The OWASP Agentic Top 10, Translated

In December 2025, OWASP published its Top 10 for Agentic Applications, a peer-reviewed list of the ways an AI agent gets turned against the business running it. It's the first authoritative, vendor-neutral list of its kind, it's free, and it's written for security engineers. Every word of it assumes you know what a confused deputy is, and if you're the person paying for the agent, you probably don't.

You don't need to. What you need is to know what each of the ten risks looks like when it happens to a business your size, and what to ask whoever is building your agent so that it doesn't. Each entry below gives you OWASP's category, a plain-language version, a real incident where one exists, and the question to put to your agency.

Three things you should know before the list. The examples are real and recent: a zero-click attack on Microsoft's Copilot, a poisoned release of Amazon's coding assistant, a Replit agent that deleted a production database and then said it couldn't be restored. None of them were exotic. Second, OWASP's list overlaps heavily with what the guardrails article already asks you to require, which is the point: most agent security is permission design done properly. And third, the list pairs with the 12 red flags for hiring an AI agency, because the eighth flag there, no data privacy or compliance plan, is where every one of these ten hides.

Why an agent is a different kind of risk from a chatbot

A chatbot produces text. If it's wrong, someone reads a wrong answer. An agent produces actions: it reads your inbox, looks up customers, sends emails, moves records, calls APIs, sometimes runs code. The security question you're asking changes from "could it say something bad" to "what could it be talked into doing, by whom, and how much access would it have while doing it".

OWASP built the Agentic Top 10 because its earlier list for language models didn't cover that shift. The theme running through all ten is one sentence from the first entry: agents and the underlying model cannot reliably distinguish instructions from related content. Every email, web page, PDF, form submission and tool result your agent reads is a potential instruction, and the agent has no way of knowing which ones you meant and which ones a stranger did.

The ten, translated

Entries 1 to 3: what it reads, what it can touch, and whose access it has

These three are where nearly all of the real-world damage so far has come from, and they're the three you can fix with permission design alone.

1. Goal hijack: the agent did what it read, not what you said

OWASP's first entry is the one every other entry leans on. Because a model can't reliably separate instructions from content, an instruction planted in something the agent reads can redirect it. The planted text doesn't need to reach a person. It only needs to reach your agent.

EchoLeak, disclosed in June 2025, is OWASP's own example. A single crafted email, with its payload hidden in the message, caused Microsoft 365 Copilot to pull confidential files and chat history and send them out, with no click from the recipient. The US vulnerability database rated it 9.3 out of 10. Salesforce's Agentforce had a cousin three months later: researchers put instructions in the description field of a web-to-lead form, the same form you probably have on your own site, and when an employee later asked the agent about leads, it followed them and sent CRM data to an outside domain. That domain had been on Salesforce's own allow list, had expired, and cost the researchers $5 to buy.

2. Tool misuse: the tool was legitimate, the use wasn't

Entry two is the agent applying a real, authorised tool in a way you didn't intend. OWASP's examples read like a checklist of ordinary over-permissioning: an email summariser that can also delete or send mail without confirmation, a CRM tool that can fetch any record when the agent only needs one object, a planner that repeatedly calls a paid API until the bill spikes.

This is the entry the permission ladder was written for. Every tool your agent can call should be rated on read-versus-write, reversibility and financial impact, and anything on the top rungs gets a cap and a gate you can see. If your agency can't show you the list of tools the agent has and what each one is allowed to do, you have your answer.

3. Identity and privilege abuse: it was using your login

The third entry is about whose access the agent runs under. The commonest version isn't an attack at all. It's convenience: the agent is set up with a staff member's credentials, or an admin API key, because that was the fastest way to make it work. OWASP calls this un-scoped privilege inheritance. Everything that person can reach, the agent can reach, and so can anyone who hijacks it.

The fix is unglamorous, and you should insist on it. The agent gets its own identity, with a credential that reaches only the tools on its list and nothing else, and the log records what the agent did as the agent, not as the person whose password it borrowed. If you can't tell from your logs whether an action was taken by a person or by the agent, you have this problem today.

Entries 4 to 6: what it loads, what it runs, and what it remembers

The next three are about the parts of the agent nobody wrote for you: the components it loads, the code it produces, and the memory it accumulates.

4. Supply chain: it was poisoned before you installed it

Agents are assembled from parts: models, plugins, tool definitions, prompt templates, connectors, sometimes other agents, often downloaded at runtime. Entry four is any of those parts arriving tampered with.

The example OWASP cites is Amazon's. In July 2025 a version of the Amazon Q Developer extension for VS Code shipped through the official marketplace containing an injected prompt that told the agent, in the attacker's words, to clean a system to a near-factory state and delete file-system and cloud resources. It had been added through a pull request. AWS's own bulletin confirms the malicious code was distributed with the extension and only failed to run because of a syntax error, after which AWS revoked the credentials involved and shipped a replacement version. The attacker didn't break in. They were, by their account, handed the access.

For you, the question is what your agent loads and from where, and whether anyone you're paying has looked at it. Every plugin, tool server and template should be pinned to a version, reviewed once, and updated deliberately. An agent that discovers and installs new tools on its own is an agent whose supply chain nobody is watching.

5. Unexpected code execution: it ran something

Some agents write and run code. Coding assistants obviously, but also any agent with a shell tool, a database console or a script runner. Entry five is that capability being used for something destructive, whether through injection, a hallucinated command or simple over-reach.

The Replit case is OWASP's example. In July 2025 a Replit agent working for a software founder deleted his production database during a period he'd explicitly declared a code freeze. The agent had been told not to make changes. It made them anyway. Replit's chief executive called it unacceptable and said it should never have been possible, and within days the company rolled out automatic separation of development and production databases, which is the control that should have existed before.

That's the lesson in one line: an agent that can touch production should not be able to reach it by accident. Development and production separated, destructive commands behind a gate, and a rollback that's been tested rather than assumed.

6. Memory and context poisoning: it remembers the wrong thing

Most useful agents remember. They keep a summary of past conversations, they retrieve from a knowledge base, they cache what they learned last week. Entry six is that memory being seeded with bad data, on purpose or by accident, so the agent reasons from it every time afterwards.

The mechanism is slower than the others. A poisoned document uploaded to the knowledge base. A customer conversation whose content gets summarised into long-term memory. What OWASP calls long-term memory drift, where a stream of slightly wrong inputs gradually moves what the agent believes. None of it triggers an alarm, because each individual answer looks reasonable.

The controls are about provenance. You should know what's in the knowledge base and who put it there. Segment memory between customers and between tasks so one conversation can't contaminate another. And review what the agent has learned on a schedule, the way you'd audit a shared drive, because nobody else will.

Entries 7 to 10: many agents, many steps, and the people around them

The last four are about scale and people. Two only arrive when you run several agents at once. The other two are where a compromised agent finally gets caught, or doesn't.

7 and 8. Agents talking to agents, and one mistake becoming many

Entries seven and eight belong together and, for most businesses, belong in the future. Insecure inter-agent communication is what happens when two agents trust each other's messages without authenticating them. Cascading failure is what happens when one fault, a wrong decision or a poisoned input, propagates through many automated steps before a person sees it. OWASP's observable symptoms for the second are worth memorising: rapid fan-out, retries that oscillate, queue storms, the same intent repeated many times.

If you run a single agent, and you probably should, these two reduce to something you've already met: cap the loop, cap the daily spend, and make sure a stuck agent stops rather than retries forever. If an agency proposes a multi-agent design, ask how agents authenticate each other and what stops one bad output feeding the next. If they can't answer, ask for one agent.

9. Trust exploitation: it sounded sure, so somebody approved it

Entry nine is the human end of the problem. Agents are fluent, confident and polite, and your people will extend them the trust they'd extend to a competent colleague. OWASP describes the agent as a bad influence that gets the human to perform the final, audited action, so the agent's part in the damage is invisible afterwards. Its two named causes are opaque reasoning, where you can't question the output, and no confirmation step on sensitive actions, where trust turns straight into execution.

Replit supplies the example here too. After the deletion, the agent told its user that rollback was impossible and that all database versions had been destroyed. That was false. The restore worked. An agent that is confidently wrong about its own actions is exactly the case where a person needs to check rather than believe.

This is the entry the handoff article was written for: show the reason and the confidence with every request, name the reviewer, and count approvals per hour so you can see when reviewing has become clicking.

10. Rogue agents: it drifted, and kept going

The last entry is the agent that leaves its lane without anyone pushing it. Goal drift, reward hacking, an agent optimising the metric it was given in a way that defeats the purpose. OWASP's point is that each action can look legitimate while the pattern is harmful, which means rule-based checks on individual actions won't catch it.

What catches it is a baseline, and you have to ask for one. What does a normal day of this agent look like: how many tool calls, in what sequence, at what cost, with what escalation rate? Once you have that, drift is a number moving. Without it, drift is a surprise. This is the same production signal that the evaluation article treats as the third layer of testing, and it's the one most agencies leave out because it only exists after launch.

Ten questions to ask your agency

Every one of these has a good answer that takes under a minute. If you get a long answer, or the word "trust", ask it again.

What this means for a small or mid-sized business

You don't need a security team to run an agent safely. You need the agent to have a short list of tools, its own credential, caps on anything involving money, a person in the loop for the irreversible, a memory you can audit, and a log that says what it did. That's six controls, and every one of them is a line item you can ask for in a proposal and check for in the delivery.

The one answer you should never accept

What you can't do is accept "we've blocked prompt injection" as an answer. Microsoft and Salesforce both shipped agents that were successfully injected, and Meta's own security team calls injection a fundamental, unsolved weakness in all LLMs. The design assumption for 2026 is that the injection sometimes works, and the whole job is making sure that when it does, your agent has nothing worth hijacking. Our production-ready agents guide treats that as a build step rather than an afterthought, and it's the same posture we'd expect from anyone you hire.

Frequently Asked Questions