AI-written malware and LLM-as-C2: what changes for IAM teams?

TL;DR: AI is lowering the cost of malware creation, accelerating variant churn, and shortening the lifespan of static indicators, while the runtime constraints attackers face remain anchored in identity, privilege, and execution boundaries, according to Orca Security. Static detection is losing durability faster than attackers need to change tactics, so runtime visibility is now the more stable defensive signal.

NHIMG editorial — based on content published by Orca Security: LLMjacking: How Attackers Hijack AI Using Compromised NHIs

By the numbers:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.

Questions worth separating out

Q: How should security teams detect AI-written malware without relying on signatures?

A: Security teams should prioritise runtime behaviour over file identity.

Q: Why does AI-assisted malware still depend on identity and privilege controls?

A: Because model assistance changes how the code is produced, not the fact that it must run inside a real environment.

Q: What do security teams get wrong about LLM-as-C2?

A: The common mistake is treating it as a novelty instead of an execution design pattern.

Practitioner guidance

• Instrument runtime behaviour at the kernel layer Collect process, file, network, and privilege telemetry at execution time so regenerated payloads can be investigated by what they do rather than by their hash or name.
• Correlate malware alerts with identity context Map each suspicious process to the service account, token, workload identity, or metadata-derived privilege it is using, because runtime access determines blast radius.
• Harden credential exposure paths inside workloads Remove secrets from code, config files, and environment variables wherever possible, and limit access to metadata services so malware cannot cheaply expand privileges after entry.

What's in the full article

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

• eBPF-based telemetry examples that show how runtime behaviour is observed at the kernel level.
• The article's breakdown of how AI-written malware differs from AI-powered malware in execution.
• Examples of process, network, and file-access patterns the vendor uses to spot suspicious runtime activity.
• How the platform correlates attack path reachability with asset criticality during investigation.

👉 Read Orca Security's analysis of AI-written malware and runtime defence →

AI-written malware and LLM-as-C2: what changes for IAM teams?

Explore further

View Full Forum →  |  NHI Foundation Course →