CISO Intelligence: The Middleman Has Always Been the Attack
Two stories landed within a day of each other and they share a shape. In the first, a fake Web3 accelerator ran a months-long recruitment operation and shipped backdoored npm packages to the founders it had been courting. In the second, OpenCode confirmed that an intruder had used a large-scale distillation campaign to reach the AI provider keys held in its hosted Console, and that some users woke up to unauthorised bills.
Different actors, different victims, one structural point. In both cases the attack was not against a model or a network edge. It was against the layer that sits between a person and a model: the agent they installed, the console that held their credentials, the vendor they trusted to run inference on their behalf. That layer is young, it is where the money is, and almost nobody is watching it.
Apex: a fake accelerator that audited nothing
Elastic Security Labs traced the operation from a single npm package, @apexacc/cli, flagged by their supply-chain monitor. Behind it was a supposed Web3 venture accelerator called Apex, running a private workspace called Apex Arena, claiming more than 200 portfolio projects and 124 million dollars raised. The pitch to crypto founders was free Anthropic Claude and Google Gemini credits, coding tools, and a free security audit.
The audits were fake. All eighteen tools in the @apexacc/audit MCP server return generated findings: some hard-coded, some formatted from the input, some randomised. Separately, the scoring service behind @apexacc/cli returned 51 out of 100 for a fictitious project while its own message said the AI scorer was unavailable. Companies may well have taken those reports to their boards.
The code was real. Apex Copilot is a repackage of the legitimate open-source coding agent Oh My Pi: 1,351 of 1,363 files matched exactly. The additions are the problem. On Windows the packages fetch a command from an attacker server and run it through PowerShell with the execution policy bypassed; the audit variant asks for elevation and tries to add its own directory to the Defender exclusion list. On macOS a small Rust helper fetches a bash script that drops a known Mach-O backdoor, CloudSyncD. The agent's OpenRouter traffic is redirected to an attacker endpoint, and an attacker-controlled MCP server is registered in the user's configuration. The MCP server can supply tool names, descriptions and instructions. The endpoint sees prompts, conversation history, code and tool output.
Two details deserve attention. First, tool approvals in that agent default to yolo mode, so a substituted model response can drive local read, write and execution tools. Elastic captured a local file being read on instruction and its contents appearing in a later request to the attacker's endpoint. Second, the operation manufactured legitimacy the old-fashioned way: fake reviews, an event listing on a well-known platform, an appearance at TOKEN2049 in Singapore. The polish was not the tell. The tell was a security vendor that would audit you for free.
OpenCode: the keys you lend out
OpenCode disclosed that a breach affecting 1.4 per cent of Console users exposed provider API keys for Anthropic, OpenAI and Google. Exposure began no earlier than 00:30 UTC on 17 October. Users reported unauthorised charges from a few hundred dollars to more than 1,700 dollars within hours, and at least one Google Cloud project was suspended for activity consistent with hijacked resources. The maintainers describe it as a large-scale distillation attack, and say the attackers had been working their systems with AI agents for at least 48 hours. One detail worth noting for anyone who thinks guardrails are optional: the investigation was reportedly held up when the models OpenCode was using declined the requests.
Whether or not you use OpenCode Console, the class of exposure is yours. Linked provider credentials sit on developer machines, in OpenCode's case at ~/.local/share/opencode/auth.json, and more often than not in a console at a third party. The test is not "did we have a breach". The test is whether you can list every place a provider key is stored on your behalf, what scope it carries, and what would make you notice someone else spending it. Most organisations fail all three questions.
Siemens: when the signed binary is the disguise
Siemens confirmed exploitation in the wild of CVE-2026-110936, a DLL sideloading flaw in Siemens Software Center affecting all versions before 4.0.9.8. CVSS v3.1 scores it 6.7; CVSS v4.0 scores it 8.4. The flaw loads libraries from an uncontrolled search path, and attackers bundled a genuine, signed copy of Software Center with malicious DLLs and pushed it through ClickFix lures.
The attack is linked to the Romulus ClickFix campaign, with Forescout finding the distribution server among Romulus infrastructure. Siemens states plainly that no Siemens system or update channel was breached: attackers chose its program as a carrier because it is signed and trusted. That is the hard part for detection. Blocklists and signature checks will pass the host process. Hunters should look for SiemensSoftwareCenter.exe running from AppData\Local\Programs after an msiexec launch, and for the infrastructure Siemens has published. Patching is straightforward; knowing what ran before you patched is not.
A useful counter-example: Cloudflare Clairic
Not every story was a warning. Cloudflare previewed Clairic, an extraction model that sits on Workers AI as @cf/cloudflare/clairic. It returns typed values from text and up to four images in one pass, without generating tokens, and every scalar answer carries a confidence score and a p_null probability that the value is missing. Extracted text comes back with character offsets, so a human reviewing an invoice can see exactly where a number came from. In Cloudflare's claims test the cascade ran at 19.3 seconds against 61.7 for the all-LLM version, at 6,032 dollars per million claims against 11,740.
The reason to care is not the price. It is the shape. A narrow model that returns typed values with a confidence score, a null when the value is absent, and a pointer to the source is auditable. It fails in a way a reviewer can check. An LLM asked to read an invoice and return JSON fails by writing a plausible digit. If you are building any workflow where an AI output becomes an action, that difference is the whole argument.
What this means for you
1. Treat AI coding agents and MCP servers as software you must inventory and approve. Check developer machines for OpenCode, for Apex packages, and for agent configuration files that list MCP servers nobody remembers adding. An agent that defaults to yolo approvals is a remote code execution channel with a friendly interface.
2. Rotate provider keys held in any hosted console, then shorten their lifetime, and turn on spend alerting. Then answer the harder question: which of your tools hold keys on your behalf, and who would notice misuse before the invoice arrived.
3. Audit your AI vendors the way you would audit a supplier, and be suspicious of free ones. Ask what the evidence behind a report is, who produced it, and whether the tool could generate it without running anything. If nobody can answer, the report is decoration.
4. If Siemens Software Center is in your estate, patch to 4.0.9.8 or later, then hunt. Preserve what you can before you update. The signed binary being genuine is precisely why the usual checks will not find the malware.
5. Prefer systems that fail visibly. Confidence scores, null returns, source offsets and logs you control are what separate a tool you can govern from a tool that merely reassures you.
The common thread is not that AI is dangerous. It is that the trust boundary now runs through tools that security teams did not select, cannot list, and rarely read the configuration of. Closing that gap is unglamorous work: inventory, credential hygiene, approval policy, evidence trails. It is also the only work that would have helped.
,-
Sources: 21 publications checked, 15 AI-relevant stories analysed over a 24-hour window.