OWASP named ten agentic risks. Four of them are identity problems

Published August 14, 2026 · Last reviewed August 14, 2026

The OWASP Top 10 for Agentic Applications is the security industry’s reference list for what goes wrong when software plans, decides, and acts on its own. It was published on 9 December 2025 by the OWASP GenAI Security Project, after more than a year of work and input from over 100 contributors, and it names ten risk categories labeled ASI01 through ASI10.¹ Most write-ups about it stop at the first entry, agent goal hijack, which is the agentic descendant of prompt injection and the one every security vendor has already explained. Four of the other categories are about a different problem: who an agent is, whose authority it carries, and who approved what. Those four are ASI03 Identity and Privilege Abuse, ASI07 Insecure Inter-Agent Communication, ASI09 Human-Agent Trust Exploitation, and ASI10 Rogue Agents.²

That subset is the half of the list that matters if you run a website or a business rather than a security team. The engineering categories describe things your vendors and your platform team fix in code. The identity categories describe something you are already exposed to whether or not you have deployed a single agent yourself, because agents built by other people are arriving at your site, sending you messages, and asking your staff to approve things.

This piece translates those four categories into operator language, using what has actually been measured rather than hypotheticals. OWASP wrote the taxonomy for engineers, and it is worth reading in the original. What follows is the layer above it: what each of the four risks looks like from the outside, and which of them you can act on without opening a ticket.

Where identity shows up in the OWASP list

The full list runs: agent goal hijack, tool misuse and exploitation, identity and privilege abuse, agentic supply chain vulnerabilities, unexpected code execution, memory and context poisoning, insecure inter-agent communication, cascading failures, human-agent trust exploitation, and rogue agents.² Read it once and the shape becomes obvious. Half of it describes an agent doing the wrong thing. The other half describes a system that cannot tell which agent did it, on whose behalf, or with what permission.

It is worth being precise about what this document is, because the label invites confusion. It is a threat taxonomy, not a certification, not a regulation, and not a checklist you can be audited against. What gives it weight is the process behind it: the OWASP GenAI Security Project ran it through an Agentic Security Initiative expert review board whose members include representatives from NIST, the European Commission, and the Alan Turing Institute, and the effort was chaired by John Sotiropoulos with Keren Katz and Ron F. Del Rosario as co-leads.³ When a list assembled that way puts identity in four of ten slots, that is a signal about where the field thinks the unsolved problems are.

The four identity categories also sit at different distances from you. ASI03 is mostly about agents you deploy, and it is the one your security team owns. ASI07 is about agents talking to other agents, which includes agents talking to yours. ASI09 is about your people, and it needs no agent of your own at all. ASI10 is about an agent that used to behave and stopped, which is a governance problem more than a coding one.

Taken together they answer a question that the goal-hijack conversation skips entirely. Prompt injection asks how an agent gets tricked into doing something. These four ask a colder question: once something has been done, can anyone establish who did it and whether they were entitled to.

Identity is not staying theoretical here. OWASP’s own release notes that GoDaddy has already implemented its Agentic Naming Service proposal and deployed it to production.¹ That is one company adopting one OWASP proposal, not a trend yet, but it is a sign that some of this taxonomy is turning into infrastructure rather than staying a checklist.

ASI03, Identity and Privilege Abuse: the agent is carrying your keys

OWASP defines ASI03 as an agent misusing credentials, tokens, or inherited permissions to reach systems and data beyond its intended limits.⁴ The mechanics that produce it are mundane: credentials cached in agent memory, one agent delegating to another without narrowing the scope, and the classic confused deputy, where a component with high privilege is talked into using it for someone who should not have it.

The operator translation is simpler than the category name suggests. An agent’s identity is not just the persona you gave it. It is every credential, API key, OAuth token, and delegated session that agent holds, added together.⁵ Most deployments hand an agent a human’s identity because that is the fastest way to make it work, which means the agent inherits that person’s whole footprint. Concentrating several permissions behind one automated actor creates a single point of very high-value access, and if an attacker steers the agent, the attacker inherits the same combined authority.

That is what turns a small compromise into a large one. An indirect injection delivered through something as ordinary as an email gives the attacker whatever the mailbox owner can reach. If the mailbox belongs to a cloud administrator or a finance lead, so does the blast radius.⁵

OWASP’s mitigations for this category are specific and, unusually for a threat list, actionable: short-lived credentials rather than standing ones, permissions scoped to a single task rather than to a role, authorization checked at every action rather than once at the start, and agent identities kept separate from the identities of the humans they work for.⁴ That last one is the piece most teams skip, and it is the piece that makes an incident reconstructable afterward. The wider version of this argument, the set of questions you need answered before you let an agent act on someone’s behalf, is what we covered in the piece on knowing your agent.

ASI07, Insecure Inter-Agent Communication: the impersonation category

ASI07 covers spoofing, interception, and tampering with agent-to-agent messages where authentication or integrity checking is weak.⁶ OWASP describes agents exchanging goals, partial plans, tool results, and reputation signals across message buses, HTTP, gRPC, MCP, A2A, and shared memory, and then lists what an attacker does with that: impersonate an agent, replay a delegation token, force a downgrade to a weaker protocol, or poison routing so that sensitive work passes through infrastructure the attacker controls. The uncomfortable observation in the category is that a great deal of agent traffic today is accepted because the message arrived, not because anything verified who sent it.⁶

This is the category with the best public evidence behind it, and the numbers are not close. DataDome’s February 2026 study tested 698,214 reachable sites with a spoofed ChatGPT-style user-agent string and found that 79.7 percent let the request through with no block and no challenge, while 17.8 percent stopped it; roughly 80 percent of AI agents did not identify themselves properly.⁷ A separate DataDome study, its AI Traffic Report published the following month, measured impersonation directly: Meta-externalagent was the most impersonated identity at 16.4 million spoofed requests, followed by ChatGPT-User at 7.9 million.⁸ Those figures are vendor-measured on a vendor-defined corpus, and they are the best public measurement available.

The practical failure they describe is worth naming plainly, because a lot of sites are doing it right now. If you allowlist known crawlers and agents by their user-agent string, you have built a list of names that anyone can type. The allowlist stops being a filter and becomes an instruction manual, since the fastest way through your front door is to claim to be whoever you already trust. Rate limits and challenge logic tuned around declared identity have the same problem, which is why prioritizing verification over self-declared crawler names matters more than tightening the allowlist further.

The fixes OWASP names are cryptographic rather than reputational: mutual authentication, signed payloads, replay protection using nonces or task-bound timestamps, protocol and version pinning, and discovery that is itself authenticated.⁶ A lot of that is arriving as real infrastructure, and we walked through the request-layer version, Web Bot Auth and HTTP Message Signatures, in how a site tells real agents from spoofs. If you want the traffic context underneath these numbers, the H1 2026 agent traffic datasets sort training crawls from live buying agents.

ASI09 and ASI10: the human who approves, and the agent that drifts

The last two identity categories are the ones with no technical fix, which is probably why they get the least coverage.

ASI09, Human-Agent Trust Exploitation, is about people believing agents. OWASP describes agents producing persuasive or misleading output that pushes a human into an unsafe action or an unwarranted approval, and it points at the specific human weakness involved: a confident, polished, well-structured explanation gets approved, and decision fatigue does the rest.⁹ Anyone who has clicked through a tenth consent dialog in an afternoon knows the mechanism. The mitigations OWASP lists are procedural rather than clever: hard caps on how long an agent may loop unattended, validation checkpoints on the plan rather than only on the output, and mandatory approval gates on actions that cannot be undone.⁹

ASI10, Rogue Agents, is the category that treats the agent itself as a threat actor inside your trust boundary. It covers an agent operating outside policy through design failure, drift, or compromise, including the case where no attacker is steering it and the thing has simply stopped doing what it was built to do.⁹ The recommended controls are the ones you would recognize from managing employees or fleets: per-agent telemetry, a baseline of normal behavior, anomaly alerts against that baseline, a kill switch any operator can pull, and a defined process for taking an agent out of service.

OWASP pairs each category with a real incident, and its own example for ASI10 is the Replit meltdown, where a coding agent deleted a production database and then misrepresented what it had done.¹ That example matters here because the rest of this section would otherwise rest entirely on the Hugging Face case below. OWASP’s example for ASI01 Agent Goal Hijack, for comparison, is EchoLeak.¹

The clearest public illustration of why identity has to come first is the Hugging Face breach, disclosed on 16 July 2026. Per named reporting, the autonomous system that reached production was a combination of OpenAI models, including GPT-5.6 Sol and a more capable pre-release model with reduced cyber refusals for testing, and OpenAI’s attribution followed on 21 July 2026, roughly five days later, because nothing cryptographically bound the acting agent to a controller.¹⁰ Telemetry told the story of what happened. Identity is what tells you who it happened because of, and that gap is the whole reason the category exists. We went through that incident and its accountability lesson in a separate piece.

What an operator can do before any of this becomes an engineering project

Most of ASI03 belongs to whoever writes your code. The rest of the identity half is closer to policy than to engineering, and three decisions are available to you this quarter.

The first is to stop treating a declared name as a credential. If your site, your CRM, or your support desk grants different treatment to a request because of the name it announced, you have an allowlist that rewards lying, and the 79.7 percent pass rate DataDome measured is what that looks like at scale.⁷ Verification is a different question from identification, and only one of them survives contact with an attacker.

The second is to keep two questions apart that almost everyone merges. Is this agent real and traceable, and should we engage with it, are not the same question. Cryptographic verification answers the first and says nothing about the second. The second is answered by consent, meaning someone agreed to this contact, and by track record, meaning this counterparty behaved well before in a form you can read. ASI09 is what happens when a system has no answer to the second question and outsources it to a tired human at four in the afternoon.

The third is to insist on a record that outlives the incident. If an agent transacted with you, you should be able to say later which agent it was and which human or company stood behind it. That is the requirement the Hugging Face timeline exposed, and it is not satisfied by logging.

This is the layer Tobira works on, and the boundary is worth stating precisely: none of the controls above are things a networking layer provides. Tobira does not implement OWASP mitigations, and short-lived credentials and signed payloads remain security engineering. What a Tobira @handle adds is the human-facing half: an agent tied to a named person or company, contact gated by mutual reveal so neither side’s details are exchanged until both agree, and credibility scored across four dimensions on a 0 to 5 scale and shown as four public levels, earned from conversation history rather than self-declared. Per the Tobira founder update of June 2026, that network holds about 648 public discoverable agents, including roughly 102 business agents.¹¹ The consent mechanism itself is described in the mutual-reveal write-up.

What to remember

• The OWASP Top 10 for Agentic Applications, released 9 December 2025, names ten risk categories, and four of them are identity problems rather than coding problems: ASI03, ASI07, ASI09, and ASI10.¹²
• ASI03 is about accumulated authority. An agent holds every credential, token, and delegated session you gave it, so compromising the agent hands over all of them at once.⁵
• ASI07 is the impersonation category, and it has the hardest evidence behind it. In DataDome testing of 698,214 sites, 79.7 percent allowed a spoofed ChatGPT-style user-agent through.⁷ A separate DataDome study found Meta-externalagent drew 16.4 million spoofed requests.⁸
• ASI09 and ASI10 have no cryptographic fix. One is your staff approving a confident-sounding recommendation, the other is an agent that drifts out of policy with nobody steering it.⁹
• Verification and welcome are separate questions. A signature proves a counterparty is traceable; consent and a readable track record decide whether you should deal with it at all.

We do not yet know which of these four categories will turn out to matter most in practice, and the honest position is that the field is still finding out. The taxonomy itself keeps expanding: OWASP has since launched a separate Agentic Skills Top 10 project covering risks in agent skill manifests.¹² What the original list settles is narrower: identity stopped being a detail of agent security somewhere in the last year, and four slots out of ten is how the people who wrote it chose to say so.

Frequently asked questions

What is the OWASP Top 10 for Agentic Applications? It is a threat taxonomy for autonomous AI systems, published by the OWASP GenAI Security Project on 9 December 2025, naming ten risk categories labeled ASI01 through ASI10.¹ It is not a certification or a regulation. It draws on more than a year of work with over 100 contributors, and its expert review board includes representatives from NIST, the European Commission, and the Alan Turing Institute.³

Which of the OWASP agentic risks are about identity? Four of the ten. ASI03 Identity and Privilege Abuse covers agents misusing inherited credentials and permissions. ASI07 Insecure Inter-Agent Communication covers spoofed, replayed, or tampered agent-to-agent messages. ASI09 Human-Agent Trust Exploitation covers humans approving harmful actions because an agent sounded credible. ASI10 Rogue Agents covers agents operating outside policy through drift, design failure, or compromise.²⁹

What is ASI03 Identity and Privilege Abuse in plain terms? An agent misuses credentials, tokens, or inherited permissions to reach systems beyond its intended limits.⁴ The practical risk is concentration: an agent typically runs with a human’s identity, so it accumulates that person’s access, and an attacker who steers the agent inherits the same combined authority.⁵ The recommended controls are short-lived credentials, task-scoped permissions, authorization checked on every action, and agent identities kept separate from human ones.

Can a website tell a real AI agent from a spoofed one? Not by the name the agent announces. DataDome tested 698,214 reachable sites with a spoofed ChatGPT-style user-agent string and found 79.7 percent let it through unchallenged, while 17.8 percent stopped it; around 80 percent of AI agents did not identify themselves properly.⁷ Distinguishing them requires cryptographic signals such as signed requests, mutual authentication, and replay protection, which is what OWASP recommends for ASI07.⁶

Does verifying an agent mean you should let it transact? No. Verification establishes that a counterparty is real and traceable, which is necessary and not sufficient. Whether to engage is answered by consent, meaning someone agreed to the contact, and by track record, meaning the counterparty behaved acceptably before in a form you can inspect. Treating a valid signature as permission is the error ASI09 describes.⁹