Runtime cloud security is displacing CNAPP for workload protection

At a glance

What this is: This is Oligo Security’s analysis of Latio’s 2025 cloud security market report, arguing that cloud security is shifting from broad posture management toward runtime protection and CADR.

Why it matters: It matters to IAM practitioners because runtime security changes how workload access, application behaviour, and AI activity are governed across NHI, autonomous, and human identity programmes.

By the numbers:

• 53% of practitioners ranked Application Detection and Response among their most requested features.
• 65% said they want better visibility into how AI models and applications behave at runtime.

👉 Read Oligo Security's analysis of the cloud security shift toward runtime protection

Context

Cloud application detection and response is the move from seeing cloud configuration to understanding what is actually happening in production. The article’s core claim is that CNAPP-style visibility is no longer enough when workloads, applications, and AI activity change at runtime.

For IAM and NHI teams, that shift matters because access decisions are no longer evaluated only at provisioning time. Runtime context changes how teams judge entitlement scope, secret exposure, service-to-service trust, and whether application behaviour still matches the access that was originally approved.

Key questions

Q: How should security teams prioritise cloud vulnerabilities when runtime exposure is unclear?

A: Teams should prioritise vulnerabilities that are reachable in the current runtime state, not just those that score highest in abstract. That means correlating scanning results with live process behaviour, network paths, and application function usage. If an issue cannot be reached, it may still matter, but it should not outrank an exposure that can be exploited immediately.

Q: Why do runtime controls matter more than posture alone for cloud workloads?

A: Posture tells you what could be wrong at deployment time, but runtime tells you what is happening now. In cloud environments, attackers exploit live application paths, active identities, and reachable services. Without runtime controls, teams can know they are exposed but still miss the moment when that exposure becomes usable by an attacker.

Q: What do security teams get wrong about application-layer cloud protection?

A: Many teams assume broader platform coverage automatically means better protection. In practice, coverage without runtime context produces noise, duplicates, and low-confidence alerts. Application-layer protection has to show which actions are actually occurring, which paths are reachable, and which identities are enabling the behaviour.

Q: How can organisations tell whether AI runtime monitoring is working?

A: A working programme can explain which AI-driven actions were observed, which service identities enabled them, and whether those actions stayed inside approved operational scope. If the team only sees dashboards and not the behaviour chain from input to tool use to effect, the control is too shallow to rely on.

Technical breakdown

Why posture tooling misses runtime risk

Posture tools are designed to identify misconfiguration, missing controls, and possible exposure before execution. Runtime security adds the layer that posture cannot see: live process behaviour, reachable code paths, active connections, and response state. In cloud environments, this matters because many serious failures only become visible once a workload is running and interacting with other services. CADR as described in the article is essentially a shift from static condition checking to production behaviour analysis, with the goal of reducing noise and prioritising issues that can actually be exploited.

Practical implication: teams should treat runtime telemetry as a separate control plane, not as an optional enhancement to posture scanning.

Function-level reachability and false-positive reduction

Function-level reachability is the idea that a vulnerability only becomes operationally meaningful if the vulnerable code path can actually be reached in the current application state. This is especially important in distributed cloud systems, where large vulnerability lists create alert fatigue but only a fraction of findings represent true attack paths. The article links this to runtime context because reachability cuts through generic risk scoring and identifies the vulnerabilities that matter in production. That makes security work more targeted and easier to align with application owners.

Practical implication: map vulnerability response to real runtime reachability instead of treating every disclosed issue as equally urgent.

AI runtime behaviour as a security signal

The article treats AI as part of the runtime problem because models and agents are now behaving inside production systems, not just in isolated labs. When AI-driven workflows can call tools, query data, or influence downstream systems, security teams need to observe what the application and the AI component actually do together. That is different from classic infrastructure monitoring because the relevant signal includes prompt-driven behaviour, tool invocation, and chained actions across services. In governance terms, the security question becomes whether the behaviour stays within the intended operational boundary while the system is live.

Practical implication: extend runtime monitoring to AI-enabled workflows where the control problem is behavioural, not just infrastructural.

Threat narrative

Attacker objective: The attacker aims to turn live application behaviour into an execution path that enables theft, manipulation, or service disruption at production speed.

1. Entry occurs when a cloud workload, application, or AI-enabled service is deployed with an exploitable weakness that posture tools may flag but cannot prioritise effectively.
2. Escalation happens when the attacker reaches a live code path, uses runtime behaviour to distinguish real exposure from noise, and pivots through reachable services or application-layer functions.
3. Impact follows when the adversary abuses the active production state to exfiltrate data, disrupt services, or manipulate AI and application behaviour before defenders can respond.

Breaches seen in the wild

• Codefinger AWS S3 ransomware attack — Codefinger used compromised AWS credentials to encrypt S3 buckets via SSE-C.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Runtime security is now an identity problem, not just a cloud security problem. Once applications, workloads, and AI systems act in production, the real question is who or what is allowed to do what at runtime. That pulls workload identity, secret exposure, and service-to-service trust into the same governance conversation. Organisations that still treat these as separate disciplines will keep missing the control boundary that matters most.

Function-level reachability is a better decision signal than raw vulnerability volume. The article’s emphasis on reducing noise is really a governance argument: security teams need to know which exposures are executable in the current runtime state. That aligns with OWASP-NHI thinking because identity-linked access becomes dangerous when the path from credential to action is actually open. Practitioners should prioritise reachable exposure over theoretical inventory.

AI behaviour inside production systems creates a new runtime trust boundary. The article’s AI runtime framing shows that model activity can no longer be treated as a passive workload characteristic. When AI is embedded in cloud workflows, the security issue is whether the system can act within the scope originally intended. That combines OWASP-AGENTIC-style runtime scrutiny with NHI governance for the service identities that enable it. The implication is that entitlement reviews alone no longer describe actual risk.

Application-layer protection is replacing broad platform confidence with operational proof. CNAPP-era programs often assume coverage is the same thing as control, but runtime protection forces a harder test: can the team see, prioritise, and stop the action that is actually happening. That is a stronger standard for cloud governance, and it exposes where visibility has been mistaken for enforcement. Practitioners should judge tooling by live control outcomes, not by dashboard breadth.

From our research:

• 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to The 2024 Non-Human Identity Security Report.
• 59.8% of organisations see value in a solution that simplifies non-human access management and introduces dynamic ephemeral credentials, according to The 2024 Non-Human Identity Security Report.
• For the broader market picture, Ultimate Guide to NHIs , 2025 Outlook and Predictions tracks where runtime-centric identity governance is heading next.

What this signals

Runtime protection will increasingly become the governance layer for cloud identity decisions. As organisations move away from broad platform confidence, they will need to prove that service identities, application actions, and AI workflows are behaving within approved scope. That is a programme change, not just a tooling change, because it shifts the operational question from what is deployed to what is executing.

Identity teams should expect stronger coupling between cloud security and NHI governance. The old separation between infrastructure controls and identity controls is fading as runtime telemetry exposes how access is actually used. With 88.5% of organisations already saying their non-human IAM practices lag behind or merely match human IAM, per the 2024 Non-Human Identity Security Report, the governance gap is structural.

Function-level reachability creates a new named concept for prioritisation: runtime exposure debt. It describes the backlog of issues that look important on paper but only become actionable when a live workload can actually reach them. Teams that track runtime exposure debt alongside posture risk will make better remediation calls and reduce unnecessary operational churn.

For practitioners

• Separate posture findings from runtime exposure Create a workflow that classifies findings into configuration risk, reachable runtime risk, and active exploitation risk. Use that distinction to route only executable issues into incident and remediation queues.
• Prioritise live code-path exposures first Tie vulnerability response to function-level reachability so teams fix the issues that are actually callable in production. This reduces noise and keeps AppSec, CloudSec, and operations aligned on the same evidence.
• Extend monitoring to AI-enabled workflows Instrument the service identities, tool calls, and application interactions that accompany AI-driven runtime behaviour. If an AI workflow can influence data access or downstream execution, treat that behaviour as part of the control boundary.

Key takeaways

• Cloud security is shifting from posture checking to runtime control, which changes how identity, workload, and AI risk are governed.
• The practical value lies in separating reachable exposure from theoretical vulnerability volume, because only live paths create immediate attackability.
• Programmes that still treat runtime visibility as optional will keep confusing coverage with control and miss the moment risk becomes executable.

Key terms

• Cloud Application Detection and Response: Cloud Application Detection and Response is a runtime security approach that focuses on what cloud applications and workloads are actually doing in production. It combines live telemetry, context, and response so teams can detect and stop active abuse rather than only catalogue configuration risk.
• Function-level reachability: Function-level reachability is the ability to determine whether a vulnerable code path can be executed in the current runtime state. It helps security teams separate theoretical exposure from issues that an attacker can actually invoke in production.
• Runtime context: Runtime context is the live operational information needed to understand current application behaviour, identity use, and network activity. In cloud and AI environments, it is the difference between knowing a system exists and knowing what it is doing right now.
• Runtime exposure debt: Runtime exposure debt is the growing backlog of issues that appear risky in static assessment but only become exploitable when a live workload can reach them. The term helps teams prioritise by actual attackability instead of treating every finding as equally urgent.

What's in the full article

Oligo Security's full article covers the operational detail this post intentionally leaves for the source:

• How the vendor defines CADR across cloud, workload, application, and AI runtime contexts
• The runtime protection architecture the article associates with function-level reachability and live response
• Why the vendor argues posture-heavy CNAPP tools are missing application-layer context
• How Oligo positions its own runtime visibility claims against the market shift described by Latio

👉 The full Oligo Security post covers CADR definitions, runtime visibility detail, and the market framing behind the move beyond CNAPP.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.