The Agentic AI Security Landscape, Q2 2026: How the Categories Actually Divide

Every security market map hides a buying decision. In the agent case, the useful split is not between general AI safety and specialist agent tools. OWASP Gen AI Security Project published State of Agentic AI Security and Governance 2.01, and says it gives “a comprehensive view” of the landscape for securing and governing autonomous AI systems. That helps locate the market, but it does not answer the narrower evidence question: when an agent changes a credit limit, can you show who permitted that exact action?

AI agent security landscape 2026 by document, not slogan

The safest way to read the market is to start with the documents, not the pitch decks. OWASP gives the landscape frame.

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

— OWASP Gen AI Security Project, State of Agentic AI Security and Governance 2.01

That sentence supports a broad landscape claim. It does not, by itself, tell a risk owner which layer will answer a payment dispute, a deleted record, or an unauthorised account change. A map can be comprehensive and still be the wrong artefact for evidence.

OWASP’s separate AI Security Solutions Landscape For AI and Agentic Red Teaming Q2 2026 says that generative AI and autonomous agents are being deployed into business-critical workflows, and that traditional application security practices are no longer sufficient. It also frames red teaming as a lifecycle-wide approach to identifying, measuring, mitigating, and governing risks through adversarial testing, defensive validation, and continuous feedback loops. That is a serious category. It is not the same category as proving that a particular agent was allowed to release one payment at one moment.

The first divide is identity. NIST’s work makes that plain because the announcement points stakeholders to an AI Agent Identity and Authorization Concept Paper. Identity matters because an agent without a stable identity is difficult to govern. But a known agent can still perform the wrong action. A badge is not a permission slip.

The second divide is threat detection and testing. OWASP’s AI Agent Security cheat sheet says testing should cover both application controls and agent-specific failure modes. It also says agents should undergo structured security testing before release and after material changes to prompts, tools, memory, retrieval, policies, or model providers. That advice belongs before the incident. It improves the system. It does not necessarily preserve the authority behind one completed action.

The third divide is application authorization. This is where an agent asks to do something that changes the world outside the model: approve an invoice, amend a record, cancel an order, or send a message to a regulator. The useful question is narrow. Was this agent allowed to do this thing, for this account, under these conditions?

The fourth divide is the record. The record is not a prettier log. It is the artefact that has to survive the argument after the dashboard has gone quiet. If the market map treats recording as a feature inside detection, or as a line item inside observability, the buyer still has work to do.

AI agent security standards and what they actually cover

NIST is not pretending that standards for agents are finished. Its announcement says NIST, including CAISI, aims to foster industry-led technical standards and protocols for public trust, interoperability, and secure innovation. It also says NIST will announce research, guidelines, and further deliverables in the months ahead. That matters. A compliance officer should not treat a standards initiative as if it were already a control catalogue.

"To address this concern, NIST, including CAISI, aims to foster industry-led technical standards and protocols that build public trust in AI agents, catalyze an interoperable agent ecosystem, and diffuse their benefits to all Americans and across the world."

— NIST announcement on interoperable and secure AI agents

The live point is not whether NIST has used the right nouns. It has. The live point is whether your control set can show the chain from identity, to permission, to outcome, to later proof. Standards language can make that requirement visible. It does not implement it for you.

OWASP’s Top 10 for Agentic Applications for 2026 was published on 10 December 2025 and describes itself as a globally peer-reviewed framework identifying critical security risks facing autonomous and agentic AI systems. It says the Top 10 equips builders, defenders, and decision-makers with a starting point for reducing agentic AI risks and supporting safe deployments. “Starting point” is the phrase to keep. It is not an audit pack.

The OWASP cheat sheet is more operational. It warns that attackers may try to weaken or remove security tests in the same pull request that changes agent behaviour. That is a useful control warning because the test suite becomes part of the attack surface. It still leaves a separate question: if all tests passed and the agent later changed a customer record, what proves the authority for that change?

There is also a vendor and product landscape around prompt security. OWASP’s Prompt Security taxonomy entry describes FortiAIGate as an AI gateway that routes LLM traffic, enforces input and output controls, detects prompt injection, toxicity, and sensitive data exposure, and provides centralised logging, policy management, and usage visibility. That is a concrete bundle of gateway functions. It is not the same as a durable permission record for a specific action.

This distinction is not hostile to testing vendors, gateway vendors, or identity vendors. It protects them from being blamed for a job they did not claim to do. A gateway may detect a dangerous prompt. A test may catch a failure mode. An identity layer may prove which agent connected. None of those facts necessarily proves that a named policy allowed a named action at runtime.

Agentic AI runtime control and the runtime turn

The runtime turn is clearest in OWASP’s Agent Control Standard. OWASP published the document on 2 September 2026 and says it provides an open foundation for putting transparency and control into practice. Its stronger sentence is about what agents must expose.

"Agents must be inspectable, traceable and instrumentable —providing visibility into what they are, what they can access, what they did and why, and the ability to control their behavior at runtime."

— OWASP Gen AI Security Project, Agent Control Standard, 2 September 2026

That sentence is worth reading slowly. It joins visibility and runtime control. It does not say that a later reviewer will automatically receive a complete authority record for every completed action. Runtime control and later evidence are neighbours, not twins.

OWASP says the Agent Control Standard defines how agent platforms expose middleware hooks and how safety policies can be enforced through them, enabling declarative controls that are portable across agent frameworks and enforced at runtime. That is a meaningful control direction. It moves the discussion from static assessment toward decisions made while the agent is acting. For a payment release, that is the right moment to decide.

But runtime enforcement is still present-tense. It answers “may this proceed now?” The evidence problem is past-tense and adversarial. It asks “show me why that proceeded then, and show me why I should trust the record now.”

This is where runtime authorization differs from runtime security. Runtime security can include detection, monitoring, blocking, testing, and policy enforcement. Runtime authorization is narrower. It is the permission decision for the action itself. Narrower is not weaker. It is easier to evidence.

The Model Context Protocol point is similar. Crelis’s GREENLIGHT knowledge base says 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. That is not an attack on MCP. It is a boundary line. If the tool call is the whole evidence story, the story ends too early.

For a worked version of that boundary, see Who Authorizes an MCP Tool Call?. The short version is simple: a tool call can be allowed, and still leave the organisation unable to prove the authority behind it later. That is the gap that makes agent governance feel solved until someone asks for the file.

What this means if you have to produce evidence

A risk owner should separate four files. The first file proves identity. The second shows testing and threat treatment. The third shows runtime permission. The fourth preserves the record of authority. If those four files collapse into one dashboard, the dashboard will look efficient until it is used as evidence.

Start with the disputed action. A supplier bank detail is changed. The agent did not merely produce text. It changed a record that affects future payments. In that case, a screenshot of an agent session is weak evidence. A general access role is also weak evidence. The useful record says which agent requested the change, which rule or approval allowed it, what was changed, and what happened next.

The same logic applies to a deleted customer record. Detection may tell you that deletion occurred. Identity may tell you which agent account was involved. Application logs may show that the database accepted the operation. The missing item is often authority: why this deletion was permitted for this record at this time.

This is why the Singapore reader should connect the market landscape to governance evidence, not to slogans. The Crelis analysis of MAS SAFR makes the same distinction at the supervisory evidence layer. The broader AI compliance reference for Singapore puts that problem in the local governance frame. Those pages do not turn Crelis into a regulator. They are a way to organise the evidence question before procurement language blurs it.

There is a hard objection here. Many teams already retain logs. Some logs are good. Some are detailed enough to reconstruct much of what happened. The problem is not that logs are useless. The problem is that logs are usually designed to operate a system, not to prove authority to a sceptical outsider.

A second objection is also fair. Not every agent action deserves the same burden. Summarising a policy document is not the same as changing a customer credit limit. The evidence layer should follow consequence. If an agent cannot touch money, customers, records, or infrastructure, the record requirement may be lighter.

Crelis’s demo page asks teams to identify where AI agents touch money, customers, records, or infrastructure. That is the right starting inventory because it names the places where authority will later be contested. A tool that only drafts text may need review. A tool that releases funds needs proof.

Practical steps for a defensible agent estate

1. Classify actions, not agents. Do not begin with a list of models. Begin with actions: release payment, amend customer status, delete a record, change a limit, send a formal notice. The same agent can perform low-risk and high-consequence work in the same hour.
2. Keep identity separate. Record which agent acted, but do not treat that as permission. NIST’s initiative explicitly places identity and authorization in the standards conversation. Your design should keep them distinct enough that a reviewer can see both.
3. Test before and after material change. OWASP says structured security testing should happen before release and after material changes to prompts, tools, memory, retrieval, policies, or model providers. That means the control file should include change-triggered testing, not only a launch assessment.
4. Put runtime permission near the action. OWASP’s Agent Control Standard points to safety policies enforced at runtime through exposed hooks. That is the right architectural instinct: decide before the payment leaves, not after the exception report arrives.
5. Preserve the authority record. For each consequential action, keep the permission decision, the basis for that decision, the requested action, and the outcome together. If these live in separate tools, the later reviewer gets a reconstruction exercise instead of evidence.
6. Mark what your tools do not cover. A red-team tool is not an identity system. An identity system is not an authorization record. A gateway log is not automatically proof of authority. The buyer who writes those limits down is less likely to buy the same control twice.
7. Start with the hardest workflow. Pick one workflow where an agent touches something that matters. Crelis’s demo path uses that same framing for scoping. If the evidence story fails there, it will not improve when spread across more systems.

Crelis’s position is narrow: use GREENLIGHT to put a permission step in front of consequential agent actions, and treat the resulting record as part of the control, not as an afterthought. Crelis describes GREENLIGHT as a setup where sensitive actions either have no direct route to the sensitive system or the system refuses sensitive actions without a valid Crelis permission. The claim is not that this replaces testing, identity, or standards work; it is that recording an outcome is not the same as evidencing the authority behind it.

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 boundary between live permission and broader runtime defence.
• Who Authorizes an MCP Tool Call? — the permission gap around individual tool calls.
• MAS SAFR — the Singapore evidence question for agentic AI governance.