Runtime security became the source of truth in 2025

At a glance

What this is: This is Oligo Security's year-end analysis of how runtime security, AI runtime protection, and cloud attack research reshaped its view of the market in 2025.

Why it matters: It matters because IAM, NHI, and security teams increasingly have to govern identities and risks as they behave in production, not just as they are provisioned.

By the numbers:

• Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption.
• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
• Organisations that describe themselves as confident in their AI deployment actually experience a 72% security incident rate.

👉 Read Oligo Security's year-end analysis of runtime security in 2025

Context

Runtime security is the discipline of understanding and controlling software, AI systems, and cloud workloads while they are executing, not just before release. This article argues that 2025 made that model feel less optional because modern attacks, AI adoption, and production context exposed the limits of static scanning and pre-runtime assumptions.

For identity and access teams, the deeper question is how much trust can be placed in pre-approved credentials, packaged policies, and design-time reviews once systems begin acting in real environments. That pressure now spans workload identity, secrets, AI agents, and broader identity governance, which is why runtime visibility has become a cross-programme concern.

The article's starting point is typical for a security vendor year-in-review, but the underlying shift is not. Many programmes still separate code risk, infrastructure risk, and identity risk even though attackers increasingly move across those boundaries in production.

Key questions

Q: How should teams govern runtime security for AI systems and cloud workloads?

A: Teams should govern runtime security by focusing on live execution paths, not just pre-deployment approvals. That means correlating telemetry from workloads, identities, packages, and AI actions so defenders can see what actually happens in production. The practical goal is to identify where trust decisions become real and where blast radius expands once systems start executing.

Q: Why do static scans fail to protect modern applications and AI systems on their own?

A: Static scans fail because they describe code or configuration before the system is exercised, while many attacks only become visible during execution. A package may look benign until it runs, an AI workflow may appear safe until it calls tools, and a secret may be harmless until it is used in production. Runtime evidence closes that gap.

Q: What do security teams get wrong about AI runtime risk?

A: A common mistake is treating AI runtime risk as a prompt-safety or model-quality issue alone. In practice, the risk often sits in permissions, tool access, and the production path the AI can reach. If an AI system can act on infrastructure or data, its governance must include identity scope, monitoring, and containment.

Q: How do teams decide whether runtime security should sit with AppSec or identity?

A: Teams should stop treating that as an either-or choice. Runtime security sits at the point where application behaviour and identity use intersect, so ownership has to be shared across AppSec, cloud security, and identity governance. If a flaw can be reached by a credential, token, or workload identity, it is both an application and identity problem.

Technical breakdown

Why runtime security changes the control point

Runtime security shifts the control point from build-time assurance to execution-time observation and enforcement. In practice, that means the defender is looking at what actually happens when code, workloads, or AI systems run, including loaded libraries, process behaviour, network calls, and privilege use. This is different from static analysis because the real question is not whether a component looked safe in a repository, but whether it behaved safely under live conditions. For identity teams, that matters because the effective blast radius of a secret, token, or workload identity is only visible once it is exercised in production.

Practical implication: map which identity and workload decisions are still made before execution and where runtime controls are now required.

Cloud application detection and response for production attacks

Cloud application detection and response, often shortened to CADR, is a runtime approach to detecting and responding to attacks inside live application paths rather than only at the network or host layer. The article positions it as a way to connect initial intrusion, exploitation, and post-exploitation context in one view. That matters because modern application-layer attacks often blend code abuse, workload compromise, and lateral movement without triggering legacy perimeter assumptions. The key technical change is that defenders need execution context to determine whether a process, package, or request is benign or part of an active chain.

Practical implication: correlate application execution with identity usage so anomalous privilege use is visible at the point of abuse.

Runtime AI security and model context protocol risk

Runtime AI security extends protection into live AI models and agents, where prompts, tool calls, and downstream actions become security-relevant events. The article also highlights Model Context Protocol, or MCP, as a workflow that links runtime-exploitable risk back to code and developer tooling. That combination matters because AI systems can create exposure through unsafe tool access, insecure defaults, or misuse of privileged context after deployment. The technical issue is not just AI output quality. It is whether the production AI path can be used to trigger unwanted behaviour, access sensitive resources, or open a route into the wider environment.

Practical implication: review AI runtime paths as identity-bearing systems and not just as content-generation services.

Threat narrative

Attacker objective: The attacker aims to turn live execution paths into durable control, allowing compromise, propagation, or exfiltration from systems that looked safe before runtime.

1. Entry occurred through exposed or vulnerable modern software, cloud infrastructure, or AI tooling that could be reached in production.
2. Escalation followed when attackers used runtime behaviour, privileged execution paths, or insecure AI and cloud defaults to expand access.
3. Impact came from infrastructure takeover, botnet propagation, or developer machine compromise once the live execution path was abused.

Breaches seen in the wild

• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.
• Codefinger AWS S3 ransomware attack — Codefinger used compromised AWS credentials to encrypt S3 buckets via SSE-C.

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 has become the operational layer where identity, code, and infrastructure meet. Static controls still matter, but they no longer define the real security boundary once software is executing. That is why runtime visibility is increasingly a governance issue, not just a tooling category. Practitioners should treat execution-time context as the place where policy either proves itself or fails.

Runtime AI security is now an identity problem as much as an AI problem. Once models and agents can act in production, their prompts, tool calls, and permissions become part of the identity plane. The article correctly frames AI runtime protection as monitoring behaviour rather than trusting configuration alone. Security teams should assume AI systems will be governed through the same entitlement and observation logic used for other privileged non-human actors.

Execution-time assurance exposes a named concept we should sharpen: identity blast radius. In this context, identity blast radius is the amount of damage a secret, workload identity, or AI-enabled runtime can create once it is live. The article's research on vulnerable functions and runtime exploitability shows that the real question is not whether a flaw exists, but how far it can reach in production. Practitioners should measure blast radius by runtime reach, not by inventory size.

Runtime assumptions fail whenever teams believe pre-runtime review can substitute for live verification. That assumption was designed for software that could be bounded by build pipelines and approval gates. It fails when an attacker can exploit a cloud service, package, or AI path only after deployment, because the risk materialises in execution rather than in design. The implication is that governance models must stop treating runtime as a secondary layer and start treating it as the primary enforcement point.

Modern attack research is collapsing the separation between application security and identity governance. The article's examples show that vulnerability, identity, and operational telemetry are now intertwined in the same incident path. A package exploit, a compromised runtime, or a misused AI workflow is no longer a pure AppSec issue once it can leverage access and move laterally. Practitioners should align AppSec and identity ownership around production behaviour, not organisational silos.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• Only 44% of organisations have implemented any policies to manage their AI agents, even though 92% agree that governing AI agents is critical to enterprise security.
• For a broader identity-control lens, the NHI Lifecycle Management Guide shows how provisioning, rotation, and offboarding logic must be extended to high-risk runtime identities.

What this signals

Identity blast radius is becoming the most useful way to interpret runtime security investments. When 70% of organisations already grant AI systems more access than a human would receive for the same job, per the 2026 Infrastructure Identity Survey, the security question is no longer whether a system is modern. It is whether its live privilege can be bounded.

Security leaders should expect runtime telemetry to migrate from an engineering concern to an identity governance control. The programmes that win here will be the ones that can tie execution data back to identities, entitlements, and approval boundaries without waiting for a post-incident review.

The next stage is cross-domain governance, where AppSec, cloud security, and IAM share one production view. That shift will force teams to define who owns runtime evidence, how exceptions are handled, and which events trigger identity review before impact spreads.

For practitioners

• Audit production paths for identity-bearing runtime risk Inventory where secrets, workload identities, and AI agent permissions are exercised after deployment, then distinguish those paths from build-time-only controls. Focus on which systems can actually execute privileged actions in production.
• Separate static confidence from runtime evidence Use runtime telemetry to validate whether approved code, packages, and AI workflows behave as expected under live conditions. Treat any mismatch between design-time review and production behaviour as a governance failure, not an exception.
• Connect AppSec findings to identity scope When a vulnerability or malicious package is found, determine which identities, service accounts, and tokens can reach it in production. The useful question is not just whether the flaw exists, but how far access allows it to spread.
• Treat AI runtime paths as privileged infrastructure Review AI models, agents, and assistants for tool access, data reach, and escalation paths that resemble privileged workloads. If they can act on systems or data, they need governance comparable to other high-risk non-human identities.

Key takeaways

• Runtime security matters because the real security boundary is now live execution, not design-time intent.
• The article's evidence points to a growing gap between what teams approve and what systems actually do in production.
• Security teams should align application, cloud, and identity controls around runtime behaviour, especially for AI systems and privileged workloads.

Key terms

• Runtime Security: Runtime security is the practice of detecting and controlling risk while software, workloads, or AI systems are actively executing. It focuses on live behaviour, process context, identity use, and network action rather than only design-time analysis or pre-release scanning.
• Cloud Application Detection and Response: Cloud Application Detection and Response, or CADR, is a runtime security approach that links live application behaviour to detection and response. It helps teams see execution context, identify abuse paths, and connect application-layer events to the identities and workloads involved.
• Runtime AI Security: Runtime AI security is the control of AI models and agents while they are operating in production. It covers prompts, tool calls, permissions, and downstream actions so organisations can monitor misuse and contain harmful behaviour as it happens.
• Identity Blast Radius: Identity blast radius is the amount of damage an identity, secret, or credential can cause once it is used in a live environment. It is a practical way to judge how far access can spread through production systems before containment or detection occurs.

What's in the full article

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

• Product-specific breakdown of CADR, AI-SPM, and AI-DR capabilities for teams evaluating runtime protection.
• Detailed discussion of the platform's vulnerable function enrichment approach and how it changes prioritisation.
• Expanded explanation of the AirBorne, ShadowRay 2.0, and Fluent Bit research findings.
• Additional context on the Application Attack Matrix and the runtime sensor observations.

👉 Oligo Security's full post covers the product details, research examples, and recognition moments behind the year-end recap.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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.