Researchers at Cambridge-based Darktrace have shown that a developer’s own Claude Code agent can be run as a remote implant once an attacker has the developer’s Claude Console credentials. The work is a lab demonstration rather than a flaw in Claude, and it has not been seen in the wild. Even so, it makes allow-listed AI traffic a place attackers can hide.
What happened
On 12 November 2026, Moishe Tajtelbaum and Sam Lister of Darktrace Signal Labs released “Living off the AI: Shared Memories as a Covert C2 Channel”. They showed that an attacker who already has a foothold on a developer workstation, and has stolen that developer’s Claude Console credentials, can direct the locally installed Claude Code agent from outside the network. Instructions arrive and results leave through Claude’s memory stores feature, and stolen data is uploaded through Anthropic’s Files API.
Three caveats matter. Darktrace says no Claude vulnerability is involved, the work ran only in its own test lab with fictitious identities, and it has no evidence of real-world use. Speaking to Help Net Security, Tim Bazalgette, Darktrace’s Chief AI Officer, said the company told Anthropic about the work before publishing as a courtesy, with no formal disclosure because there was nothing to disclose. As Bromure notes, nothing is due to be patched, because every component is a documented feature behaving as designed. That is why it deserves attention: the attacker brings no new tooling, and instead borrows a trusted developer tool that already has the user’s privileges.
The technical picture
Memory stores are workspace-scoped collections of text files that persist between sessions. They are built so that agents on Anthropic’s Claude Managed Agents service can keep context over time. Darktrace found that anyone holding a standard API key can create one in a Console workspace through the REST API, even if the organisation has never used Managed Agents. According to Bazalgette, OAuth credentials could not reach memory stores in the same way.
In the simulation, the operator created a store holding three files: a heartbeat, an input queue of jobs and an output file for results. A first-stage payload on a Linux host located the Claude Code installation and harvested the user’s credentials. It then set up a transient systemd service that kept relaunching Claude Code non-interactively. Bromure and the CSA say it then removed itself. Help Net Security reports that the processes ran with permission prompts disabled, meaning nobody signed off individual actions, a mode Anthropic’s documentation reserves for isolated sandboxes, as the Cloud Security Alliance points out.
From then on, each agent run checked in, picked up a plain-English job and completed it with shell tool calls. Over nine jobs, the agent:
- mapped nearby hosts and services
- retrieved staff names and a stray password left on an FTP server open to anonymous logins
- built a list of 190 possible account names
- password-sprayed a domain controller until one account worked
- listed SMB shares and downloaded a 1 GB file
- uploaded that file in three parts to the Files API.
Every exchange ran over api.anthropic.com, which the agent uses anyway, so after the first stage the victim never touched attacker infrastructure.
There is precedent: the Cloud Security Alliance cites Microsoft’s SesameOp research, where a backdoor treated the OpenAI Assistants API as a dead drop. Here the agent itself does the work, leaving no custom implant to catch.
Why it matters for UK organisations
AI coding assistants are now ordinary kit in UK development teams, from consultancies to the engineering functions of banks and public bodies, and each deployment means the vendor’s API host sits on an egress allow list. Blocking by destination cannot separate a developer’s legitimate session from an operator’s tasking when both go to the same hostname with valid credentials.
It also changes how we should rank AI platform keys. Many organisations still treat them as a billing risk, something to rotate if a surprise invoice arrives. In this scenario, a stolen key hands over tasking, storage and a willing worker with a developer’s network reach. Bazalgette’s advice is to protect such a key as carefully as a production credential, and I agree. Under UK GDPR, losing personal data through that route is still a reportable breach, whichever hostname the data left by.
Developer endpoints are often a weak point, with local admin rights, broad network access, long-lived tokens and relaxed endpoint controls. Add an autonomous agent with prompts switched off and a modest compromise becomes an insider-grade foothold.
Expert view
I would not overstate this. The attacker needs code execution and the developer’s credentials first, and by then you already have a serious incident. What the research changes is what comes next. In my experience, the moment an intruder has to stand up command and control is one of the best chances defenders get. A beacon to a fresh domain, an unusual TLS fingerprint or a strange binary is often what gives them away. This technique removes that moment. The process is signed and approved, its parent is a coding agent that routinely spawns shells, and the destination is sanctioned.
The plain-English tasking matters too. Darktrace’s operator still gave fairly specific instructions, so this is not agents hacking alone, but with no bespoke implant to write, the bar for whoever sits at the other end drops.
The fair criticism of the platforms is about visibility, not vulnerability. Bazalgette noted that it matters whether customers can see writes to the stores at all. When we test, the first thing I want to know is whether the client can list every memory store, file and key in their AI workspaces, and who created each one. Few can answer that today.
What to do now
- Audit your AI workspaces. List every memory store, uploaded file and API key in your Claude Console workspaces, and in equivalent platforms. Investigate anything nobody can account for.
- Move developers off long-lived keys. Use OAuth or identity federation where the platform supports it. Otherwise, issue keys that expire quickly and only cover one workspace. This maps to Cyber Essentials user access control.
- Get keys out of plain sight. Remove credentials from shell history, dotfiles and environment variables. Treat the agent’s local credential file as a secret that infostealers will target.
- Keep the guardrails on. Ban permission-bypass modes on workstations and allow them only in isolated, disposable containers or virtual machines. This falls under the secure configuration control.
- Baseline agent behaviour. Use EDR to correlate agent processes with their child processes, command lines and upload volumes. A coding agent running nmap, smbclient or password-spraying scripts, or sending far more data to the API than inference needs, should raise an alert.
- Harden developer endpoints. Remove standing admin rights, segment build hosts from domain controllers and file shares, and do not relax anti-malware controls for engineers.
Bottom line
Darktrace has not found a bug in Claude, and nobody has been caught using this in the wild. What the research shows is that AI coding agents, once trusted and allow-listed, are ready-made insiders for anyone holding the right key. UK organisations should treat AI platform credentials as production secrets, keep agent guardrails switched on and watch what their agents do, not just where they connect.
