Seven Model Backends Behind One Autonomous Attack Framework
Unit 42 documented a Hermes Agent campaign with seven interchangeable model backends and more than 460 targets. The useful defensive lesson sits at the model egress boundary: authorize the identity and destination for every outbound AI request, then preserve the decision record independently of the chosen provider.
On July 30, 2026, Unit 42 described an operator who connected the open-source Hermes Agent framework to seven interchangeable model backends. DeepSeek handled the primary reasoning, while Qwen, GLM, Kimi, MiniMax, Claude Code, and OpenAI Codex also appeared in the configuration. One Telegram command launched scanning, research, exploit selection, and attempts against more than 460 targets. I think the seven-provider configuration is the most important artifact in the report because it strips away the comforting idea that defenders can build policy around one model vendor.
The campaign largely failed, and the published compromise counts conflict, a distinction that matters. A security argument should survive without inflating an incident, so I will keep the focus on the outbound model calls that made the framework work.
Seven backends behind one framework
Unit 42's July 30 report identifies the actor as knaithe, also known as KnYuan, and assesses that the operator was based in Zhuhai, China. Hermes Agent supplied the orchestration. Its configuration supplied a menu of model endpoints that the same workflow could call as the operator changed providers or tools.
That menu changes the defensive unit. A rule that blocks one DeepSeek hostname leaves six configured alternatives. A control that relies on a provider refusing an offensive request hands the enforcement decision to a remote model service. The local facts are more useful: which authenticated workload opened the connection, which model endpoint it selected, what route it called, and which policy applied at that moment.
The exposed working directory made this visible in a very physical way. The agent accidentally started a Python HTTP server and published API keys, session logs, model configurations, exploit scripts, and target lists. Seven provider entries in one directory are a better architecture diagram than a polished 47-slide security deck.
The campaign record requires careful reading
BleepingComputer reported on July 31 that the actor used DeepSeek through Hermes Agent to automate target discovery and exploitation work. The Hacker News coverage from the same date says the attempts against exposed Langflow and n8n systems failed because the targets lacked the configurations required by the selected exploits.
Published figures also describe three organizations affected by data exfiltration, command execution on 11 Marimo instances, and only three confirmed successfully exploited targets across the operation. The sources had yet to reconcile those numbers when this article was prepared on August 5. Treating them as one clean compromise total would manufacture certainty.
The exploitation of Citrix NetScaler, Langflow, n8n, Marimo, Apache Tomcat, and Windows IKE VPN services occurred outside DeepInspect's boundary. A policy gateway does not patch an exposed n8n instance. The relevant boundary appears earlier, when an authenticated agent inside an environment makes HTTP requests to an LLM API to obtain reasoning or code.
Provider-specific controls age badly
Security teams often start an AI policy with an allowlist of familiar domains. The Hermes configuration shows the maintenance problem. A workload can switch the hostname, API key, and model name while preserving the same operational intent. Provider acquisition, regional endpoints, compatible APIs, and self-hosted gateways add further destination churn.
An identity-aware rule describes the permitted relationship instead. The build agent may call an approved coding model through a named gateway route. The finance assistant may call a separate endpoint after prompt-level PII classification. An unknown service account running from a forgotten virtual machine gets denied when it opens a new model route, even when the destination belongs to an approved provider.
That policy needs destination context, but destination alone is too weak. The decision combines workload identity, human delegation where available, route, data classification, model authorization, and policy version. I would reject any design whose complete answer is a longer domain blocklist. Seven interchangeable backends can turn that list into stale paperwork before the next change window.
Per-decision records expose backend switching
A provider-agnostic gateway can write one record for each model request. The useful fields include the authenticated agent, delegated user, requested provider and model, route, classification result, policy version, decision, and timestamp. Those records show backend switching as a sequence instead of scattering the evidence across seven vendor consoles.
Write-path independence matters here. If the same agent that selected an exploit also controls its audit file, an operator can lose or alter the evidence with the same credentials. A decoupled enforcement point commits the record outside the calling process. The record remains useful when a Python server exposes the agent's own working directory or when the orchestration process crashes midway through a run.
This is an egress authorization control for HTTP AI traffic. Endpoint protection, vulnerability management, network segmentation, and service patching still handle the exploitation path described by Unit 42. The controls meet at incident reconstruction: the AI decision record identifies the model request, while network and host telemetry describe what the agent did afterward.
The control belongs at the AI request boundary
The earlier JadePuffer analysis focused on one agent carrying an autonomous attack chain. This incident adds a different detail: a commodity framework can rotate among seven reasoning services without changing the workflow. Our agentic AI news tracker provides the broader chronology, while the inline enforcement architecture explains why a decision made after the model call has forensic value but zero preventive value.
The practical control sequence authenticates the calling agent, resolves any delegated human identity, and classifies the request. It then evaluates the destination and model against a current policy before permitting or denying the outbound HTTP call and signing the decision record. Each step uses facts the enterprise owns.
DeepInspect
DeepInspect sits inline between authenticated users or agents and HTTP-based LLM APIs. It evaluates identity, role, data classification, route, model authorization, and organizational policy before forwarding a request. A change from DeepSeek to Qwen or Codex becomes another evaluated destination under the same policy plane.
Every permit, redact, and deny decision produces a tamper-evident record with the policy version and model destination. DeepInspect stays within the AI request boundary; it does not patch Citrix, Langflow, n8n, Marimo, Tomcat, or Windows VPN services.
Book a technical deep dive at deepinspect.ai.