TL;DR: Cloud-native protection now has to extend from code to cloud to runtime, because static scanning alone cannot keep pace with modern workload risk across containers, functions, and hybrid environments, according to Aqua Security. That shift makes continuous enforcement and detection the decisive control surface for identity and workload security.
At a glance
What this is: Aqua Security argues that AI workload protection must shift from static scanning to continuous runtime control across cloud native environments.
Why it matters: For IAM, PAM, and NHI teams, this reinforces that workload identity and privilege controls must be enforced in execution, not just approved at build time.
Context
Static scanning can confirm that a workload looked safe before deployment, but it cannot observe how that workload behaves once it starts interacting with cloud services, identities, and data. In cloud native and AI-adjacent environments, that gap matters because runtime behaviour is where privilege, persistence, and misuse become visible.
Aqua Security’s article frames runtime as the point where prevention and detection have to meet. The core governance issue is not whether code passed a scan, but whether the operating workload is still behaving within the identity and access assumptions that were true at release time.
Key questions
Q: How should teams balance static scanning and runtime control for cloud workloads?
A: Use static scanning to block known bad code, images, and configuration before deployment, but treat runtime control as the control that governs live behaviour. The two are complementary, not interchangeable. If a workload can access secrets or services in production, security decisions must continue after release, when actual process, network, and identity behaviour can be observed.
Q: What breaks when security stops at pre-deployment checks?
A: What breaks is the assumption that a clean build equals a safe workload. Once the service is live, it may call unexpected endpoints, use privileges in new ways, or interact with data that was not part of the original test path. That is where runtime containment and detection become necessary.
Q: How do security teams know if runtime protection is actually working?
A: Look for evidence that suspicious behaviour is detected fast enough to contain it before the session or workload expands the blast radius. Effective runtime protection produces actionable alerts, ties them to containment steps, and shows that abnormal access can be limited during active execution, not only reviewed afterward.
A: They should apply one identity and enforcement model across those execution types so that visibility and control do not disappear when the workload changes form. The practical goal is consistent monitoring of workload identity, permissions, and behaviour across every runtime boundary.
Technical breakdown
Why static scanning misses workload behaviour
Static scanning inspects code, images, and configuration before deployment. That is useful for catching known misconfigurations and vulnerabilities, but it cannot model everything a running workload will do once it connects to APIs, secrets, clusters, and service identities. Runtime control matters because the attack surface changes as the workload starts making authenticated requests, opening network paths, and consuming data. In cloud native environments, the security question is not only whether an artifact was clean at build time, but whether its live identity, permissions, and process behaviour remain acceptable under production conditions.
Practical implication: treat build-time scanning as a gate, not a substitute for runtime enforcement.
How runtime control changes cloud native security
Runtime control monitors what workloads actually do after deployment and can intervene when behaviour diverges from expected policy. That includes detecting suspicious process execution, unexpected network calls, unapproved file writes, or attempts to use permissions that the workload should not exercise. For identity teams, the important shift is that authorization becomes behavioral as well as declarative. A workload may be formally entitled to access a resource, but that access still has to be bounded by context, environment, and observed execution patterns. This is especially relevant when the same workload moves across containers, functions, and hybrid environments.
Practical implication: align runtime policy with the real privilege envelope of each workload identity.
Why full lifecycle cloud native security is now the baseline
A full lifecycle model links pre-deployment hygiene with runtime protection, which is the only way to keep up with modern cloud native delivery. The article’s emphasis on continuous protection reflects a broader truth: identity and workload security fail when they are split across separate teams, separate tools, and separate moments in the delivery chain. Cloud native environments compress change cycles, so a control that only fires before release will miss the stage where most abuse emerges. The result is a governance gap between intended access and actual execution.
Practical implication: manage workload identity and enforcement as one lifecycle, from build through production.
NHI Mgmt Group analysis
Runtime control is now the decisive boundary for cloud native workload security. Static scanning still has value, but it only validates the artifact before execution. Once the workload starts authenticating, consuming secrets, and calling services, the real security posture is determined by runtime behaviour. Practitioners should treat runtime as the authoritative control plane for workload identity and access.
Continuous protection closes the gap between approved access and observed use. Many cloud native programmes still assume that a clean build and approved deployment are enough. That assumption breaks once a workload can drift through environment changes, service-to-service calls, and privilege use that were not visible at release time. The implication is that governance must follow the workload into production, not stop at the pipeline.
Identity controls for workloads have to be enforced at execution time, not just issuance time. A workload can be validly provisioned and still become unsafe when it begins using permissions in ways the release process never anticipated. That makes runtime policy, detection, and containment central to NHI and workload identity governance. Practitioners should think in terms of live enforcement rather than static approval.
Cloud native security is converging on one lifecycle model, not separate product silos. The article points to a market direction where code security, container security, and runtime detection are no longer distinct problems for separate teams. That does not eliminate specialised controls, but it does change procurement and operating models. Practitioners should expect governance to be measured by continuity across the delivery chain.
Runtime visibility is becoming the named concept that matters most: control without observation is incomplete. The operational lesson is that security teams need to know not only what was deployed, but what that workload actually did after it went live. That is the practical dividing line between policy intent and production reality. Practitioners should build for live observation and intervention as a default.
What this signals
Runtime enforcement is becoming the point where cloud native security either holds or fails. Static checks can only validate what was true before deployment, while runtime policy sees what a workload is actually doing in production. For practitioners, that means detection and containment need to move closer to execution, especially where workloads hold access to secrets and service identities.
Identity governance for workloads now needs live context. A service account or workload identity that looks acceptable in the pipeline can become risky once it starts using permissions in production. The programme implication is simple: govern entitlement, but verify behaviour continuously once the workload is active.
For practitioners
- Prioritise runtime enforcement for cloud workloads Use live policy controls to stop or contain suspicious behaviour after deployment, especially where workloads can reach secrets, APIs, or sensitive data. Do not rely on image or code review alone.
- Map workload identities to production privileges Inventory which service accounts, tokens, and workload identities each deployed workload can use, then compare that to what the workload actually needs during execution.
- Separate pre-deployment hygiene from runtime decisions Keep static scanning as an admission control, but route runtime anomalies into a distinct response path that can isolate or restrict the workload without waiting for the next release.
- Review hybrid and serverless coverage gaps Check whether your current controls follow the workload across containers, functions, virtual machines, and hybrid environments, or whether visibility drops when execution moves outside one platform.
Key takeaways
- Cloud native workloads cannot be secured by build-time review alone because the most important risk appears after deployment.
- The article’s central shift is from static scanning to continuous runtime control across code, cloud, and production execution.
- Practitioners should align workload identity governance with live enforcement so that permissions, behaviour, and response stay connected.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Workload identities can be overexposed once runtime behaviour exceeds pipeline assumptions. |
| NHI-06 — Insecure Cloud Deployment Configurations | The article centres on cloud native controls that must extend into live deployment conditions. | |
| Recommendation — Review workload privileges against observed runtime behaviour and remove access that production execution does not justify. Validate cloud deployment controls at runtime, not only during pre-deployment scanning. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Runtime control depends on governing what workloads are authorised to access once live. |
| Recommendation — Map workload entitlements to PR.AA-05 and verify that live access remains consistent with policy. | ||
| MITRE ATT&CK | TA0007;TA0008 — Discovery; Lateral Movement | Runtime compromise often surfaces when workloads discover or reach resources beyond intended scope. |
| Recommendation — Trace suspicious workload behaviour against discovery and lateral movement tactics to spot misuse in production. | ||
Key terms
- Runtime control: Controls that enforce policy while an AI system is operating, rather than after the fact. For healthcare chatbots, runtime control includes data masking, output filtering, access scoping, and immutable logging so the organisation can defend the interaction itself.
- Cloud Native Application Protection Platform: A CNAPP is a cloud security platform that combines posture management, workload protection, and entitlement analysis in one operating model. In practice, it tries to connect misconfiguration, identity, and runtime risk so teams can see how exposure becomes impact across cloud environments.
- Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.
- Continuous protection: Continuous protection is the practice of keeping security controls active from development through production rather than stopping at deployment. For workloads, it means monitoring and enforcing policy while the system is running, where risk often changes faster than release cycles can absorb.
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 24, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org