OWASP's Top 10 for Agentic Applications, Read by a Risk Officer

You may be asked to accept an agent that can release a payment, update a customer record, or call a tool that changes live data. OWASP published the OWASP Top 10 for Agentic Applications for 2026 in December 2025. It describes the document as a framework for the most critical security risks facing autonomous and agentic AI systems. Treat it as a risk map, not as proof that each permitted action had authority behind it.

OWASP Top 10 Agentic Applications as a risk map

OWASP’s own summary is a useful place to start because it is narrower than the claims vendors often make around it.

The OWASP Top 10 for Agentic Applications 2026 is a globally peer-reviewed framework that identifies the most critical security risks facing autonomous and agentic AI systems.

— OWASP Top 10 for Agentic Applications for 2026, December 2025

That sentence supports a security reading. It does not support a compliance shortcut. It says the framework identifies risks. It does not say that adopting the framework proves who authorised an agent to change a credit limit, delete a record, or release a refund.

OWASP also says the Top 10 distils GenAI security guidance into an accessible operational format and gives builders, defenders, and decision-makers a starting point for reducing agentic AI risks. A starting point is not a finished control set. A decision-maker can use it to ask better questions, but the hard question remains the same: when an allowed action later becomes disputed, where is the record of the authority that allowed it?

The OWASP announcement says the project had already discussed excessive agency and wanted to go deeper into the security aspects of Agentic AI applications. That matters for risk owners because excessive agency often presents as an authorization problem, even when the security team describes it as an attack path. If an agent can approve a refund beyond its remit because the tool accepts the call, the failure is not only that the tool was reachable. The failure is that the permission boundary did not carry enough authority to say no.

There is a limit to the claim. The available OWASP summary does not give a board-ready answer to every control question. OWASP says its Agentic Skills Top 10 document and the complete detail pages should be reviewed for full risk descriptions, attack scenarios, and OWASP mappings. So a risk owner should not read a landing page, tick a policy box, and move on. The work is in the detail pages, the system design, and the evidence retained after actions complete.

The better use is adversarial. Ask whether each risk is about intrusion, unsafe reasoning, excessive permission, weak review, or missing evidence. Some will be classic security failures. Some will be authorization failures wearing a security label. Some will be both. That distinction matters because a blocked attack and an authorised payment require different proof.

OWASP Agentic AI controls and the permission gap

The phrase “OWASP agentic AI controls” can mislead if it is treated as a shopping list. OWASP’s page says the Top 10 equips builders, defenders, and decision-makers with a starting point for reducing risks and supporting safe deployments. It does not say that a risk owner can infer action-level accountability from the existence of those controls.

Start with the tool boundary. OWASP says a Practical Guide for Secure MCP Server Development provides guidance for securing Model Context Protocol servers, described as the connection point between AI assistants and external tools, APIs, and data sources. That is plainly relevant where an agent can write to a payment system, create a support ticket, or pull customer data into a workflow. It is still not the whole answer.

Securing the connection point can stop some bad calls. It can also shape what tools are exposed. But a connection control does not automatically prove that the particular approved call was permitted under the right policy, by the right person or system, for the right reason. A system can be well protected at the edge and still poor at explaining why a specific permitted action happened.

The Model Context Protocol point is important enough that it should sit in the risk register, not only in engineering notes, because agent tool calls are where abstract policy turns into a concrete change. Keeping the permission question visible when teams discuss tools and agents is the discipline that matters here.

OWASP’s Agentic Skills work reinforces the same point from another angle. It says attention has gone to large language models and the Model Context Protocol tool layer, while the intermediate behaviour layer in agentic skills has become vulnerable and under-protected.

While significant attention has been devoted to securing large language models (LLMs) and the Model Context Protocol (MCP) tool layer, the intermediate behavior layer —embodied in agentic skills—has emerged as a particularly vulnerable and under-protected component of the AI agent ecosystem.

— OWASP Agentic Skills Top 10, public review draft

That sentence cuts against a common simplification. You cannot secure only the model and declare the agent safe. You cannot secure only the tool connection and declare the agent accountable. The behaviour that selects a tool, frames a request, and continues after partial results is where permission can become vague.

OWASP says that behavioural abstraction layer creates security challenges that cannot be addressed by securing either the model or the protocol layer alone. A risk officer should read that as a warning against control theatre. If the organisation cannot show why an agent had authority to perform the action it performed, the organisation has not solved the control problem; it has only moved it to a layer with better vocabulary.

OWASP Agentic Top 10 beside skills and MCP

The search phrase “OWASP agentic top 10” now points to more than one artefact. OWASP describes the OWASP Top 10 for Agentic Applications for 2026 as a framework for autonomous and agentic AI systems. OWASP describes its Agentic Skills Top 10 — still an incubator project in public review, not settled guidance — as documenting the most critical security risks in agentic AI skills across major AI agent platforms.

Those are adjacent, not identical. One frames agentic applications. The other frames skills. OWASP also presents the OWASP AIVSS project as a sibling initiative focused on scoring the severity of agentic AI vulnerabilities. For a risk owner, the practical reading is simple: the field is splitting the agent problem into layers, and a single checklist will not carry all of the accountability work.

The Agentic Security Initiative page says the AIUC-1 Crosswalk of the OWASP Top 10 for Agentic Applications provides a bidirectional mapping between AIUC-1 requirements and the OWASP Agentic Security Initiative’s Top 10. That is useful for mapping. It is not an action record. A crosswalk can tell you how two frameworks relate. It cannot tell you who allowed an agent to approve a supplier payment at a particular moment.

OWASP says the GenAI Security Project is a global open-source initiative dedicated to identifying, mitigating, and documenting security and safety risks associated with generative AI technologies, including large language models, agentic AI systems, and AI-driven applications. That breadth is valuable. It also means the material will not answer every firm-specific evidence question. If a disputed event comes down to a single allowed action, “we followed OWASP” is a control statement, not evidence about that action.

This is where the security and risk readings separate. Security asks whether the agent could be induced to do something dangerous. Risk asks who accepted the authority for what the agent did when it was not blocked. The first question is about prevention. The second is about accountability. Both matter, but they are not the same control.

OWASP’s own language supports that split. The announcement says the Agentic Top 10 distils a new reality into a framework with actionable mitigations and architectural blueprints. Mitigations and blueprints are design aids. Evidence is an artefact left by a decision. If the artefact is missing, the blueprint may still be sound, but the assurance file is weak.

What this means if you have to produce evidence

Assume an agent has changed a customer’s credit limit. The system log shows the update. The agent transcript shows the reasoning. The access layer shows the tool call was allowed. None of those, alone, answers the question a risk owner will be asked: who authorised that particular change?

OWASP helps frame the risk that such a failure may occur. It does not, by itself, create the record that proves the permission behind the action. That is not a criticism of OWASP. A security framework is not an evidence store, and it should not be sold as one.

The distinction is easy to test. Pick one action that would matter if challenged: a deleted record, a changed payment destination, a customer refund, or an infrastructure change. Ask for the artefact that names the request, the decision, and the authority behind the decision. If the answer is a transcript, you have a narrative. If the answer is a system log, you have an event record. If the answer names the policy or human approval that permitted the action, you are closer to evidence.

For the same evidence question, see MAS SAFR evidence analysis. A related piece, Verifiable AI Compliance for Singapore Financial Services: Navigating the SAFR Era, takes the same evidence problem through the financial-services lens.

There is another limit. A permission record does not make the original policy good. It can prove that a weak policy allowed a bad action. That is uncomfortable, but it is better than the alternative, because an organisation can fix a weak policy once it can see the authority chain that produced the result.

Practical steps for risk owners

1. Name the agent actions that matter. Do not start with the model. Start with the action: release payment, change address, delete record, raise limit, or approve refund.
2. Map each action to the OWASP risk discussion. Use the OWASP Top 10 for Agentic Applications as the risk map for autonomous and agentic AI systems. Do not turn the map into proof. A map tells you where to look; it does not show who approved the journey.
3. Separate attack prevention from permission evidence. A control that blocks a malicious tool call is necessary. It is not the same as a record showing why a permitted tool call was allowed. The allowed call is the one most likely to require explanation later.
4. Include the behaviour layer. OWASP says agentic skills create security challenges that cannot be addressed by securing either the model or the protocol layer alone. Review the skill or workflow that chooses the action, not only the tool that executes it.
5. Check declared scope. OWASP’s Agentic Skills material tells teams to declare permissions accurately and not understate scope. That is an authorization issue, not merely a documentation issue, because understated scope makes later accountability harder.
6. Demand an artefact for allowed actions. For each sensitive action, require a record that links the request, the decision, and the authority. A transcript may help investigation. It should not be the only proof.
7. Test the rejected path and the approved path. Blocking a forbidden action proves one control worked. Approving an allowed action should also leave evidence of why it was allowed. Most assurance work focuses on the first path because it is easier to demonstrate.
8. Keep the human review question specific. If human approval is required, define what the reviewer saw and what decision they made. A structured AI decision review workflow makes that definition repeatable instead of ad hoc.
9. Review architecture claims against records. OWASP refers to actionable mitigations and architectural blueprints for the Agentic Top 10. Treat those as design inputs. Then ask what record survives the action.
10. Do not cite OWASP as a substitute for your own answer. OWASP can justify why a risk is on the register. It cannot, by itself, prove why your agent changed a customer record at a particular time.

The practical position is narrow: use OWASP to structure the risk discussion, then put a runtime permission step in front of agent actions that touch systems of record. GREENLIGHT is Crelis’s version of that step — sensitive agent actions are routed through Crelis, and only what policy allows is carried out. Crelis describes the layer as sitting in front of AI agent actions and able to allow, require human approval, escalate, or block in real time, with tamper-evident proof. The product demonstration is where the evidence question becomes concrete.

Crelis holds no SOC 2, ISO 27001 or ISO 42001 certification, and claims none.

Related reading

• MAS SAFR evidence analysis — what Singapore’s MAS SAFR white paper actually asks you to evidence, and what it doesn’t.
• Model Context Protocol — Crelis notes on agent tool calls and permission records.
• High-risk AI output review — a checklist for review before consequential outputs move into action.