Runtime security became the source of truth in 2025

At a glance

What this is: This is Oligo Security’s year-end reflection arguing that runtime security became the operational source of truth in 2025 as execution-time context, not pre-deployment assumptions, proved decisive across cloud and AI environments.

Why it matters: For IAM, PAM, and NHI teams, the lesson is that governance cannot stop at inventory or policy design when risk only becomes visible at runtime, especially for workloads, services, and AI-enabled systems.

Context

Runtime security is the discipline of understanding and protecting software while it is executing, not only before release. Oligo Security’s year-end analysis argues that 2025 was the year that execution-time context became the practical source of truth for modern software, cloud workloads, and AI systems.

The governance gap is straightforward: static inventories, pre-deployment scans, and design-time assumptions cannot fully describe what code does once it is live. For NHI, agentic AI, and workload identity programmes, that means the meaningful security question shifts from what exists on paper to what is actually exercised in production.

Key questions

Q: Where does runtime security fail if teams rely only on static inventories?

A: Runtime security fails when teams assume that configuration data, bills of materials, or pre-deployment scans tell the full story. They do not show what code actually executes, which functions are reachable, or whether a package behaves maliciously only in production. That is why runtime evidence is now the more useful source of truth.

Q: Why does runtime context matter for NHI and workload identities?

A: Because a service account or token only becomes dangerous when live code uses it. Runtime context shows which identities are exercised by real workloads, which paths they unlock, and whether their authority creates a larger blast radius than the entitlement record suggests.

Q: How do security teams decide whether an identity CVE is urgent?

A: Security teams should prioritise identity CVEs by whether the affected component sits in authentication, provisioning, admin, or privileged access paths, and by whether it is internet-facing or broadly reachable. A flaw in those paths is usually more urgent because it can expand access rather than just disrupt a single service.

Q: What does runtime security mean for AI systems in production?

A: It means security teams must evaluate observed behaviour, not only declared policy. If a model or agent can invoke tools, change actions, or interact with systems dynamically, then live execution becomes the control boundary that matters most.

Technical breakdown

Why runtime context outranks static inventory

Static tooling can enumerate assets, packages, or declared permissions, but it cannot reliably show how code behaves under live inputs, chained dependencies, or production traffic. Runtime security fills that gap by observing execution paths, function calls, and actual exploitability in context. That matters because many modern failures are not obvious from configuration alone. A package may look benign in a bill of materials yet still execute malicious behaviour only at runtime, while a vulnerability may appear severe on paper but never be reachable in production. Practical implication: treat runtime evidence as the deciding input for exposure triage, not as a secondary validation layer.

Practical implication: Use runtime evidence to prioritise exposure and remediation instead of trusting design-time inventories alone.

How runtime protection changes AI security

The article links runtime security to AI-SPM and AI-DR, which signals a shift from cataloguing AI assets to monitoring how models and agents behave in production. That is important because AI systems can be misused through prompts, agents can be manipulated through runtime interactions, and framework weaknesses can only be confirmed when execution occurs. In other words, AI security becomes a behaviour problem as much as a configuration problem. The same applies to identity: when an AI system or agent executes actions dynamically, the control question is whether its live behaviour stays inside the intended boundary. Practical implication: govern AI systems by observed runtime behaviour, not by declared intent alone.

Practical implication: Anchor AI governance in observed behaviour and runtime boundaries, not just model inventories or policy statements.

Why execution-time detection matters for cloud and software supply chains

Oligo’s analysis points to malicious packages, vulnerable functions, and infrastructure-layer exploits as examples of threats that only become fully visible when code runs. That is a reminder that software supply chain security does not end at CI or dependency approval. Runtime inspection can expose the exact functions that execute, the packages that actually load, and the attack paths that static review misses. For cloud and workload security teams, this makes execution context the bridge between vulnerability intelligence and real exposure. Practical implication: combine reachability, runtime telemetry, and exploit validation before deciding what is truly urgent.

Practical implication: Correlate reachability with runtime telemetry so your supply chain decisions reflect actual execution risk.

Threat narrative

Attacker objective: The attacker aims to turn reachable runtime behaviour into execution, privilege, and control over production systems.

1. Entry occurred when vulnerable packages, exposed AI infrastructure, or live application paths created a reachable execution surface for attackers.
2. Credential or privilege abuse followed when malicious code, exploit chains, or agent misuse executed inside production contexts with real authority.
3. Escalation happened as runtime flaws enabled deeper control of workloads, AI clusters, or cloud infrastructure beyond the originally exposed component.
4. Impact was attacker persistence, compromise, or botnet-style abuse inside environments that static review had not fully captured.

Breaches seen in the wild

• Microsoft SAS token exposure 2023: An over-permissive Azure SAS token in a Microsoft AI GitHub repo exposed 38TB, including workstation backups and Teams messages, for 3 years.
• xinference PyPI compromise 2026: Three xinference releases on PyPI carried a stealer for cloud, Kubernetes and registry keys, reportedly via a compromised bot account.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Runtime security became the source of truth because design-time truth was no longer enough: static inventories, code review, and pre-deployment scanning do not answer the question that matters most in modern environments, which is what executes and with what authority. Oligo Security’s 2025 recap reflects a broader shift across cloud and AI environments. The discipline now has to measure live behaviour, not just declared state, if it wants to stay relevant to practitioners.

Runtime visibility is the missing control plane for NHI and workload governance: service accounts, tokens, and workload identities are only meaningful once they are connected to execution context. A permission set that looks reasonable on paper can still create dangerous blast radius when a workload loads malicious code, a package executes unexpectedly, or an AI workflow invokes actions at runtime. The implication is that governance has to follow execution, not just issuance.

AI security and runtime security are converging around behaviour, not branding: the article’s discussion of Runtime AI Security shows that models and agents are now subject to the same basic governance question as workloads, namely whether observed action stays inside expected boundaries. That does not make every AI feature autonomous, but it does make execution-time monitoring unavoidable wherever live behaviour can change risk. Practitioners should stop treating AI posture as a separate silo from runtime control.

Execution-time exploitability is becoming the practical definition of urgency: vulnerable functions, malicious packages, and cloud infrastructure flaws all matter most when they are actually reachable in production. This is where static prioritisation breaks down, because severity without runtime reachability creates noise while live exploitability creates material exposure. Security teams need a runtime lens to decide which findings deserve immediate action.

Runtime security is becoming the operational proof standard for modern attacks: the market is moving toward evidence that ties vulnerability, exploitability, and behaviour together in one workflow. That trend aligns with how adversaries already operate across cloud, software supply chain, and AI environments. The practitioner conclusion is simple: if a control cannot speak to live execution, it is increasingly a secondary signal rather than the source of truth.

What this signals

Runtime evidence is replacing declared state as the practical control boundary: modern environments change too quickly for inventories and design-time reviews to remain authoritative on their own. The real governance question is now whether the workload, agent, or service behaved inside its intended boundary once it was live.

Execution-time control is becoming the common language across cloud, AI, and NHI governance: the same operational lesson shows up in all three domains, because authority only matters when code or agents actually exercise it. Practitioners should expect runtime telemetry, reachability, and live behaviour to drive more of their prioritisation decisions in 2026.

For practitioners

• Prioritise runtime reachability over static severity Use execution evidence to decide which vulnerabilities, packages, and code paths are actually exposed in production, then focus remediation on the ones that can be reached and exploited.
• Map workload behaviour to live authority Review which service accounts, tokens, and workload identities are exercised by running code, then compare that behaviour with the authority those identities carry in production.
• Separate AI posture from AI behaviour For models and agents in production, monitor what they actually do, which tools they invoke, and whether those actions stay inside approved runtime boundaries.
• Correlate supply chain data with production telemetry Do not stop at dependency approval or CI scanning. Confirm which packages, functions, and transitive components actually execute in live environments before assigning remediation priority.

Key takeaways

• Runtime security matters because live execution exposes risks that design-time controls cannot fully describe.
• The article points to AI, cloud, and software supply chain examples where runtime context determines whether a vulnerability is truly exploitable.
• Practitioners should treat runtime evidence as the deciding input for prioritisation, governance, and remediation across workloads, services, and AI systems.

Key terms

• Runtime Security: Runtime security is the practice of detecting and constraining malicious behavior while software is executing. It focuses on live workload activity, not just code quality or pre-deployment checks, so teams can contain abuse after a system is already running.
• Runtime Visibility: The ability to observe what an AI client actually accessed, which tools it used, and how it behaved during a session. It is more useful than entitlement snapshots for agent governance because it captures executed reality, not just approved access.
• Execution Context: Execution context is the live operating state of an application, including which libraries run, which syscalls execute, and which network paths are used. In security practice, it helps separate theoretical exposure from code that is truly reachable and therefore more urgent to remediate.
• Interaction blast radius: Interaction blast radius is the scope of harm that can follow from a single UI action in an agent-mediated workflow. It includes data exposure, tool invocation, state change, and downstream delegation. The larger the blast radius, the more the interface must be governed like a privileged control surface.

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.