What OWASP's Agentic Threat Taxonomy Says About Authorization Failures

Your agent is about to release a payment, delete a customer record, or change a credit limit. The security team asks whether the model was compromised. The risk owner asks a colder question: who allowed that action to happen. OWASP’s agentic work helps with the first question, but it does not, by itself, close the second.

Agentic AI threats and mitigations as an authorization problem

OWASP’s starting point is explicit. The Agentic AI – Threats and Mitigations page was published by the OWASP Gen AI Security Project on 17 February 2025. It frames the work as a first guide from the OWASP Agentic Security Initiative to provide a threat-model-based reference for emerging agentic threats and to discuss mitigations.

"This document is the first in a series of guides from the OWASP Agentic Security Initiative (ASI) to provide a threat-model-based reference of emerging agentic threats and discuss mitigations."

— OWASP Gen AI Security Project, Agentic AI – Threats and Mitigations, 17 February 2025

That sentence is careful. It says threat model. It says threats. It says mitigations. It does not say audit trail, authorization record, approval chain, or proof that a particular action was allowed.

This distinction matters because an agent failure can arrive wearing two different uniforms. One looks like an attack. A tool is abused. Memory is poisoned. Identity is misused. The other looks like normal operation. The agent calls the right tool, under its own identity, and the downstream system accepts the request. The damage is still real if nobody authorised the payment, the deletion, or the change.

Security writing often collapses those cases because both produce an unwanted outcome. For the engineer in the incident room, that is tolerable. For the compliance officer, it is not. “The agent did the wrong thing” is a diagnosis only if the question is technical cause. It is not an answer to authority.

OWASP’s later descriptions keep the same emphasis. The OWASP Gen AI Security Project’s workshop page, published on 15 May 2025, says its takeaways emphasise threat modelling for agentic AI with a focus on securing memory, tools, and identity.

"Key takeaways emphasize the importance of threat modeling for agentic AI, with a focus on securing memory, tools, and identity, while advocating for proactive security measures that support innovation without stifling it."

— OWASP Gen AI Security Project, Agentic Security Open Workshop – Agentic AI Threats and Mitigations, 15 May 2025

Memory, tools, and identity are the right places to look. They are also not the whole control question. A memory control may reduce bad context. A tool control may reduce misuse. An identity control may tell you which agent acted. None of those facts, alone, proves that the action had authority when it executed.

The practical split is simple. Intrusion controls ask whether someone or something broke the system’s assumptions. Authorization controls ask whether the proposed action fitted the authority granted for that moment. Evidence controls ask whether you can still prove that answer after the model output, the tool call, and the operational trace have all moved on.

That is the gap hidden inside a phrase like “agentic AI threats and mitigations”. The phrase is useful for search, procurement, and first-pass risk classification. It is too broad for accountability. A deleted record caused by a compromised tool and a deleted record caused by an over-permitted agent may look identical in the system of record. They do not require the same evidence.

A related argument is narrower than the security market often wants. Runtime authorization is not the same thing as runtime security. Security tries to stop bad things. Authorization decides whether this specific thing may happen. Evidence preserves the decision so that someone outside the run can test it.

Agentic AI security controls at the point of action

OWASP’s agentic work later broadened into a control vocabulary around agentic applications. The Agentic Security Initiative page published on 18 August 2025 says that the OWASP Top 10 for Agentic Applications 2026 is a globally peer-reviewed framework identifying critical security risks facing autonomous and agentic AI systems. A later OWASP Gen AI Security Project page, published on 10 December 2025, says the OWASP Top 10 for Agentic Applications provides vulnerability descriptions, threat mappings, and mitigation guidance.

"The OWASP Top 10 for Agentic Applications provides clear, practical steps to address these issues through vulnerability descriptions, threat mappings, and mitigation guidance."

— OWASP GenAI Security Project Releases Top 10 Risks and Mitigations for Agentic AI Security, 10 December 2025

That is valuable. It gives security teams a shared way to describe risk. It gives builders a language for finding weak points before agents touch systems that matter. It also shows the limit of the category. A mitigation can reduce risk without leaving behind the authority record a reviewer needs.

Consider a payment release. A security control might verify the agent identity, constrain the tool, inspect the request, and block an obviously unsafe instruction. Good. Now change one fact. The payment is within a normal operational band, the tool is the expected one, and the agent identity is known. The remaining question is whether this payment, for this payee, under this policy, at this time, was authorised.

The answer cannot be recovered from identity alone. Identity is not authorization, and authorization is not evidence. That separation is annoying because it creates more work. It is also how disputes are decided.

The same split applies to a deleted record. If the record disappears after a credential theft, the intrusion story may dominate. If the record disappears because an agent was allowed to call a deletion tool but nobody approved that class of deletion, the failure is different. It is not mainly that the system failed to recognise the agent. It is that the system treated access as authority.

OWASP’s archive language shows the taxonomy moving from documents into tooling. An OWASP Agentic AI archive page says the Agentic AI – Threats and Mitigations taxonomy is powering developer tools that embed security into AI builder and red-team workflows. The same OWASP archive page says tools are adopting the OWASP ASI taxonomy to help teams test, defend, and build secure agentic systems.

That adoption is a reason to take the taxonomy seriously, not a reason to overload it. Testing and defence tools can find classes of weakness. They can give a team a better map of where an agent might be abused. They do not automatically answer who approved a particular consequential action.

This is where a control design either becomes accountable or stops at prevention. Blocking is useful. Blocking is not proof that every allowed action was authorised. The same point is made more directly in Enforcement Is Not Evidence.

There is an uncomfortable implication here. A control programme can look mature while still failing the evidence test. It can have inventories, identities, scanners, red-team tools, and incident playbooks. If a disputed action leaves no preserved decision record, the organisation may know a great deal about its threat surface and still be unable to show why the action was allowed.

Agentic AI control framework choices for evidence

Framework language is useful when it forces discipline. It is dangerous when it becomes a substitute for a control design. OWASP’s State of Agentic AI Security and Governance page was published on 2 June 2026 and describes the document as providing a comprehensive view of the landscape for securing and governing autonomous AI systems. That is field-level framing. It is not the same thing as an obligation on your system to retain action-level authorization evidence.

The OWASP Top 10 for Agentic Applications 2026 language points to a framework for identifying security risks. The release language for the OWASP Top 10 for Agentic Applications points to practical steps through vulnerability descriptions, threat mappings, and mitigation guidance. Those are necessary inputs to a control framework. They do not decide the architecture of proof.

An agentic AI control framework that cares about authorization evidence has to answer different questions. What actions require a live permission decision. What facts must be available before that decision is made. Which human or policy source can approve an exception. What record survives after the action completes.

That does not make the OWASP taxonomy deficient. A threat taxonomy should not pretend to be a records system. Its job is to name classes of risk and shape mitigations. The mistake is made downstream, when a team treats that taxonomy as if it has already specified the proof needed for contested action.

Here is the vendor position, stated once. Crelis’s GREENLIGHT material is explicit about the action boundary: depending on setup, either the agent has no direct route to the sensitive system or the system refuses sensitive actions that arrive without a valid Crelis permission ; systems that do not know about Crelis keep working as they do today while every action is checked and recorded ; and agent requests for sensitive actions are routed through Crelis, which carries out only what policy allows, while your systems do not change at all . Crelis describes the mechanism, shown in its product demonstration, as an in-path decision point that intercepts each proposed agent action before execution and produces both a decision and a record , and its knowledge base adds that MCP can authorize an individual tool call and can pause mid-call for a human decision, but cannot record which policy permitted the action or keep that record after the call returns. These are Crelis’s product claims, not OWASP requirements and not certification claims; they state the design point a risk owner should test for, whatever tool is used: the authorization decision sits before the consequential action and produces a retained record.

That design point is also why protocol-level permission is not enough. A tool-call permission and a durable authority record solve different problems, and only one of them survives after the call returns.

This matters most when the control works. A blocked action creates a clean story. An allowed action is harder. The organisation has to explain not only that the agent acted, but that the permission existed, matched the policy, and was not reconstructed after the dispute began.

The cleanest mental model is a record of authority, not just a log of events. A log says what happened. An authority record says why the system was allowed to make it happen. A reviewer can often tolerate a missing debug trace. A reviewer cannot tolerate a missing basis for a payment, deletion, or credit change.

What this means if you have to produce evidence

Start by refusing the easy answer. “We follow OWASP” may be true and still incomplete. The OWASP material gives a way to discuss agentic threats, risks, mitigations, and security controls. It does not, in the language cited above, say that a completed agent action is accompanied by a preserved proof of authority.

That is not a criticism of OWASP. It is a warning about scope. A document built for threat modelling should not be forced to do the job of an evidence system. The burden moves back to your control design.

A useful evidence file for an agent action needs more than a final outcome. It needs the proposed action, the acting identity, the relevant policy basis, the approval or escalation path, the decision, and the retained record tying those facts to the action. Leave out one of those elements and the story becomes contestable.

There is also a timing issue. Evidence created after a dispute is explanation, not authority. The record has to be created when the decision is made, before the payment is released or the record is deleted. Otherwise the reviewer is being asked to trust reconstruction.

The organisation should also separate operational comfort from defensibility. A dashboard can show that the agent acted as expected. A system event can show that a tool accepted the request. Neither tells the whole authorization story. They are useful exhibits, but they are not the permission itself.

This is why a pre-execution authorization layer is framed around the permission step rather than around model monitoring. The useful claim is narrow. It is about the point at which a proposed action becomes an authorised action, and about the record that survives that moment.

Practical steps for separating threats from authority

1. Split the register. Do not put every unwanted agent outcome into one bucket. Mark whether the scenario is an intrusion, a misuse of memory, a tool-control issue, an identity issue, or a permitted-looking action that lacks authority.
2. Map OWASP terms to action points. Use OWASP’s threat and mitigation language to find where the agent can touch memory, tools, and identity, then identify which of those touchpoints can change money, customers, records, or infrastructure.
3. Define consequential actions. Write down which agent actions cannot proceed on identity alone. A refund, a deletion, a credit-limit change, and an account closure should not inherit authority merely because the agent can reach the tool.
4. Put the decision before execution. Require a permission decision before the action reaches the sensitive system. If the control only explains the action after it happens, it is not an authorization control.
5. Record the basis, not only the outcome. Keep the policy basis, approval route, decision, and action together in one retained record, created at the moment the decision is made.
6. Test allowed actions. Red-team exercises often focus on blocked or malicious paths. Add tests for ordinary-looking allowed actions and ask whether the record proves the authority behind them.
7. Keep enforcement and evidence separate. A blocked action shows a control fired. An allowed action needs a different artefact: the preserved reason it was permitted.

The position this article argues is deliberately narrow: use OWASP to name agentic AI threats and mitigations, then add runtime authorization where an agent can take a consequential action. The action should not merely be observed after the fact; it should pass through a permission step that leaves tamper-evident evidence behind.

Crelis is patent-pending. It holds no SOC 2, ISO 27001 or ISO 42001 certification, and claims none.

Related reading

• Runtime Authorization vs Runtime Security — the split between stopping bad behaviour and deciding whether an action is allowed.
• Identity Is Not Authorization Is Not Evidence — the three questions that get collapsed when agents hold credentials.
• Enforcement Is Not Evidence — why a block decision is not proof that allowed actions had authority.
• AI Decision Review Workflow — a model for reviewing consequential AI decisions after they happen.