Cisco Talos’s CAIRN Framework Tracks Malware That Uses AI to Choose Its Actions

Cisco Talos’s CAIRN Framework Tracks Malware That Uses AI to Choose Its Actions

Updated September 22, 2026

Security researchers at Cisco Talos have released an open-source framework designed to identify and study malware that incorporates artificial intelligence. The framework, called the Cognitive Artifact Intelligence Research Network (CAIRN), is intended to detect traces left by AI services in malicious software and help researchers classify samples over time.

Talos used CAIRN to identify a Windows malware tool dubbed CLOSEDQUORUM. According to reporting by Wired, the program queried as many as four large language models—including DeepSeek, Qwen, Mistral and Google Gemini—to determine what actions to take. Researchers said it could target credentials and cryptocurrency. They have not publicly established the malware’s origin or confirmed its use in a specific active campaign, so the finding should be read as evidence of a capability and a detection problem, not proof that AI-directed malware is already widespread.

That distinction matters. Security teams are accustomed to tracking code families, infrastructure, and operator behaviors. When an implant consults external AI services, its behavior may vary between executions, and the reasoning process can be partly hidden behind commercial APIs. CAIRN’s premise is that the integration itself can leave observable “fingerprints”—technical traces that defenders can use to group samples and investigate how AI is being used.

What CAIRN is meant to do

Traditional malware analysis often begins with a sample: analysts inspect its code, identify network connections, observe behavior in a sandbox, and compare it with known families. A framework that looks for AI integration adds another question: does the software communicate with model endpoints or otherwise reveal that a language model is in the decision loop?

An AI service call alone is not proof of malicious intent. Legitimate applications use model APIs, and ordinary malware can contact cloud services for many reasons. A useful detection approach must combine multiple indicators: the application’s behavior, the destination and timing of requests, the instructions or responses involved when visible, and the actions taken on the compromised system. CAIRN is valuable if it helps analysts find and compare those traces without treating every AI-related network connection as an infection.

The framework also addresses a research gap. Public examples of malware that call language models have been limited, making it hard to measure whether such techniques are experimental curiosities or a growing operational pattern. A repeatable way to search samples could improve that picture. It may let defenders track changes in the technique, identify reused components, and share findings across organizations.

Open-source availability can help independent researchers validate the method and adapt it to their own telemetry. It can also reveal limitations more quickly than a closed tool, provided the project documents what it detects, what it misses, and how analysts can reproduce results. CAIRN should be evaluated on those practical properties—not on the dramatic possibility of a machine-controlled “hive mind.”

What the CLOSEDQUORUM finding suggests

The reported behavior of CLOSEDQUORUM is notable because the software is said to query several model providers and select or combine their responses to decide its next step. Redundancy could make a malicious system more resilient if one service is unavailable, but model access does not automatically make malware more capable. The system still needs an initial foothold, permissions, working network access, and code that can translate model output into actions.

That last point is central. A language model does not independently enter a machine or steal information simply because it is asked a question. The surrounding program determines what data is supplied, which tools are available, and whether an output triggers an operation. In this reported case, the concern is the combination: an implant with access to a Windows environment, repeated model queries, and an execution mechanism that can act on the answers. Analysts need to establish how much autonomy exists in practice and which operations remain constrained by fixed code.

The use of several models may also create operational weaknesses. API access can be rate-limited, logged, blocked, or revoked. Providers can change model behavior or terms. Network defenders may detect unusual outbound requests, especially from machines that have no business communicating with those services. A malware operator who relies on external models introduces dependencies that defenders may exploit.

At the same time, simple domain blocking is unlikely to be sufficient in every organization. Businesses may legitimately use AI services, and attackers can route traffic through compromised infrastructure or proxies. Detection must account for context: which process is making the request, whether the host normally uses that service, what data is being sent, and what activity follows. CAIRN’s value will depend on helping defenders connect these observations.

Why this differs from ordinary automation

Malware has long used scripts, decision trees, and command servers. The new element is not that software can make choices; it is the possibility that a model can interpret a less rigid instruction or adapt a sequence based on changing context. Whether that yields a meaningful advantage depends on the quality of the model integration, the prompt, the available tools, and the environment.

Security communication should avoid overstating what “autonomous” means. The word can describe a system that chooses among a few prewritten actions, or one that plans a longer sequence with limited human input. Those are not equivalent. Public reporting says CLOSEDQUORUM queried models for direction, but detailed technical documentation is needed to determine how much control the model actually exercised, whether an operator configured goals beforehand, and what safeguards or constraints existed.

Defenders should look for evidence at multiple layers:

• Endpoint behavior: unexpected scripts, new persistence mechanisms, suspicious process trees, or credential access.
• Network activity: unusual connections to model APIs, new cloud destinations, or repeated requests from a process that has no approved AI use.
• Identity signals: abnormal sign-ins or token use following a suspicious process event.
• Data movement: unexpected archive creation, uploads, or access to cryptocurrency wallets and credential stores.

No single signal is conclusive. A developer workstation may legitimately run local experiments and call external model APIs. A server may have no reason to do so. Policies should reflect role and use rather than block all AI traffic indiscriminately.

Practical steps for security teams

Organizations can take useful action without assuming that every attacker now has an AI agent. First, maintain an inventory of approved AI applications, model endpoints, and service accounts. Where possible, route organizational AI use through managed gateways that provide authentication, logging, and policy controls. This helps distinguish sanctioned use from unknown programs making model requests.

Second, apply least privilege. Workstations and services should not have broad access to credentials, sensitive directories, or administrative tools unless their tasks require it. If malware gains a foothold, limiting permissions reduces the actions available to any process—AI-assisted or otherwise. Protect secrets in dedicated stores, rotate exposed credentials, and use multi-factor authentication resistant to phishing where supported.

Third, monitor process-to-network relationships. A network alert for an AI API is more informative when combined with the executable that initiated it, the user context, the host’s usual behavior, and any subsequent file or identity activity. Security operations teams should test whether their endpoint and network tools preserve this context, then create triage procedures for unexpected model traffic.

Fourth, practice response scenarios. A tabletop exercise can ask how the organization would isolate a host, revoke API tokens, rotate credentials, preserve evidence, and notify affected teams if an unknown program used model services. Include both cloud-hosted and locally run models in the discussion. The objective is not to predict a particular malware family; it is to make sure basic incident response does not depend on recognizing a brand-new technique.

Finally, follow technical disclosures as they mature. Analysts should seek primary documentation from Cisco Talos, sample hashes, detection rules, observed indicators, and a clear explanation of CAIRN’s methodology. Where a claim rests on a single sample or a researcher’s characterization, that uncertainty should remain explicit. Shared, reproducible analysis is more useful than sensational labels.

What remains unknown

The public accounts do not settle how often AI-integrated malware is being used in real incidents, whether CLOSEDQUORUM successfully compromised victims, or who operated it. They also do not show that the models themselves were compromised. The reported design appears to use commercial model services as external inputs; that is a different issue from a model provider intentionally or accidentally enabling an attack.

Researchers’ estimate of the broader landscape should be tested against independently collected samples and transparent definitions. A framework may uncover previously missed examples, but findings depend on the scope of the sample set and the signals used to identify AI integration. A detection tool can improve visibility while still producing false positives or missing techniques that leave different traces.

For now, the development is significant as a measurement step. CAIRN gives defenders a proposed way to study a poorly documented behavior, and CLOSEDQUORUM illustrates why analysts want evidence before the technique becomes common. The responsible conclusion is measured: some malicious software is reported to consult AI models during operation; the scale and effectiveness remain uncertain; and organizations should monitor unusual AI-service use as part of broader endpoint and identity defense.

AI vendors can contribute by publishing abuse-reporting channels, responding to credible threat reports, and providing security controls for API accounts. Providers should not expose private customer data to other customers, and they should make it possible for organizations to restrict or monitor model access. Those measures complement endpoint defense; they do not transfer responsibility for securing a customer’s computers to the model provider.

The same evidence-first standard should guide coverage of the story. Calling a capability “fully autonomous” without describing its boundaries risks confusing readers and security teams. The useful questions are concrete: What does the malware observe? Which decisions are delegated? What can it execute? How does it persist? Which infrastructure does it contact? Can independent analysts reproduce the result? Answers will determine whether CAIRN becomes a durable detection aid and whether the threat deserves a change in defensive priorities.

Sources and further reading

• Wired: A new tool found malware that’s guided by an AI hive mind
• Cisco Talos Intelligence Group
• Cisco Talos threat intelligence
• CISA: Secure Our World and cybersecurity guidance
• MITRE ATT&CK knowledge base
• NIST Cybersecurity Framework
• CERT-UA advisories
• Google Cloud: Threat Horizons reports

Coordinating detection across organizations

AI-related indicators are most useful when teams can share them in a structured way. Security providers, incident responders, and public agencies can compare hashes, endpoint behaviors, and network patterns while protecting customer-identifying information. A common vocabulary for describing model use could help distinguish an AI API call that is part of an approved workflow from one initiated by an unexpected process.

Information sharing still requires validation. An indicator that is useful in one environment can be noisy elsewhere, especially when many organizations use the same cloud services. Teams should record confidence, source, and observed context alongside indicators so that recipients can assess relevance rather than treating every signal as a confirmed compromise.

The aim is early visibility, not a new alarm label. If CAIRN helps researchers map how AI services are integrated into malicious tools, the findings can inform endpoint rules, threat hunting, and provider abuse response. But operational defenses should remain grounded in evidence about actual execution and impact.

A measured conclusion

The most consequential question is not whether malware can call a model; any program with internet access can call a service if it has credentials and network reach. The question is whether delegating decisions to a model changes an attacker’s scale, adaptability, or reliability enough to alter defensive practice. That requires comparative evidence across samples and campaigns.

Researchers should describe what is known and what remains uncertain. For CLOSEDQUORUM, public coverage identifies a model-polling design and the capability to target credentials and cryptocurrency, but does not establish its operator or prevalence. Those are meaningful findings, and they should be reported with their limits intact.