Goldman Sachs Claude Code Ban: What It Means
Goldman Sachs has limited Claude Code to engineers. See why the bank changed course, what risks it is managing and how firms can govern AI coding agents.
Goldman Sachs Pulls Claude Code From Traders: The Risk Behind the Decision
Goldman Sachs has narrowed access to AI coding tools used by its traders and bankers. Bloomberg reports that updated internal guidance from October restricts Anthropic's Claude Code and Microsoft's GitHub to engineers. Some staff known as strats - who work across trading, quantitative research and software engineering - keep access.
The change matters because the tools weren't just for experiments. Traders and bankers had reportedly built tools to monitor client flows, model market moves and positions, and produce written and visual material. In July, Goldman's chief information officer, Marco Argenti, praised employee-led "vibe coding," describing how staff could create an initial version and hand it to engineers for improvement.
The shift highlights a real tension in enterprise AI: people close to a problem can often prototype fast, but speed doesn't remove the need for software review, data controls, and clear ownership. A coding agent can generate and run code using the user's permissions, including access to sensitive information. This article looks at why Goldman tightened access, what risks the policy is trying to address, and how financial firms can keep experimentation useful without letting unreviewed code drift into consequential workflows.
Why did Goldman Sachs restrict Claude Code?
Goldman's reported policy is role-based: third-party coding agents are limited to certain employee groups. The tools can read files, write code, and run it. Goldman's own internal AI assistant - built on models from multiple providers - remains available across the firm. In other words, this isn't a total ban on AI. It's a decision about who can use tools that execute code, and what controls apply.
Bloomberg reports that Goldman reviewed productivity and risk concerns before updating its guidance. The change reportedly frustrated some traders who had found the tools practical. Their uses included tracking client trading flows, building models of market moves and positions, and assembling recurring written or graphic material.
It also flips the tone from Argenti's comments in July. Back then, he spoke positively about non-technical employees building early versions and handing them to engineers to refine. That workflow can cut down the time needed for engineering capacity - especially when a trader understands a recurring desk problem and can show what a tool should do before developers turn it into something production-ready.
The weak point is the handoff. A prototype can end up in daily work before it gets reviewed, or it might never reach engineering at all. And if the person who built it is the only one who really understands what it's for, it can become an informal dependency with no clear owner.
Goldman has also made access decisions for reasons separate from the October role-based restriction. In April, it removed Claude from its internal AI platform for bankers in Hong Kong. The Financial Times reported that the bank interpreted its contract with Anthropic narrowly; Anthropic said Claude wasn't officially supported in Hong Kong. The October update, by contrast, focuses on employee roles and what coding agents can do.
There's also the broader context of Goldman's work with Anthropic. Earlier reporting says Anthropic engineers spent six months at the bank helping build Claude-based agents for trade accounting and client onboarding. Those tools run through Goldman's engineering teams. Goldman and Morgan Stanley were also listed as lead underwriters in Anthropic's S-1 filing, according to the source report. The relationship is a reminder that access policy is a governance choice, not simply a question of whether a model provider is "trusted."
Why are AI coding agents risky on a trading desk?
The concern isn't that AI will "make mistakes" in some abstract way. People write buggy software all the time, too. The specific risk is that a coding agent can generate and execute code in the user's environment - often with the permissions that user already has. If code gets built and used informally, it can slip past the safeguards that normally apply before software becomes part of a critical workflow.
Code can move from prototype to daily workflow
In a standard engineering path, code usually goes through review, testing, approvals, and controlled deployment before it touches critical systems. A trader's spreadsheet or script may start as a personal helper and then become something a wider team leans on. That shift can happen without anyone making a formal decision to treat the code as operational software.
Once that happens, the failures aren't just technical. A model may handle unusual market conditions badly, rely on outdated input, or calculate positions incorrectly. If staff use the outputs to make decisions, edge cases can turn into real financial consequences. The risk grows when users can't inspect what the generated code is actually doing - or explain how it behaves outside the narrow examples they tested.
Existing information barriers still apply
Banks use information barriers to keep sensitive material from moving between groups in ways that could create conflicts. For example, bankers working on a deal may see information that traders shouldn't. Bloomberg's source report says Goldman's internal AI platform was built with controls like these.
A tool built ad hoc with an agent may not include those same restrictions. It might read files, combine data, or produce outputs its creator didn't anticipate. If an engineering team doesn't even know a tool exists, it can't review it. And access controls get harder to enforce when employees create their own software outside established development processes.
The user's permissions shape the exposure
A coding agent doesn't need special privileges to create problems. If it runs using the user's access, instruction or code errors can expose information the user is allowed to see - or operate on data within their environment.
So the question isn't only whether the model is "safe." It's what data the user can access, what actions the agent can take, and how those actions are logged and monitored.
There's also a human factors angle. If engineers can ship code they don't fully understand (a concern Meta engineer reportedly raised last month), then a non-engineer using generated code to model positions may be even less able to spot subtle failures. The goal isn't to assume every AI-generated script is automatically dangerous. It's to keep unreviewed code from quietly gaining the authority and reliance that production systems require.
What does the restriction mean for Goldman's AI strategy?
The decision suggests Goldman is drawing a line between broad access to AI assistance and access to coding tools that can run autonomously. Employees can still use the bank's internal AI assistant, while third-party agents that write and run code are limited to engineers and certain technical roles. That's more precise than banning AI outright - but it raises a practical question: if someone has a useful idea, how does it get built into something that's properly supported?
Argenti's July description pointed to one approach. Let the person closest to the problem draft a rough version, then have an engineer improve it. That can work when the prototype is isolated, uses approved data, and can't affect consequential decisions. It's much less safe if the prototype can access sensitive information or becomes part of a desk's day-to-day workflow before review.
A restriction can reduce risk - and it can also remove a route for surfacing genuine needs. Traders who built tools were showing what was missing: monitoring client flows, modeling market scenarios, and preparing recurring analysis. If access disappears without a replacement path, those needs don't vanish. They just shift into manual work, unofficial scripts, or longer waits for engineering support.
The better response is to capture the demand without assuming every prototype should come back. A bank can ask employees to document the problem, the data required, and what decisions the tool would support. Then engineering can decide whether the task becomes a governed internal product, an approved workflow, or something that shouldn't be automated.
Costs also play a role. Coding agents are often priced by usage, and wide access can make spending harder to predict. Bloomberg's source report notes that other organizations have dealt with wasteful agent use and adjusted how they fund access. Cost alone may not justify blocking a useful tool, but it is a reason to measure actual usage rather than assume access is "free."
Barclays is a useful contrast, though it's not a like-for-like comparison. In October, it said it expected half its developers to use Claude Code by year-end, and later it listed developers among thousands of planned job cuts. Both banks are putting coding agents in engineers' hands, but their business goals and workforce decisions aren't identical. Adoption numbers don't automatically tell you whether a firm is improving quality, shortening cycle times, or simply shifting how it staffs work.
For Goldman, the real test is whether the new boundary keeps the benefits of employee-led problem discovery while putting accountable engineers in charge of code that touches important workflows. A policy can be cautious and still be incomplete if it removes tools without explaining how the underlying work will be supported going forward.
How should financial firms govern AI coding agents?
The practical rule is simple: an agent can help create code, but a named owner has to be accountable before that code touches production data or influences a consequential decision. The owner may be an engineer - but accountability has to be clear, and the review has to match the risk of the workflow.
Separate exploration from operational use
Experimentation doesn't mean every prototype gets access to live workflows. Firms can set up a low-risk sandbox using synthetic, anonymized, or otherwise approved data and limited permissions. Prototypes that stay in that environment can be evaluated for usefulness without gaining access to client records or trading systems.
A tool should leave the sandbox only after it has an owner and a clear purpose. That's when normal software controls should kick in: review, testing, approval, deployment, and monitoring. Generated code shouldn't get a lighter process just because the task was described in natural language instead of written line-by-line.
Apply controls to the capability, not just the vendor
Rules should distinguish between an AI assistant that summarizes approved material and an agent that can read files, execute code, or take actions. The provider matters, but permissions and workflow matter at least as much.
A useful review starts with questions like:
- What information can the agent access?
- Can it write or execute code, and where?
- Can its outputs affect client, trading, or regulatory decisions?
- Who reviews the result, and who owns failures?
- How are use, cost, and access changes recorded?
The answers should determine who can use the tool and under what conditions. That avoids two extremes: treating all AI tools as equally risky, or assuming that a familiar vendor makes an autonomous agent safe by default.
Keep information barriers and data entitlements intact
Agent-generated code has to follow the same information barriers and data entitlements as other software. If an employee can't access a particular dataset under existing policy, an agent operating in that employee's environment shouldn't become an indirect way to reach it. Controls need to be enforced by the systems the agent uses - not left up to the user to remember in a prompt.
This matters even more in regulated settings, where a prototype can still create unacceptable information flows. The review shouldn't be just "does it work?" It should also cover what it read, what it produced, and who is allowed to see the outputs.
Record the use case when access changes
When a company restricts an agent, it should document what employees were using it for and what work will replace it. In Goldman's reported case, the uses included client-flow monitoring and position modeling. Those tasks still need to be done after access changes.
A simple intake process can turn a restriction into a product backlog rather than a dead end. Have users describe the task, how often it happens, what data it involves, what the current workaround is, and what goes wrong if it fails. Engineering and risk teams can use that to prioritize the safest, most valuable work.
Key takeaways
- Keep prototypes separate from production data and decisions.
- Assign a named owner before code enters an operational workflow.
- Apply existing review, information-barrier, and data-access rules to AI-generated code.
- Restrict agents based on their capabilities and permissions, not just their brand.
- When access is withdrawn, keep evidence of the use case and define a replacement path.
Conclusion
Goldman's decision draws a line that matters: letting employees experiment with AI isn't the same as letting unreviewed code become part of a trading workflow. A coding agent can speed up prototyping, but it can also operate with access and influence that outlast the experiment. In a bank, information barriers, software review, and clear ownership aren't "nice to have" - they're basic operational requirements.
Restricting access may be a sensible control. Just as important, the policy should preserve what the experiments revealed: which tasks are slow, what employees need tools to handle, and where engineering capacity would help most. Firms rolling out coding agents should define ownership before launch, keep prototypes away from production data, and include a path for useful work to continue whenever access gets tightened.