TL;DR: The 2025 Latio Cloud Security Market Report says teams are moving beyond one-size-fits-all CNAPPs toward AST, CTEM, and CADR, with 65% prioritising AI posture management and 53% prioritising application detection and response, according to Cyera. The governance signal is clear: posture confidence is no longer enough when runtime exposure spans data, apps, and workloads.
At a glance
What this is: This market report says cloud security teams are shifting from broad CNAPP coverage toward more targeted runtime-first controls such as AST, CTEM and CADR.
Why it matters: It matters because IAM, NHI and cloud security programmes now need to distinguish posture visibility from runtime control, especially as AI and application exposure expand.
Context
Cloud security programmes often overstate coverage when they rely on posture data alone. Runtime exposure is the gap between what a platform can see in configuration and what is actually happening across applications, workloads and data paths.
The 2025 Latio Cloud Security Market Report frames a market shift toward controls that operate closer to execution, especially where cloud, AI and application layers intersect. For IAM and NHI teams, that means access and identity decisions can no longer be evaluated only at provisioning time.
This article is about how buyers are rebalancing cloud security spend, but the underlying governance question is broader: which controls still work once activity moves into runtime and where do existing programmes lose decision quality?
Key questions
Q: How should teams choose between runtime-first and posture-led security tools?
A: Start with where your risk actually lives. If compromise emerges from live workload behavior, prioritise tools that can enforce in the cluster or at execution time. If your main exposure is misconfiguration across many clouds, posture breadth matters more. Most programmes need both views, but the deciding factor is whether the platform can change behavior, not only report on it.
Q: Why do posture tools still leave cloud teams exposed at runtime?
A: Because posture tools mostly describe state, not behaviour. A team can know an environment is configured correctly and still miss how data, workloads, APIs or AI systems behave once access is granted and execution begins.
Q: What are the signs that a cloud security programme needs CTEM or ADR?
A: Common signs include confidence in posture reporting but weak visibility into live application activity, unclear ownership of exposure validation, and response processes that only begin after a finding has already been summarised.
Q: How do AI posture management and cloud identity governance overlap?
A: They overlap wherever AI systems access sensitive data, call tools, or operate within cloud environments that depend on identity decisions. The governance issue is whether access, usage and response controls follow the AI system into runtime rather than stopping at approval time.
Technical breakdown
Why posture-first controls miss runtime exposure
Posture-first tooling is designed to detect misconfiguration, missing hardening and policy drift before a workload or application is exercised. That is useful, but it does not fully answer what happens after access is granted, an API is called, or an application begins exchanging sensitive data at runtime. The article points to a common gap: teams can feel confident in vulnerability and posture coverage while still lacking direct detection and response where behaviour actually unfolds. In practice, the control boundary moves from configuration state to live execution, which changes what “covered” means.
Practical implication: Treat posture as a baseline control and map where runtime monitoring, detection and response must take over.
How AST, CTEM and CADR split the control problem
The report groups three approaches that solve different parts of the same problem. Application Security Testing focuses on finding weaknesses before release, Continuous Threat Exposure Management prioritises exposure discovery and validation across the attack surface, and Cloud Application Detection and Response watches for active abuse or suspicious behaviour during execution. These are not interchangeable labels. A programme that blends them into one category risks buying coverage that looks broad on paper but leaves decision points unclear in practice. The real value is in deciding which phase of the lifecycle each control owns.
Practical implication: Assign each approach to a distinct phase of the lifecycle so teams know what is discovered, prioritised and detected.
Why AI posture management is now a separate buying signal
AI posture management emerges in the report as a top priority because AI workloads introduce new governance questions around data access, tool usage and exposure paths. The key issue is not just whether AI exists in the environment, but whether the security model can follow it into runtime interactions where data, agents and workloads intersect. That pushes identity and access governance closer to the execution layer, because the sensitive question becomes who or what can access data during live model or application activity. This is a control-scope problem as much as a tooling problem.
Practical implication: Map AI access, data exposure and runtime monitoring into one governance view rather than treating them as separate programmes.
NHI Mgmt Group analysis
Runtime-first security is becoming the practical answer to cloud exposure, not a niche preference. The report shows buyers moving away from all-in-one platform thinking toward controls that distinguish posture, exposure management and runtime response. That shift reflects a governance reality: cloud risk now appears at execution time as often as it appears in configuration drift. Practitioners should expect budgets and evaluation criteria to follow that split.
AI posture management is a signal that identity scope now extends into live data and application behaviour. When AI systems touch cloud data, the question is no longer only whether the environment is secure on paper. It becomes whether access, usage and response controls can track what is happening while the system is running. That makes identity and data governance inseparable in AI-heavy cloud estates.
CTEM only works when exposure validation is tied to the actual runtime paths attackers and users can reach. If teams limit exposure management to static findings, they will miss the paths that matter most to application and workload abuse. The report’s emphasis on targeted strategies suggests practitioners are recognising that breadth without execution context creates false confidence. The implication is to measure exposure in the same place the business runs.
Agent-based protection is the named concept that explains this market shift. The article points to protection that operates across network, OS, container, API and application layers because runtime threats do not stay in one layer. That is the right mental model for cloud and AI security programmes that need to see behaviour, not just posture. Practitioners should organise controls around execution paths rather than product categories.
From our research library:
- By 2029, 40% of enterprises that successfully implement zero trust within cloud service provider environments will rely on the advanced visibility and control capabilities offered by CNAPP solutions.
- Read next: Identity Security Posture Management (ISPM) Guide
What this signals
Runtime control is now the differentiator: programmes that stop at posture reporting will keep producing confidence signals without operational reach, so the next maturity step is to connect exposure validation to live detection and response.
For IAM and NHI teams, the practical shift is to treat AI workloads, cloud applications and data paths as one governed runtime surface instead of separate technical domains. That is where identity decisions now create or reduce risk.
For practitioners
- Separate posture, exposure and runtime responsibilities Document which team and control owns configuration drift, exposure validation and live detection so the programme does not assume one platform covers all three.
- Map AI workloads to runtime decision points Identify where AI systems access data, call tools, or interact with cloud services and make those points visible in identity and security workflows.
- Evaluate runtime controls against application paths Test whether current detection and response tooling can observe activity across APIs, containers, workloads and application sessions rather than only summarising posture findings.
- Align buyer criteria to control phase Score vendors and internal capabilities by whether they discover exposure, validate exploitability or detect live activity, since each phase answers a different governance need.
Key takeaways
- The market signal is not that posture is obsolete, but that posture alone no longer defines control coverage in cloud and AI environments.
- Teams are separating discovery, exposure validation and runtime response because each addresses a different failure mode in the cloud stack.
- Identity governance now has to follow live access and behaviour, especially where AI systems interact with data and services at runtime.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CSA Cloud Controls Matrix and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-01 — Networks and network services are monitored to find potentially adverse events | Runtime-first controls depend on monitoring live cloud activity, not just posture. |
| PR.AA-05 — Access permissions, entitlements and authorizations are managed | The article ties cloud and AI risk to who or what can access data and services. | |
| Recommendation — Extend monitoring to runtime activity so cloud exposure is visible after deployment. Review entitlements against live workload and AI access paths rather than static approval records. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | The report's AI and cloud governance questions center on identity scope in runtime environments. |
| SEF — Security Events and Monitoring | CADR and CTEM both depend on monitoring and response across live cloud activity. | |
| Recommendation — Align cloud identity governance with runtime access paths across applications, workloads and AI systems. Use cloud monitoring and response controls to detect active abuse, not just configuration issues. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | AI posture management is a governance issue because it extends security oversight into AI use and access. |
| Recommendation — Define accountability for AI access, usage and security oversight before scaling AI deployments. | ||
Key terms
- Runtime-first controls: Security controls designed to observe, detect or respond during live execution rather than only at configuration time. In cloud and AI environments, runtime-first controls focus on behaviour, active exposure and access paths that emerge after deployment.
- Continuous Threat Exposure Management: Continuous Threat Exposure Management is the ongoing process of finding which assets, identities, and paths are actually reachable from the current environment. It moves risk assessment away from static inventories and toward live exposure, so security teams can prioritise what an attacker or misuse path can reach now.
- Cloud Application Detection And Response: Cloud Application Detection and Response is the practice of identifying suspicious behaviour inside live cloud applications and workloads, then containing that behaviour before it spreads. It focuses on runtime signals such as unusual access, API misuse, and escalation paths that scan-time posture tools cannot see.
- Identity Posture Management: Identity posture management is the continuous discovery, assessment, and monitoring of identity risk across an environment. In NHI contexts, it focuses on exposure, privilege, ownership, and drift, so teams can find risky access before it becomes an incident or an audit gap.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 7, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org