After Claude Code Is Banned, Employees Paste Company Code onto Personal Computers

Amjad Masad said it plainly on Twitter: AI agents running on employee terminals are becoming a systemic security risk for enterprises and governments. Some institutions are starting to restrict Claude Code, and Goldman Sachs is reportedly among them. He retweeted a security advisory by Luis Héctor Chávez: original link, and the original tweet is here.

First, some background. The agent here is not a chat box in a web page; it runs on developer machines, has shell permissions, can read files, run commands, touch environment variables, and access external services over the network. It does work for people, and it also inherits their permissions. Enterprises used to draw boundaries by employee account; now there is an additional process that acts on its own.

Restricting Claude Code seems the most direct approach. The problem is in the replies: multiple people mentioned that a ban would push usage onto personal laptops. K4k0 said employees might paste company code onto personal computers and run it there, which is less secure. Somi also argued that blocking it mainly just moves the agent onto personal devices. Jacob Ho offered another approach: give coding agents dedicated VMs, short-lived tokens, and no production SSH access. He said the incident rate dropped more noticeably than with any ban.

The more painful pitfall is credentials. Tayo Stack said many teams lock down the sandbox tightly, then turn around and stuff API keys into the agent's environment file. Jess followed up that even managed cloud environments do not stop an agent from reading secrets mounted into them. Luis Héctor Chávez replied that you should not give agents direct credentials; route all egress requests through a proxy, and let the proxy enforce the organization's policies for network access and third-party connectors.

There is a more hidden layer: shared state. John Rood said terminal risk is visible; memory risk is not. Once multiple agents share storage, an agent on a compromised laptop can read what decisions other agents made last month, including content it was not supposed to see. This boundary should be drawn by caller, not by workspace. ReignSwords added that short-lived tokens and dedicated VMs solve the credentials half, but contaminated shared memory is harder to handle; one agent's incident will drag down other agents.

Management controls do exist. Mehdi Mohseni mentioned Claude Code's allowManagedPermissionRulesOnly, which can make IT's managed settings the sole source of permission rules. shallma listed a set of more practical actions: sandboxed dev containers, narrowing tokens per task, denying egress by default, and logging every tool call. Jatin Garg asked an organizational question: when cloud agents act with employee permissions, who owns incident response?

There are also two self-deprecating lines in the replies. Hongji Lee said the biggest security risk on his laptop is that he clicks allow without reading the prompt every time. Prolific's reply cuts deeper: enterprise security teams banned coding agents, yet the same team has 40 interns holding production credentials and a shared password document.

Someone posted a video joking that now even coffee machines have to submit security reports.

The security advisory's direction is already clear: isolated environments, proxied egress, short-lived credentials, full auditing, and shared-state isolation by caller. Banning tools is the least effort and looks the most like control. The actual effect may be to move risk somewhere invisible. What security teams need to guard against may be a process that holds keys, can read shared memory, and does not even have to attend onboarding. The tool name is just the jacket it is wearing today.