TL;DR: Koske illustrates the difference between AI-generated malware and AI-powered malware, where static code can already embed stealth, persistence, and evasion patterns even before live model feedback arrives, according to Aqua Security. The practical lesson is that runtime policy, not pre-deployment hygiene alone, now has to absorb AI-shaped threat variation.
At a glance
What this is: This is Aqua Security’s analysis of AI-assisted malware like Koske and the runtime controls used to detect and block it.
Why it matters: It matters because cloud workload defenders need runtime visibility and enforcement that can respond to AI-shaped malware behavior, not just known signatures or build-time checks.
👉 Read Aqua Security's analysis of AI-assisted malware detection and blocking
Context
AI-assisted malware changes the defender's problem from spotting a fixed sample to handling code that can adapt its execution path at runtime. In cloud native environments, that pushes security teams toward runtime policy, drift prevention, and active blocking rather than relying only on pre-deployment inspection.
For IAM and workload security teams, the key issue is not whether the malware was written by AI, but whether the environment can stop malicious behavior after execution begins. That matters for NHI governance, workload identity, and cloud control planes because modern attacks increasingly target the execution layer where permissions are already in place.
Key questions
Q: How should security teams block AI-assisted malware in cloud workloads?
A: Security teams should block AI-assisted malware by combining runtime policy, drift prevention, and execution containment. The goal is to stop suspicious behavior after the workload starts, not just scan code before deployment. Audit mode helps teams tune controls safely, while enforce mode should be used for actions that should never occur in production, such as fileless execution or unauthorized mining.
Q: Why do AI-generated malware samples create problems for traditional scanning?
A: AI-generated malware can look more methodical and complete than hand-written samples, which makes static signatures and pattern matching less reliable. Traditional scanning is strongest when threats are stable and well known. It becomes weaker when attackers can generate new variants quickly, embed fallback logic, and alter execution paths without changing the core intent of the malware.
Q: What breaks when cloud workloads have too much runtime freedom?
A: Too much runtime freedom lets malware use legitimate tools and paths to complete malicious objectives. If a container can reach shells, networking tools, or firewall controls without tight restrictions, an attacker can pivot from initial execution to persistence and evasion. The breakdown is not just technical exposure. It is governance failure over what the workload should be allowed to do at runtime.
Q: How do teams decide between audit mode and enforce mode for runtime controls?
A: Teams should use audit mode first when they need to validate policy impact or learn what normal workload behavior looks like. Enforce mode is appropriate when the behavior is clearly malicious or clearly out of scope. The decision should be based on business tolerance for interruption, confidence in policy quality, and the likelihood that the behaviour is operationally required.
Technical breakdown
AI-generated malware versus AI-powered malware
AI-generated malware is code shaped by AI during creation, but it still executes as static malware once deployed. AI-powered malware goes further because it can maintain a live feedback loop with a model during execution, changing tactics based on results. That distinction matters. The first changes the quality and speed of malware authoring. The second changes the behaviour of the attack itself, because it can adapt in response to blocking, detection, or failed steps. Koske sits in the first category, but it points toward the second.
Practical implication: treat AI-generated code as a precursor to adaptive threats, and design controls for runtime behavior, not just static samples.
Runtime policy, audit mode, and enforce mode
Runtime policies decide what a container can do after it starts, including whether execution is observed or blocked. Audit mode records suspicious behavior without stopping it, which helps with validation and tuning. Enforce mode actively blocks actions such as cryptocurrency mining, fileless execution, or drift from expected state. This is a control-plane decision, not just a malware detection feature. The value is that malicious behavior can be interrupted where static scanning has no visibility, especially in ephemeral workloads that can launch, mutate, and disappear quickly.
Practical implication: use audit first to validate policy coverage, then move to enforce for known-bad behaviors that should never be allowed in production.
Why cloud native workloads need behavior-based containment
Cloud native workloads are attractive targets because they often run with broad entitlements, fast deployment cycles, and short-lived execution contexts. Malware that uses curl, wget, firewall changes, rootkits, or fileless execution can bypass assumptions built for slower, more stable systems. That is why drift prevention and execution controls matter: they constrain what a running workload can actually do, even when the binary or script itself looks benign at first glance. The technical problem is containment under runtime uncertainty.
Practical implication: pair workload identity and entitlement scoping with runtime containment so malicious behavior is limited even when code slips past earlier checks.
NHI Mgmt Group analysis
AI-generated malware is not the same as AI-powered compromise. Koske shows that AI can already improve malware construction without requiring a live model in the attack loop. That means defenders should not wait for fully autonomous malware before changing controls. The field should treat AI-generated code as an intermediate but serious stage in threat evolution, especially in cloud native environments where execution changes quickly and analysis windows are short.
Runtime enforcement is now the decisive control plane for cloud malware. Static inspection can flag known patterns, but it cannot reliably stop malware once the workload is executing and has access to tools, network paths, or shell utilities. Aqua Security’s framing reinforces a broader industry point: containment has to happen where the workload acts, not only where it is built. Practitioners should read this as a signal that runtime policy belongs in the core security model, not as an optional add-on.
Drift prevention is a workload identity control as much as a malware control. Malware like Koske succeeds when the environment tolerates behaviour that departs from intended execution state. That is the same governance problem identity teams face when workload permissions are wider than the task requires. The named concept here is runtime drift exposure: the wider the permitted behavior surface, the more room malware has to pivot. Practitioners should narrow execution paths before they try to detect every malicious variant.
AI-shaped threats collapse the gap between development and production risk. The same ecosystem that produces code assistance and automation can also accelerate malicious scripting, payload refinement, and post-exploitation adaptation. This does not make every AI-assisted threat autonomous, but it does make threat creation cheaper and faster. For IAM, PAM, and workload teams, the implication is clear: policies designed only for known binaries and stable workflows will age badly against evolving malware authoring methods.
Cloud native security teams need behavior-based assumptions, not sample-based comfort. The important question is no longer whether a threat matches yesterday's signature. It is whether the platform can observe, constrain, and interrupt suspicious runtime behavior before the objective is reached. That perspective aligns with OWASP NHI and NIST CSF thinking around execution containment, access scoping, and continuous verification. Practitioners should evaluate whether their controls can fail closed when malware mutates its path.
From our research:
- 67% of security leaders still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to The 2026 Infrastructure Identity Survey.
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
- For the broader governance context, see The 52 NHI breaches Report for recurring patterns in non-human identity exposure and control failure.
What this signals
Runtime containment is becoming the practical boundary between acceptable workload risk and uncontrolled execution. Teams that still rely on build-time scanning alone are already behind the threat model. With 67% of security leaders still relying heavily on static credentials despite the risks they pose to agentic AI deployments, per The 2026 Infrastructure Identity Survey, the governance pattern is clear: static assumptions do not survive adaptive threats.
AI-shaped malware will pressure identity programmes to think in terms of permitted behavior, not just authenticated access. That shifts attention toward workload identity scoping, containment boundaries, and runtime drift detection. Teams that already track entitlement scope and execution state will have a better chance of interrupting malicious behavior before it becomes persistence or lateral movement.
AI-assisted threat creation raises the value of controls that fail closed under uncertainty. When defenders cannot be certain a sample is complete or static, they need policies that constrain action rather than simply identify known bad code. In practical terms, that means connecting container protection, secrets governance, and least privilege into one operational model.
For practitioners
- Separate detection from prevention in runtime policy design Use audit mode to validate what a workload actually does, then move high-confidence malicious behaviors to enforce mode so execution can be blocked in production.
- Constrain shell and network tool access in containers Limit access to utilities such as curl, wget, and firewall modification paths unless they are explicitly required for the workload's function.
- Apply drift prevention to expected workload state Define the allowed runtime state for each workload and block unexpected changes in execution path, privilege use, or persistence behavior.
- Tie workload permissions to task scope Review workload identity and entitlement scope so a compromised process cannot freely pivot into broader network, filesystem, or control-plane actions.
Key takeaways
- AI-generated malware already changes the quality of threats, even before live model feedback enters the attack loop.
- Runtime controls matter because static inspection cannot reliably stop malicious behavior once a workload is executing.
- Teams should tighten workload permissions, apply drift prevention, and use enforce mode for behaviors that have no legitimate production use.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Runtime malware exposure maps to weak workload identity and control scoping. |
| NIST CSF 2.0 | PR.PT-1 | Protective technology should limit malicious execution in runtime environments. |
| NIST Zero Trust (SP 800-207) | PR.AC-4 | Least privilege and continuous verification are central to runtime containment. |
Scope workload permissions tightly and validate runtime behavior against expected identity use.
Key terms
- AI-generated malware: Malware whose code is produced or heavily shaped by an AI system before deployment. The result can be more methodical and adaptable than typical hand-written samples, but it still behaves as static malware once executed unless it has a live model feedback loop.
- AI-powered malware: Malware that stays connected to a live model during execution and changes its behavior based on runtime feedback. This makes the attack adaptive rather than fixed, which raises the value of runtime controls and behavior-based containment.
- Runtime policy: A set of rules that governs what a workload may do while it is running. In cloud native environments, runtime policy is used to observe or block actions such as unauthorized execution paths, persistence, or suspicious tool use after deployment.
- Drift prevention: A control that blocks a workload from deviating from its approved runtime state. It limits unexpected changes in behavior, configuration, or execution path, which is especially important when malware tries to pivot through legitimate tools or system changes.
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.
This post draws on content published by Aqua Security: How to Detect and Block AI-Assisted Malware Like Koske. Read the original.
Published by the NHIMG editorial team on 2025-08-12.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org