Autonomous C2 changes the detection boundary. Watch the model call, not only the operator.

Cisco Talos reported CLOSEDQUORUM on 22 September as the first reported autonomous AI command-and-control implant. Talos says the malware uses commercial cloud models to drive execution on an infected environment, shifting part of the attack chain from a remote operator into model-mediated decisions on the host.

The obvious reading is that defenders now need to detect malicious prompts. That is too narrow. The operational change is that command-and-control can look less like an attacker issuing a sequence of commands and more like an endpoint repeatedly consulting a legitimate model service, then acting locally on the response.

The model request becomes part of C2 telemetry

Cisco's Snort rule documentation for CLOSEDQUORUM classifies its traffic as malware command-and-control and looks for specially crafted LLM chat-completion messages associated with the implant. Cisco also records the rule under application-layer protocol C2 and says attacks or scans have been seen in the wild.

That creates a detection gap for organisations that allow outbound access to commercial AI services but treat those destinations as ordinary SaaS. Destination reputation alone cannot distinguish a developer calling a model from malware asking the same class of service what to do next. Detection has to join process identity, model-bound network traffic and the local actions that follow.

When the decision loop moves into the implant, model traffic becomes command-and-control evidence.

Agentic malware changes what an investigation must preserve

Traditional C2 analysis prioritises the remote infrastructure, commands received and operator timeline. An autonomous loop adds another evidentiary layer: the prompt sent by the implant, the model endpoint, the response path and the process that consumed it. Without those events, responders can see execution without reconstructing why the malware selected that action.

This also changes containment. Blocking one attacker-controlled domain is insufficient when the implant can rely on a legitimate cloud model endpoint. Egress policy needs to bind approved AI destinations to approved processes, identities and workloads rather than granting host-wide access because the domain itself is trusted.

Treat AI egress as executable authority

Security teams should inventory which endpoints can reach external model APIs, record the process and workload identity behind those connections, and alert when an unapproved binary initiates model traffic. Where TLS inspection or provider-side audit data is available and lawful, preserve enough metadata to correlate requests with subsequent process, file and network activity.

The control objective is not to block AI traffic. It is to stop a legitimate model service from becoming an unobserved decision channel for malicious code. CLOSEDQUORUM makes that distinction operational: once software can outsource decisions to a model, AI egress belongs in the same control plane as other command-and-control paths.

Written by the Devence Lab research team.