Claude under attack: the infostealer case shows why AI agents should never have full access to our computer
Anthropic has started forcibly signing out some Claude users after spotting a new abuse pattern: criminal groups are using common "infostealer" malware to steal already authenticated Claude sessions and exploit the victims' accounts, burning through their usage quota.
In the cases it found, the company revoked the compromised sessions, removed saved payment methods and refunded the charges it identified as fraudulent usage.
The most interesting detail, from a security point of view, is that the attackers do not need to know the victim's password.
An infostealer copies cookies, tokens and other information sitting locally on the computer, then reuses a browser session that had already been authenticated. In this scenario even two factor authentication becomes useless: the criminal is not performing a fresh login, they are reusing a session that the service already treats as valid. The cases under analysis involve malware families such as Vidar, LummaC2, StealC, RedLine and Acreed on Windows, with Atomic Stealer on a small number of Macs.
Anthropic also clarified that it has no evidence the malware arrived through Claude. In the cases examined these appear to be ordinary infostealers that reached the computer through external software or downloads, so the Claude account would be just one of the many credentials harvested from an already compromised machine. One uncomfortable point remains: signing the user out stops the stolen sessions, but it does not remove the malware. If it stays on the machine, the next session will be stolen the same way.
The problem goes beyond Claude
The episode matters because it lands while we are handing AI models a growing amount of privilege over our computers.
A traditional chatbot takes text in and gives text back.
A coding agent like Claude Code is something substantially different.
It can read files, edit source code, run programs, install dependencies, use Git, query external services and, through tools and MCP servers, potentially reach databases, APIs, cloud platforms and other corporate systems.
The risk does not necessarily come from malicious behaviour by the model. It can come from a mistake, a compromised dependency, a malicious repository, a prompt injection hidden inside a file the agent reads, or one of the tools wired to the agent.
The more capability we grant the agent, the larger its blast radius becomes, meaning the set of systems that could be dragged in if something went wrong.
This is exactly the problem Anthropic itself is putting at the centre of a large part of its own security architecture for agents. In 2026 the company described containment as one of the core principles for limiting the blast radius of increasingly autonomous systems.
The underlying principle: the agent should not see our computer
The architectural rule should be very simple:
an AI agent should have access only to the resources it needs to complete the task we assigned it.
Not the other way around.
We should not run Claude Code on our main computer, give it access to the whole home directory, and then try to occasionally stop it from touching something.
We should build an environment where, by default, those resources simply do not exist from the agent's point of view.
It is the difference between security based on consent and security based on containment.
Anthropic observed internally a problem well known in cybersecurity: approval fatigue. If a system keeps asking the user "do you want to authorise this command?", sooner or later the user starts approving on autopilot.
According to figures the company published, users approved roughly 93% of authorisation prompts. Introducing sandboxing let it cut the number of prompts sharply while keeping a technical boundary around the agent.
In other words: it is better to technically stop an agent from reading an SSH key than to ask the user a hundred times whether they want to allow it.
The recommended architecture for Claude Code and other agents
A prudent architecture can be pictured like this:
INTERNET
│
▼
┌───────────────────┐
│ EGRESS PROXY │
│ domain allowlist │
│ logging / policy │
└─────────┬─────────┘
│
authorised traffic
│
▼
┌────────────────────────────────────────────────────┐
│ SANDBOX / VM / CONTAINER │
│ │
│ Claude Code / AI Agent │
│ │ │
│ ┌───────────────┼───────────────┐ │
│ ▼ ▼ ▼ │
│ /workspace local tools MCP Gateway │
│ READ/WRITE limited │ │
│ │ │
│ /reference ▼ │
│ READ ONLY allowed tools │
│ │
│ REAL HOME: NOT MOUNTED │
│ SSH KEYS: NOT PRESENT │
│ BROWSER COOKIES: NOT PRESENT │
│ PASSWORD MANAGER: NOT PRESENT │
│ CLOUD CREDENTIALS: NOT PRESENT │
│ HOST DOCKER SOCKET: NOT PRESENT │
└───────────────────────┬────────────────────────────┘
│
▼
CREDENTIAL BROKER
short, scoped tokens
│
┌──────────┴─────────┐
▼ ▼
Git Cloud/API
specific repo specific serviceThe core idea is that Claude Code lives inside the working environment, not inside our digital identity.
The repository it has to work on can be mounted for reading and writing. A folder with corporate documentation, if needed, can be mounted read only.
The rest of the filesystem simply should not be available.
Anthropic applies a similar principle to its own sandboxing: filesystem isolation and network isolation are both treated as necessary. The company stresses that protecting only the filesystem is not enough, and neither is protecting only the network.
Do not mount $HOME
This should become one of the easiest principles to remember.
A coding agent usually does not need our full home directory.
Inside $HOME you can find the .ssh folder, Git configuration, tokens, .env files, caches holding credentials, Kubernetes configuration, cloud credentials, shell history, local databases, password manager settings and plenty of other data that has no reason to be available to an agent tasked with fixing a bug in a repository.
The better approach is to create a temporary home inside the sandbox.
The agent sees that one.
It does not see the real one.
The network needs a sandbox too
Locking down the filesystem while leaving Internet access completely open solves only half the problem.
Suppose a repository contains a prompt injection.
The agent reads a file that looks harmless but carries an instruction crafted to convince it to look for credentials and send them to an external server.
If the agent can read those credentials and can connect freely to the Internet, the attack already has everything it needs. This is not just theory: Anthropic recounted that, after a phishing attempt, one of its employees gave Claude Code a plausible looking instruction to retrieve AWS credentials and send them to an external destination, and the agent carried out the exfiltration in 24 attempts out of 25.
This is why a stronger setup should use an egress proxy.
The agent, for example, should be able to reach only the services the project needs: the model provider, the authorised Git repository, the package registry used by the project and a few other explicitly approved APIs.
A request toward a brand new domain should instead be blocked, or require authorisation.
This is also the model Anthropic describes for the Claude Code sandbox, where network access can be restricted to the domains it may reach.
Credentials should not enter the sandbox
Here we can take one more step.
The agent often needs to authenticate to something.
That does not mean we should hand it our GitHub private key, a permanent AWS key or an SSH key.
Between the agent and the service we can place a credential broker.
The broker receives a request such as "I need to push to repository X, branch Y".
The system checks the policy and generates a temporary token that allows only that operation or that narrow set of operations.
The token can last a few minutes and not work on other repositories.
Anthropic uses a similar concept in the cloud architecture of Claude Code: the real Git credentials stay outside the sandbox, and a controlled proxy handles the authorised Git operations.
It is a very powerful principle: a secret that does not enter the agent's environment cannot be exfiltrated by the agent.
MCP should be treated as a privilege system
The Model Context Protocol makes agents far more useful, because it lets them connect to external tools and data sources.
But an MCP server should not be seen as a simple plugin.
From a security standpoint it is an extension of the agent's capabilities.
An MCP that can read the production database means the agent can read the production database.
An MCP with mailbox access means the agent can access the mailbox.
An MCP able to drive Kubernetes means we are widening the agent's blast radius all the way to the Kubernetes infrastructure.
Anthropic's documentation does recommend using MCP servers you own or from vendors you consider trustworthy, and reminds users that Anthropic does not automatically verify or audit the MCP servers they use.
For serious environments I would therefore introduce a central MCP Gateway.
The agent does not connect directly to dozens of services. It connects to the gateway, which enforces authentication, authorisation, logging and policy.
Some operations must stay human
The sandbox lets us give the agent much more autonomy over low risk operations.
It can edit a hundred files in the project, build the software, write tests, run linting and try different solutions without asking us for permission at every turn.
But some boundaries should be different.
A possible corporate policy could work on three levels. Automatic: reading and editing the workspace, tests, builds, linting, static analysis, creating branches and local commits. Explicit consent: reaching new domains, installing tools that were not planned, using new MCP servers, and reading data outside the project. Strong approval: access to secrets, writing to databases, merging into protected branches, changing infrastructure, deployments, privileged cloud operations and any action toward production systems.
The human, then, does not have to approve every npm test.
They have to approve the expansion of the trust perimeter.
The Docker socket is effectively host access
There is also one architectural mistake that is especially important to avoid.
Putting Claude Code inside a container and mounting /var/run/docker.sock from the host can undo much of the isolation.
A process that freely controls the host Docker daemon can often create new containers, with privileges or mounts that let it reach parts of the system we thought we had isolated.
This is why "I run it in Docker" does not automatically mean "I sandboxed it".
The security boundary has to include the privileged interfaces exposed to the container as well.
An ephemeral environment is even better
Ideally every meaningful task should be able to start from a clean environment.
Repository cloned.
Dependencies installed.
Agent started.
Task executed.
Patch or commit exported.
Sandbox destroyed.
This model reduces both the persistence of any compromise and the accidental buildup of credentials and data.
For particularly sensitive work an ephemeral VM can be preferable to a simple container, while for everyday development well configured OS level sandboxes or devcontainers can be enough. The Claude Code security documentation itself suggests devcontainers to increase isolation on sensitive repositories.
The model to adopt: Zero Trust for agents too
For years we have applied the Zero Trust principle to users: do not automatically trust someone just because they are inside the network.
With AI agents we can apply the same principle.
We should not ask "do I trust Claude?".
The right question is: what is the maximum possible damage if this specific agent session is completely compromised?
If the answer is "it can only edit a copy of the repository and talk to four authorised domains", we have built a reasonably contained system.
If instead the answer is "it can read my whole home, use my SSH keys, reach the cloud, query the Kubernetes cluster, read the browser cookies and talk to any server on the Internet", we are handing a single process an enormous blast radius.
And no "Allow?" popup can fully make up for an architectural choice like that.
The Anthropic case teaches us one more thing
Agent sandboxing does not solve the problem shown by the infostealers Anthropic found.
If the host computer is already compromised, malware can directly hunt for browser sessions, passwords, cookies and other credentials on the machine, regardless of Claude Code.
A sandbox mainly protects the host from the agent and from the code the agent runs.
To protect the agent and our identities from an already compromised host we also need other measures: an up to date operating system, software from trustworthy sources, endpoint protection, account separation, revocation of compromised sessions and credential rotation.
Security therefore has to work in both directions.
Secure host
│
▼
Secure sandbox
│
▼
Agent with minimal privileges
│
▼
Controlled tools/MCP
│
▼
Temporary credentials
│
▼
Authorised servicesThe AI workstation of the future looks more like cloud infrastructure than a terminal
The arrival of autonomous agents is reshaping our computer.
The terminal is no longer used only by a human typing one command at a time. It can now be driven by a system able to chain dozens or hundreds of operations, read thousands of files and make decisions on its own.
This is why the model "I install the agent on the laptop and grant it everything" is probably not the one to carry into the future.
The healthier model is the one long used in cloud infrastructure: isolation, least privilege, temporary credentials, network segmentation, logging, policy and ephemeral environments.
Claude Code and the other coding agents can be given a very high level of autonomy.
But that autonomy should exist inside a cage we built.
The more capable agents become, the less we should rely on the hope that they will not do something wrong, and the more we should design systems where, even if something goes wrong, the possible damage stays small.
It may be one of the most important rules of the new agentic security:
do not limit what the agent wants to do. Limit what the agent can physically reach.