OWASP Guidance on AI Agents, Explained for Non-Specialists

OWASP’s guidance on AI agents comes from its GenAI Security Project, and two documents carry most of it. The OWASP Top 10 for Agentic Applications, published in December 2025↗ (opens in a new tab) by the project’s Agentic Security Initiative, lists ten risks from ASI01 Agent Goal Hijack to ASI10 Rogue Agents. The OWASP Top 10 for LLM Applications covers the model itself, and its entry on Excessive Agency is the one most often quoted about agents. For a small team, six ideas from the two lists do most of the work: treat everything an agent reads as untrusted, give it fewer tools and permissions, give it an identity of its own, keep secrets out of its context, run its code in a sandbox, and do not let a confident agent talk a person into approving something.

OWASP also has a separate, still-beta Top 10 for MCP. That one is covered in MCP security risks, so it is left out here.

What OWASP publishes on agents

• The OWASP Top 10 for LLM Applications↗ (opens in a new tab). The 2025 edition, published in November 2024, is the one most security writing still cites. A 2026 edition followed in August 2026, reordered using incident data as well as practitioners’ votes.
• The OWASP Top 10 for Agentic Applications 2026↗ (opens in a new tab), announced on 9 December 2025. Ten entries numbered ASI01 to ASI10, each with a description, examples, attack scenarios and mitigations.
• Agentic AI – Threats and Mitigations, the Agentic Security Initiative’s detailed taxonomy, first released in February 2025. The agentic Top 10 says it relies on it and maps each entry back to it.

The 2026 LLM list↗ (opens in a new tab) draws the boundary between the two clearly. It owns the risk while the model is a component inside your application. Once the model becomes an actor, with tools it can call, memory it carries between sessions and consequences downstream, the risk moves to the agentic list. Most teams using Claude Code, Cursor or a browser agent are firmly on the agentic side.

The idea behind both lists: least agency

Security people know least privilege: give an account only the permissions it needs. The agentic Top 10 extends that to least agency, which it describes as advice to avoid unnecessary autonomy, because agentic behaviour deployed where it is not needed expands the attack surface without adding value. It pairs that with observability: without clear visibility into what agents are doing and which tools they call, small problems can grow quietly. If you remember only one thing from OWASP, remember those two.

The entries that matter to a small team

Agent Goal Hijack (ASI01) and Prompt Injection (LLM01)

In plain English: someone changes what your agent is trying to do by putting instructions in something it reads, such as a web page, an email, a calendar invite or a shared document. OWASP’s description is blunt: agents cannot reliably tell instructions from content. Prompt injection is LLM01 in both editions of the LLM list, and the agentic entry covers the bigger effect, where the whole multi-step plan is redirected rather than one answer.

One control: an agent that reads outside content must not also be able to take high-impact actions without a person approving them. OWASP’s own mitigations pair least privilege for the agent’s tools with human approval for high-impact or goal-changing actions.

Excessive Agency (LLM06:2025, now LLM03:2026)

In plain English: the agent can do more than its job needs, so when it goes wrong, for any reason, the damage is bigger. OWASP traces it to three causes↗ (opens in a new tab): excessive functionality, excessive permissions and excessive autonomy. One of its examples will be familiar to anyone who has tried a few tools: a tool was trialled, replaced by a better one, and the original was never removed. In the 2026 edition this entry rose to third, and the list explains why: agentic deployments are where the damage is landing.

One control: once a quarter, list every tool and connection each agent has and remove the ones it has not used. OWASP’s first mitigation is simply “minimize tools”.

Tool Misuse and Exploitation (ASI02)

In plain English: the agent uses a tool it is genuinely allowed to use, in a way nobody wanted, such as deleting valuable data or calling an expensive service in a loop. It is different from the agent gaining extra rights; it stays inside its permissions and still causes harm.

One control: for destructive actions, see what will happen before it happens. OWASP recommends human confirmation for delete, transfer and publish actions, with a dry run or a preview of the change shown before approval.

Identity and Privilege Abuse (ASI03)

In plain English: the agent borrows someone’s identity, or picks up credentials along the way, and ends up able to do more than anyone intended. OWASP names the root cause as an attribution gap: without a distinct, governed identity of its own, least privilege for an agent cannot really be enforced.

One control: every agent gets its own narrowly scoped credential, per tool, that can be revoked without touching the person it works for. Roles and permissions for humans and AI agents shows what that looks like on a board.

Sensitive Information Disclosure (LLM02) and Hidden Context Exposure (LLM08:2026)

In plain English: whatever you put into an agent’s instructions or context can come back out. The 2026 list renamed System Prompt Leakage to Hidden Context Exposure and gives the practical rule: do not embed credentials or secrets in system prompts or hidden context, and assume everything available to the model could also be available to users.

One control: no secret goes into a rules file, a prompt or a shared note an agent reads. Keep secrets in the systems that need them, where the agent cannot read them.

Unexpected Code Execution (ASI05)

In plain English: an agent that writes and runs code can be steered into running something harmful, and because the code is generated on the spot, the usual checks may never see it. OWASP names coding tools directly here.

One control: agent-run code goes in a sandbox, never as root, with its file access and network limited. AI agent security best practices walks through doing that with Claude Code.

Memory and Context Poisoning (ASI06)

In plain English: someone slips false or malicious information into what the agent remembers or looks up, and every later session is steered by it. For a small team, the memory is usually a shared notes file, a rules file or a knowledge base the agent reads before it starts.

One control: know who wrote each shared note, and read the new ones. OWASP’s mitigations include requiring source attribution and not letting an agent feed its own output back into trusted memory unchecked.

Human-Agent Trust Exploitation (ASI09)

In plain English: the agent sounds sure of itself, so a person approves what it proposes without checking, and the harmful action is taken by the person. OWASP calls out automation bias and notes that the agent’s role can then be invisible to anyone investigating afterwards.

One control: approve on evidence, not on the agent’s explanation. OWASP suggests plain-language risk summaries rather than model-generated rationales. On a team, that means a test result, a diff or a screenshot, which is the approach in human in the loop for AI agents.

The rest of the agentic list, briefly

• ASI04 Agentic Supply Chain Vulnerabilities: tools, plugins and servers you did not write. For MCP servers specifically, see the MCP posts linked above.
• ASI07 Insecure Inter-Agent Communication and ASI08 Cascading Failures: mostly relevant once agents hand work to other agents automatically. Worth reading when you get there.
• ASI10 Rogue Agents: an agent drifting from what it was meant to do without an attacker involved. The defence is the same observability the whole list asks for.

From list to controls on one page

ASI01 / LLM01  Agents reading outside content need approval for high-impact actions
LLM03:2026     Remove unused tools and connections every quarter
ASI02          Preview and confirm deletes, transfers and publishes
ASI03          One revocable credential per agent, per tool
LLM08:2026     No secrets in prompts, rules files or shared notes
ASI05          Agent-run code in a sandbox, never as root
ASI06          Shared notes are signed; new ones get read
ASI09          Approve on evidence, not on the agent's explanation

Keep the page with your team’s agent policy, and check it during your monthly audit.

How a board covers part of this

On fenbs several of these controls are built in for the board itself. An assistant holds the role of the person who connected it, narrowed by the scopes read, write and comment, and revoking its token stops it without signing that person out (ASI03). Moving tasks between lanes is a permission of its own, so an assistant can write and comment without moving anything (ASI01, ASI02). AI context notes are signed by whoever wrote them, person or assistant (ASI06). And every change is recorded in History with who made it, which is the observability the agentic list asks for.