What should teams do if they suspect LLM-as-C2 is being used in their environment?

How to interpret suspected LLM-as-C2 activity

Assume the model path may be part of the control channel, not just a user productivity feature. The key question is whether the traffic is supporting an execution step, task handoff, or instruction relay from a process that should not be making those calls. That means you need to treat the model interaction as operational telemetry, not only content metadata.

Teams should look for whether the requests line up with an active process, a service token, or a script that should not be talking to an external model at that moment. A benign chat session usually has an obvious user workflow; LLM-as-C2 often appears as short, repeated, task-shaped exchanges that coincide with file staging, network probing, credential use, or privilege change.

When you inspect the pattern, separate the model endpoint from the surrounding host behaviour. An outbound prompt alone is weak evidence, but a prompt plus spawned child processes, unusual archive or compression activity, unexpected discovery commands, or follow-on traffic to new destinations is much stronger. This is the point at which the model is functioning like a command path, regardless of whether the payload looks like ordinary natural language.

What to verify in the host and network trail

Start with process lineage and execution context. Identify which parent process opened the connection, what account it ran under, and whether the same lineage is associated with software that normally uses the model. If the calling process has no business reason to reach an external LLM, or if the call appears during a scripted execution chain, treat that as a material escalation signal.

Then correlate the model traffic with privilege and access changes. If the same session also touches secrets stores, local browsers, shell history, remote admin tools, or file shares, the likely question is no longer “is this just AI use?” but “is this workflow steering the host to do work it should not do?” That distinction matters because LLM-as-C2 often hides inside otherwise ordinary application or automation traffic.

Endpoint and network teams should also check for repeated prompt patterns, tool invocation bursts, and new or unusual destinations immediately after a model response. The most useful evidence is sequence, not a single event: request, response, execution, and follow-on action. Where available, MITRE ATLAS adversarial AI threat matrix helps map those behaviours to known AI-oriented attack techniques, while MITRE ATT&CK Enterprise remains useful for the downstream credential access, discovery, and lateral movement stages.

How to respond without losing evidence or overreacting

If suspicion is credible, contain the path first, then preserve the chain of custody. Block or isolate the outbound model connection, snapshot the host state, and retain the prompts, responses, process tree, and nearby authentication events before remediation starts. The response goal is to determine whether the model was merely queried or was actively being used as an instruction relay during compromise.

Response should be proportionate to the observed coupling between the model and execution. If the model traffic is isolated and user-driven, tune detections and tighten access controls. If it is tied to a non-interactive process, privileged session, or post-exploitation behaviour, treat it as an active intrusion path and move to broader containment, credential review, and hunt expansion across adjacent hosts.

For organisations running agentic or automated AI workflows, OWASP Agentic AI Top 10 is a useful reference for identity and privilege abuse, tool misuse, and rogue agent behaviour. When the suspected path involves delegated access or machine-to-machine calls, OAuth 2.0 authorization flows and token exchange are the relevant control and investigation surfaces because they define how authority is being passed along the chain.

Practitioner Guidance

What to prioritise: Correlate the model call with the exact process, account, and privilege state at the time of execution. If you cannot tie the request to a legitimate workflow quickly, assume it may be a command channel and scope outward from that host.

What to verify: Confirm whether the same lineage also performed discovery, file access, archive creation, credential use, or remote execution. A single model request is not enough; the security signal is the combination of request shape and host-side action.

What good looks like: Teams can explain why each outbound model call exists, who initiated it, and what action followed. If that explanation depends on assumptions instead of logs, you do not yet have enough visibility for safe operation.

Practitioner takeaway: The practical test is whether the model is merely consulted or is actually steering execution. If the answer is unclear, treat the model channel as potentially hostile until host behaviour proves otherwise.

Related resources from NHI Mgmt Group

• Why do secrets stay dangerous even when they are no longer actively used?
• What should security teams do first when they suspect unauthorized access to a Snowflake environment?
• What should security teams do first when they suspect an attacker has only just entered the environment?
• Why are NHIs a critical concern for security teams?