State of Agentic AI Security and Governance: What the 2026 Report Records

A landscape report does one job. It names the terrain; it does not prove that a payment release, deleted record, or changed credit limit was authorised. OWASP published State of Agentic AI Security and Governance 2.01 on 2 June 2026, and describes it as a comprehensive view of the landscape for securing and governing autonomous AI systems. That gives security and governance teams a dated anchor for the agentic AI risk conversation. It cannot answer the later evidential dispute.

The state of agentic AI security, as OWASP frames it

OWASP’s page title names the document as State of Agentic AI Security and Governance 2.01. The date matters because agentic AI security guidance is moving from threat lists into operating material, and a compliance file needs to show which document it relied on at the time. Do not turn that into more than it says. A report about the field is not an approval of your agent, your workflow, or your exception process.

The State of Agentic AI Security and Governance provides a comprehensive view of today’s landscape for securing and governing autonomous AI systems.

— State of Agentic AI Security and Governance 2.01, 2 June 2026

The important word is “landscape”. A landscape tells you what terrain exists. It does not tell you that your own route was permitted. If an agent updates a customer record after reading a policy, the report may help you classify the risk; it does not show that the agent had authority to make that update at that moment.

OWASP’s Agentic Security Initiative sits behind much of this material. OWASP announced the Agentic Security Initiative from the LLM and Generative AI Security Project on 18 August 2025. On the same initiative page, OWASP says the OWASP Top 10 for Agentic Applications 2026 is a globally peer-reviewed framework identifying critical security risks for autonomous and agentic AI systems. That gives risk owners a common language. It still leaves local accountability unsolved.

The OWASP Top 10 for Agentic Applications for 2026 was published on 10 December 2025. OWASP describes that work as distilling a broad ecosystem of OWASP GenAI Security guidance into an operational format for builders, defenders, and decision-makers. That is a practical security contribution. It is also not a substitute for a record of authority.

By distilling a broad ecosystem of OWASP GenAI Security guidance into an accessible, operational format, the Top 10 equips builders, defenders, and decision-makers with a clear starting point for reducing agentic AI risks and supporting safe, trustworthy deployments.

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

A starting point is exactly that. It helps an engineering team decide where to begin. It does not preserve the decision that allowed a transfer, stopped a deletion, or escalated an exception. The gap is small in wording and large in consequence.

OWASP also published Agentic AI - OWASP Lists Threats and Mitigations on 17 February 2025. OWASP describes that document as the first in a series from the Agentic Security Initiative to provide a threat-model-based reference of emerging agentic threats and discuss mitigations. That sequence shows a programme developing over time: threat reference, risk framework, crosswalks, and a state report. It is stronger than a single vendor slide deck. It is still guidance, not evidence from your production decision path.

OWASP’s own later account says that, since February 2025, the project released documents covering the lifecycle from Agentic AI Threats & Mitigations and threat modelling to secure development guidelines, the state of agentic AI and governance, and the agentic AI security product landscape. That sentence is worth reading narrowly. It records coverage across a lifecycle. It does not say that any organisation adopting the documents can later prove which policy permitted a disputed action.

The agentic AI governance report as a governance artefact

The agentic AI governance report is most useful when treated as an artefact in a governance file, not as the file itself. It can support a risk taxonomy, a gap analysis, and a decision to prioritise agent controls. It cannot supply the missing local facts: which agent asked, what it asked to do, what policy applied, who approved it if approval was needed, and what happened next.

OWASP’s Resources Archive describes the OWASP GenAI Security Project Crosswalk as an open-source resource connecting OWASP GenAI security risks to established industry security, governance, and compliance frameworks. That is the governance bridge compliance teams usually want. It helps translate a security risk into a framework conversation. But translation is not attestation.

The same archive describes the AIUC-1 Crosswalk of the OWASP Top 10 for Agentic Applications as providing a bidirectional mapping between AIUC-1 requirements and the OWASP Agentic Security Initiative’s Top 10 risks for autonomous and agentic AI systems. A crosswalk can reduce ambiguity in policy design. It can also hide a practical problem if teams stop there. A mapping says one requirement relates to one risk. It does not say that last Friday’s supplier-bank-detail change complied with that requirement.

OWASP’s Resources Archive also describes a comprehensive, vendor-agnostic resource for organisations seeking to secure Large Language Models and Agentic AI applications. Vendor-agnostic guidance is valuable because it avoids making one product’s architecture the definition of good practice. The concession is equally important. Vendor-agnostic guidance cannot hold your system’s event trail for you.

This is where the distinction between preventing an incident and proving a decision becomes operational. Prevention is about the live decision: block the agent from sending the payment, require review before deleting the record, or stop a tool from changing a limit. Evidence is about what remains after the moment passes. A review file that contains only an outcome — “allowed” or “blocked” — is weak because it does not show the authority behind that outcome.

Agentic security addresses what happens when those models can plan, persist, and delegate across tools and systems.

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

That sentence explains why ordinary application controls are under pressure. An agent that can plan, persist, and delegate can create a chain of actions that no single screen shows well. The issue is not only whether one call was safe. The issue is whether the organisation can reconstruct why each consequential action was allowed.

For financial services readers, the related problem is familiar from model oversight and compliance evidence. Crelis has written separately on Singapore financial services AI compliance and on AI systems oversight. Those pieces take the same evidential problem from different regulated settings. The common lesson is plain: a control that cannot be shown later is a control you may struggle to rely on.

What this means if you have to produce evidence

Start with the likely dispute, not the architecture diagram. A customer says an agent changed a delivery address without authority. A finance reviewer asks why an invoice was released. A records owner asks who allowed deletion after the retention exception expired. In each case, the operational system may know what happened; the governance question is why it was permitted.

The OWASP documents help define what kinds of agentic risk should be in view. They do not remove the need to bind a live action to a live permission. A policy document on a shared drive is not enough. A screenshot from an admin console is not enough if it cannot show the decision as it stood when the agent acted.

There is also a vendor-side temptation to blur categories. Security guidance, identity, runtime authorization, monitoring, and audit are often described as though they collapse into one answer. They do not. Identity says which agent acted. Runtime authorization says whether the action was allowed at the time. Evidence says whether you can prove that answer later to someone who is not inclined to trust you.

Crelis describes its own product as runtime authorization for AI agents, and says that every agent action passes through Crelis before touching systems. Crelis also says it is currently in prototype stage and accepting pilot design partners for runtime authorization of AI agent actions. Those statements should be read as product positioning, not as certification and not as regulator approval. The useful question is narrower: where does your agent take an action that later needs a defensible authority record?

GREENLIGHT is Crelis’ permission step for sensitive actions, and Crelis describes setups in which either the agent has no direct route to the sensitive system or the system refuses sensitive actions that arrive without a valid Crelis permission. Crelis also says systems that do not know about Crelis keep working as they do today while every action is checked and recorded. That is a claim about Crelis and GREENLIGHT only. It does not prove that every deployment will meet a regulator’s evidence expectations.

The compliance owner should ask for the thing the report cannot give. Show the specific authority. Show the policy that applied. Show the approval, escalation, or block. Show that the record is tamper-evident. If the answer is a dashboard total or a model trace without authority, the answer is incomplete.

Practical steps for a risk owner

1. Name the action. Do not start with “agent governance”. Start with the action that can hurt you: release a payment, change customer data, delete a record, alter an access setting, or send a regulated communication.
2. Separate identity from authority. Require the team to show which agent acted and, separately, why that action was allowed. A known agent can still be unauthorised for a particular act.
3. Map the risk language. Use OWASP’s Top 10 for Agentic Applications 2026 as a common starting point for agentic AI risk discussions.
4. Map the governance language. Use OWASP’s crosswalk material where you need to connect GenAI security risks to security, governance, and compliance frameworks.
5. Demand action-level evidence. For each sensitive agent action, require a record that shows the request, the applicable policy, the decision, any human approval, and the outcome.
6. Reject outcome-only records. “Allowed” is not enough. “Blocked” is not enough. The authority behind the result is the part that will be contested.
7. Test the file backwards. Pick one completed action and ask a reviewer to reconstruct who authorised it without interviewing the engineer who built it.
8. Keep the proof close to runtime. The farther the record is from the decision point, the easier it is for gaps, summaries, and after-the-fact explanations to replace evidence.

The practical point is not that OWASP should have solved your evidence problem. That is not what the document claims. The point is that the OWASP report gives teams a dated field reference, and serious references make weak local evidence harder to defend. If the report helps your team name the risk, your next question should be whether your own systems can prove the authority behind the action.

Crelis’ position is narrow: GREENLIGHT should sit at the permission step for sensitive agent actions, and the record should show the authority behind the decision rather than merely the result. Crelis describes its product as an authorization layer that can allow, require human approval, escalate, or block agent actions with tamper-evident proof. If you want to assess Crelis’ claim, use the product demonstration around the places where your agents touch money, customers, records, or infrastructure.

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

Related reading

• Singapore financial services AI compliance — how evidence expectations change when agents touch regulated workflows.
• AI systems oversight — a framework for reviewing authority, evidence, and operational accountability.