AI-assisted malware like Koske exposes runtime defense gaps in cloud

At a glance

What this is: This is Aqua Security’s analysis of AI-assisted malware, using Koske to show that cloud runtime defenses must handle methodical, evasive code even before live AI-powered adaptation appears.

Why it matters: It matters because IAM, PAM, and cloud security teams need controls that act during execution, not just before deployment, when malware can already adapt its tactics inside the workload.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.

Context

AI-assisted malware is code that has been shaped by machine-generated output, even if it does not call a live model while running. In cloud environments, that distinction matters because the defensive challenge is not only how code was written but how it behaves once it reaches a workload.

Aqua Security uses Koske to illustrate a broader runtime gap: malware can arrive with prebuilt stealth, persistence, and evasion logic that defeats controls focused only on build-time hygiene. For identity and access teams, the lesson is that protection has to account for what executes inside the environment, not only what enters it.

The article also separates AI-generated malware from AI-powered malware, which keeps the governance question grounded in execution and not hype. That makes this a cloud runtime control problem first, and an AI threat problem second.

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 does AI-generated malware change cloud defense assumptions?

A: Because the threat can be methodically crafted before it ever reaches production. That means defenders cannot assume a sample will be crude or incomplete, and they need runtime controls that can catch coherent malicious behaviour even when the code looks operationally polished.

Q: What are the signs that runtime policy is failing against evasive malware?

A: Look for workloads that can alter firewall rules, invoke system utilities, or maintain persistence without an immediate policy response. If those actions are possible inside production, the runtime boundary is not enforcing the approved behaviour profile.

Q: What is the difference between AI-generated malware and AI-powered malware?

A: AI-generated malware is created with AI assistance but may run without any live model connection. AI-powered malware maintains a runtime feedback loop with a model and can adapt its actions based on execution results, which creates a more dynamic and harder-to-predict threat profile.

Technical breakdown

AI-generated malware versus AI-powered malware

AI-generated malware is produced with AI assistance, but it can still run as ordinary malicious code without any live model dependency. AI-powered malware, by contrast, maintains a live feedback loop with a model and can adapt its behaviour based on runtime results. That difference matters for defenders because the former can already contain branching logic, fallback paths, and evasion steps that look deliberate even when the malware is not dynamically reasoning during execution. The governance issue is not whether AI was involved in writing the code, but whether the payload can defeat static assumptions once it is inside the workload.

Practical implication: classify threats by runtime behaviour, not by whether AI was involved in authoring them.

Why runtime policy matters more than pre-deployment hygiene

Pre-deployment hygiene can reduce obvious defects, but it does not stop malware that is already valid, methodical, and purpose-built to survive in the target environment. Runtime policy sits at the point where behaviour becomes observable, which is where fileless execution, mining, firewall manipulation, and persistence mechanisms can be blocked or at least surfaced. In cloud workloads, that is the operational boundary that matters because the attack is often successful only after the payload starts executing. Static review may improve confidence, but execution-time control is the only place where malicious intent can be interrupted.

Practical implication: shift enforcement to runtime so behaviour, not just code, is subject to control.

Drift prevention as a containment control

The article’s mention of drift prevention points to a broader containment pattern: once a workload begins behaving outside its intended operating envelope, defenders need controls that can stop that divergence before it becomes persistence or lateral spread. Drift is not only configuration drift. In this context it is behavioural drift, where the runtime starts taking actions that the approved workload profile did not authorise. That makes runtime policy a governance layer for execution state, not just a malware detector. For cloud teams, this is where response moves from observation to interruption.

Practical implication: treat behavioural drift as a policy violation and block it at execution time.

Threat narrative

Attacker objective: The attacker wants durable execution inside cloud workloads while avoiding detection, blocking, and removal.

1. Entry occurs when AI-shaped malicious code is delivered into a cloud workload with enough structure to execute its own evasion and persistence logic.
2. The payload then seeks credentialed or privileged execution paths such as curl, wget, native sockets, and firewall changes to keep operating inside the environment.
3. Escalation comes from rootkit-style stealth, persistence, and defence evasion that help the malware remain resident and harder to detect.
4. Impact is the continued compromise of cloud workloads under a runtime profile that looks legitimate until malicious behaviour is already underway.

Breaches seen in the wild

• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
• CircleCI breach 2023: Malware stole a CircleCI engineer's SSO session; attackers exfiltrated customers' CI/CD secrets and keys, forcing a platform-wide rotation.

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

AI-assisted malware creates a runtime governance problem, not just a detection problem. When malware already contains methodical fallback logic, the defender is no longer dealing with a static sample that can be understood once and blocked forever. The security control that matters is the one that can interrupt behaviour while the workload is live. For cloud teams, that shifts the centre of gravity from analysis to enforcement.

Runtime defense becomes the point where cloud security and identity governance meet. A workload that can modify firewall rules, call system tools, and persist through rootkit-like techniques is operating with effective authority inside the environment. That means least privilege, execution policy, and workload containment have to be treated as runtime controls, not just provisioning choices. Practitioners should assume the attack surface is the running process, not the artifact in the repository.

AI-generated and AI-powered malware must be separated for governance purposes. AI-generated code can already be highly adaptive without any live model loop, while AI-powered malware adds feedback-driven behaviour that can change mid-execution. Those are different operational risks, and they demand different detection assumptions. The implication is that cloud defense programmes need behaviour-based control models that can hold even before a live model enters the attack chain.

Drift prevention is the right concept for malicious workload behaviour in cloud environments. The useful named concept here is behavioural drift: a workload begins following actions that no approved runtime profile should permit. Once that happens, persistence and evasion are already in play, so the issue is no longer simply malware presence. Practitioners should align runtime controls to the point where drift first becomes observable.

Static code quality does not equal defensive safety when the payload is methodical. Koske is noteworthy because the article describes a payload that appears complete, deliberate, and operationally coherent rather than broken or improvised. That means defenders cannot rely on the old assumption that AI-shaped malware will be crude and easy to spot. The practitioner takeaway is that cloud workloads need enforcement capable of stopping coherent malicious behaviour, not just malformed code.

From our research library:

• 96% of security operations teams report critical blind spots, most commonly in cloud infrastructure (74%) and identity and access behaviour (67%).
• Read next: Ultimate Guide to NHIs — Key Challenges and Risks

What this signals

Behavioural drift is the right control lens for AI-shaped malware. If a cloud workload can switch from approved behaviour to persistence, evasion, or policy manipulation during execution, pre-deployment confidence is no longer a sufficient security signal. Teams should use runtime enforcement to decide when a process has moved outside its allowed operating envelope.

The more important programme question is whether your current cloud controls can act on malicious intent after execution begins. That means tying workload protection to observable behaviour, not just software origin, and making sure your response path can isolate or block the process before the drift becomes durable compromise.

For practitioners

• Instrument runtime policy for malicious behaviour Turn on workload policies that can block fileless execution, suspicious command invocation, and unauthorised persistence behaviour at execution time.
• Separate AI-generated from AI-powered threat models Use different detection assumptions for code that was AI-assisted during creation versus code that maintains a live model feedback loop during execution.
• Treat behavioural drift as a containment trigger Define the point at which a workload’s runtime actions no longer match its approved profile and terminate or isolate that execution path.
• Prioritise controls that survive evasive payload design Assume malware may already include fallback paths, privilege manipulation, and stealth, then validate whether your runtime controls can still interrupt it.

Key takeaways

• AI-assisted malware can already arrive with deliberate stealth and persistence logic, which weakens any defence model that depends mainly on static pre-deployment checks.
• The article’s value is in separating code created with AI help from code that actively uses a live model, because the two threat modes behave differently in production.
• Runtime policy is the decisive control point when cloud workloads begin behaving outside their approved operating envelope.

Key terms

• AI-written malware: Malware generated or heavily assisted by a model during development, then deployed as ordinary executable code. The important distinction is that the AI role ends before runtime, so the payload behaves like traditional malware once it is compiled or delivered.
• AI-powered malware: Malware that consults a model during execution to generate instructions, adapt behaviour, or choose next steps. The model becomes part of the attack logic at runtime, which shifts detection from static code inspection toward observing external calls, timing, and changing process behaviour.
• Runtime Policies: Runtime policies are enforcement rules that control what a workload is allowed to do while it is running. They can be used to block dangerous actions, contain suspicious behavior, or automate response based on security requirements. In container environments, they turn detection into immediate control.
• Behavioural Drift: Behavioural drift is the gradual change in what an identity does compared with what it was originally approved to do. For AI agents, drift can come from prompt changes, model updates, expanded integrations, or altered workflows, which makes access review alone an incomplete control.

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.