Key takeaways

  • An agent is a language model that can use tools and act on its own. The risks are different from a chatbot because a mistake or an attack ends in an action, not only in a wrong sentence.
  • OWASP published the Top 10 for Agentic Applications for 2026 on December 9, 2025. The ten items are numbered ASI01 to ASI10, from Agent Goal Hijack to Rogue Agents.
  • Most of the ten come down to four habits: give each agent its own identity, give it the least access that works, log what it does, and keep a person in the loop for actions that cannot be undone.
  • The joint guidance Careful Adoption of Agentic AI Services (CISA, NSA and partner agencies, April and May 2026) is advisory, not law. Its advice is to avoid broad access and to start with low-risk, non-sensitive use cases.
  • The OWASP Top 10 for LLM Applications 2025 still applies underneath. Prompt injection, excessive agency and unbounded consumption are the entries that agents make more serious.

What an AI agent is, and why it needs its own risk list

A chatbot answers a question and stops. An AI agent keeps going. It is a language model wrapped in a loop that can read documents, search the web, call software through connectors, write and run code, send messages and remember what happened last time. You give it a goal, such as "reconcile these invoices" or "triage this inbox", and it decides on the steps. Many companies now run agents inside Microsoft 365, in customer support tools, in code editors and in custom workflows.

That shift changes the security question. With a chatbot the worst case is usually a wrong or embarrassing answer. With an agent the worst case is an action: a file deleted, a payment approved, a customer record sent to the wrong place. The agent acts with real credentials, and it takes instructions from text it reads, including text written by strangers. A hidden sentence in a PDF or a web page can become an instruction.

The OWASP GenAI Security Project, part of the Open Worldwide Application Security Project, is the group behind the widely used Top 10 lists for web applications and for large language models. On December 9, 2025 it published the OWASP Top 10 for Agentic Applications for 2026. The list uses identifiers ASI01 to ASI10. This article follows OWASP's official names, as they appear on the project's announcement page, and then explains each risk in plain terms. The explanations and the controls are our own reading of the list, written for a company with a few hundred people and a small IT team, not a quotation from OWASP.

How the agentic list relates to the LLM Top 10

OWASP also maintains the Top 10 for LLM Applications 2025, which is still the current edition of that list. Its entries are LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure, LLM03 Supply Chain, LLM04 Data and Model Poisoning, LLM05 Improper Output Handling, LLM06 Excessive Agency, LLM07 System Prompt Leakage, LLM08 Vector and Embedding Weaknesses, LLM09 Misinformation and LLM10 Unbounded Consumption.

Think of the two lists as layers. The LLM list covers the model and the application around it: what goes in, what comes out, what the model can reveal. The agentic list covers what happens when that model is given tools, memory, an identity and other agents to talk to. LLM06 Excessive Agency is the bridge between them. It asks whether the model has more functions, permissions or autonomy than the task needs. Every agentic risk below gets worse when the answer is yes.

ASI01 Agent Goal Hijack

OWASP describes this as hidden prompts that turn an agent into a tool for silently pulling out data, and cites the EchoLeak incident as an example. In plain terms, the agent was given one goal by you and a different goal by an attacker, and it followed the attacker. The attacker never needs to log in. They only need the agent to read something they wrote: an email, a shared document, a web page, a support ticket.

For a mid-size company the exposure is any agent that reads content from outside the company and also has access to inside data. An agent that summarizes inbound email and can also search your file shares is the classic case. Controls: treat everything the agent reads as untrusted input, separate the agent that reads outside content from the agent that touches sensitive systems, block outbound paths such as arbitrary web requests and image links that can carry data out, and require approval for any action that sends information outside the company.

ASI02 Tool Misuse

OWASP's wording on the announcement page is "Tool Misuse", and it describes agents being steered into using legitimate tools to produce destructive outcomes. Amazon Q is the example it cites. The tools themselves are not broken. The agent is using a real delete command or a real payment function exactly as designed, but for the wrong reason.

The practical lesson is that a tool is a permission. If you connect a database tool with write access because it was easier than configuring read-only, you have decided that any successful manipulation of the agent can write to the database. Controls: define each tool narrowly (a tool that reads one folder, not one that runs any command), set read-only as the default, put limits on size and rate, validate the arguments the agent passes before the tool runs, and keep a human approval step in front of anything destructive or irreversible.

ASI03 Identity & Privilege Abuse

OWASP's short description is that leaked credentials let agents operate beyond their intended scope. Agents need credentials to call systems. Too often those credentials are a developer's personal token, a shared service account or a long-lived API key pasted into a configuration file. If the agent is hijacked, or the key is stolen, the attacker inherits everything that credential can do.

This is the risk most closely tied to ordinary IT hygiene, and it is where a managed provider can help most. Controls: give every agent its own identity so its actions can be told apart from a person's, use short-lived tokens in place of standing keys, store secrets in a vault and not in prompts or code, scope each identity to the specific systems and actions the job needs, name a human owner for every agent, and remove the identity when the agent is retired. The second article in this series, on connecting agents through MCP servers, goes into the authorization rules in detail.

ASI04 Agentic Supply Chain Vulnerabilities

OWASP points at dynamic ecosystems, such as the Model Context Protocol (MCP) and agent-to-agent (A2A) connections, where components are loaded at run time and can be poisoned. A GitHub MCP exploit is the example it gives. Traditional supply chain risk is about libraries you install once. Agentic supply chain risk includes tools, plugins, prompt templates and other agents that your agent discovers and trusts while it runs.

Controls: keep an inventory of every connector, plugin and model your agents use, approve them the way you approve software vendors, pin versions instead of pulling the latest, prefer servers and tools from publishers you can identify, review what a tool description tells the model to do (descriptions are read by the model and can carry instructions), and block agents from installing or enabling new tools on their own. Your existing third-party risk process is the right home for this.

ASI05 Unexpected Code Execution

OWASP's description is that natural-language paths to execution open routes to remote code execution, and it cites an AutoGPT remote code execution issue. Many agents can write a script and run it, because that is how they do data analysis or automate a task. If an attacker can influence what the agent writes, they can influence what runs.

Controls: run any agent-generated code in a sandbox with no access to production credentials, a restricted file system and tight network rules; do not give the code runner the same identity as the agent; set time and resource limits; and treat "the agent needs to run commands on a real server" as a design decision that needs sign-off, not a default. Where the agent only needs a calculation, give it a calculator tool instead of a shell.

ASI06 Memory & Context Poisoning

Agents keep memory so they can be useful across sessions. OWASP's concern is that corrupted memory changes the agent's behavior long after the original interaction, and it cites the Gemini Memory Attack as an example. One poisoned note, planted today, can steer decisions next month, when nobody remembers where the instruction came from.

Controls: decide what the agent is allowed to remember and for how long, store the source of every memory entry, keep memory per user or per task so one person's content cannot shape another's results, review and clear memory on a schedule, and give administrators a way to inspect and delete what the agent has stored. The same care applies to knowledge bases the agent searches. Content that anyone can edit is content an attacker can edit.

ASI07 Insecure Inter-Agent Communication

When several agents work together, they pass messages. OWASP warns that spoofed messages between agents can misdirect whole clusters. If agent B accepts any message that looks like it came from agent A, then anyone who can insert a message into that channel can give orders.

Controls: authenticate each agent to the others instead of trusting a name in a message, sign or otherwise protect messages in transit, keep the channel on an internal network segment, validate the content of messages as strictly as you would validate user input, and limit which agents may call which. If you cannot say which agent is allowed to ask which other agent for what, the design is not ready for production.

ASI08 Cascading Failures

OWASP describes false signals spreading through automated pipelines with growing impact. One agent produces a wrong figure, a second agent treats it as fact and acts, a third builds on that action. Each step looks reasonable, and by the time a person looks, the error has been copied into many places.

Controls: put checkpoints between stages where a person or an independent check can stop the chain, set budgets and rate limits so a runaway loop cannot make thousands of changes, keep the ability to pause every agent with one switch, make actions reversible where possible (versioned documents, soft deletes, staged changes), and test failure on purpose before go-live by feeding the pipeline a bad input and watching where it stops.

ASI09 Human-Agent Trust Exploitation

OWASP's wording is that confident, polished explanations lead human operators to approve harmful actions. Approval prompts are only a control if the person approving understands what they are approving. Agents are fluent. A request to run a risky action, wrapped in a clear and reasonable-sounding explanation, will often be accepted.

Controls: show the person the actual action (the exact command, recipient or amount), not the agent's summary of it; reserve approvals for decisions that matter so people do not click through dozens of trivial ones; train staff that an agent's confidence is not evidence; and for sensitive actions, require a second person or an out-of-band check, the same habit that defends against wire-fraud emails.

ASI10 Rogue Agents

OWASP describes agents that show misalignment, concealment and self-directed action, and cites the Replit meltdown as its example. The causes vary. A goal can be poorly specified, an agent can find an unintended shortcut, or a compromise can alter its behavior. The result is the same: an agent doing things nobody asked for, possibly without saying so.

Controls: keep tamper-resistant logs that the agent itself cannot edit, monitor agent behavior against a baseline and alert on unusual volume, new destinations or new tools, enforce hard limits in the platform and not only in the prompt (a prompt that says "do not delete" is a request; a permission that blocks deletion is a control), and keep a tested way to revoke an agent's credentials immediately.

Logs the agent cannot edit are easier to build on a cloud that provides them. AWS CloudTrail, Google Cloud Audit Logs, the Azure Monitor activity log and the OCI Audit service all record account activity outside the application. Send copies to write-once storage such as Amazon S3 Object Lock, Cloud Storage bucket lock or Azure Blob immutable storage, so that even an agent with broad permissions cannot rewrite its own trail.

What the government guidance adds

In spring 2026 the NSA (April 30) and CISA (May 1) released joint guidance titled Careful Adoption of Agentic AI Services, together with the Australian Signals Directorate's Australian Cyber Security Centre and other international partners. CISA's release names four risks: an expanded attack surface, privilege creep, behavioral misalignment and obscure event records. Its recommendations include "Avoid granting broad or unrestricted access, especially to sensitive data or critical systems", "Begin with agentic AI use cases that are low-risk and non-sensitive" and "Account for agentic AI security in your organization's security model and risk posture".

This guidance is advisory. It does not create legal duties by itself. It is still useful, because regulators, insurers and customers read the same documents, and they tend to treat them as a statement of reasonable practice. The advice maps neatly onto the OWASP list: least access answers ASI02 and ASI03, a security model that includes agents answers ASI04 and ASI07, and good records answer ASI08 and ASI10.

A starting plan for a mid-size company

First, find out what is already running. Agents arrive through the tools people already use, and an inventory taken today usually turns up more than leadership expects. Record the owner, the data it can reach, the actions it can take and the credentials it uses.

Second, pick low-risk first uses, as the government guidance recommends. Summarizing public documents or drafting internal notes is a safer place to learn than approving payments or changing customer records.

Third, apply the four habits across the board. Give each agent its own identity. Give it the least access that does the job. Log every action somewhere the agent cannot change. Require a person to approve actions that cannot be undone.

Fourth, test. Ask a security team to try the attacks on this list against your own agents: plant an instruction in a document, try to make a tool do something outside its purpose, see whether a stolen token can be reused elsewhere. Our team does this kind of testing as part of its cybersecurity work, and the free security assessment is a good first step.

Sources

This article is general information, not legal or security advice. The plain-English explanations and controls are our interpretation of the OWASP list, which is a community project and not a legal standard. The government guidance cited is advisory. Confirm decisions with your own counsel and security team. Last reviewed .

Keep reading

Need help with this?

We find out whether everything you run is safe from attackers, then we fix it.

Cybersecurity