Citizen developer governance after Goldman pulled Claude Code

Citizen developer governance stopped being a slide in a Centre of Excellence deck on 2 November 2026, when Bloomberg reported that Goldman Sachs had cut most of its traders and bankers off from Claude Code and GitHub, months after its CIO praised the tools they were building. If you are deciding whether business staff should build with AI coding agents or whether you fund engineering instead, this post gives you a working model: who may build, where it runs, and who owns the tool once it touches client data.

The short version: Goldman did not ban AI, and it did not say it banned citizen developers. It moved one class of tool to the people who already own production code. For a company of 50 to 500 people, the useful lesson is the handover, not the ban.

What Goldman Sachs actually restricted in October 2026

The facts below come from the Bloomberg News report by Todd Gillespie, syndicated by Financial Advisor on 2 November 2026, and from The State of AI's summary of the same reporting.

• What changed: internal guidance "updated in October" limits Anthropic's Claude Code and Microsoft's GitHub to engineers. Most traders and bankers lost access.
• Who kept it: the directive does not apply to "strats", the group that spans trading, quantitative research and software engineering.
• What traders used it for: monitoring client trading flows, modelling market changes and positions, and producing written and graphic content. Some were frustrated by the change.
• What came before: as recently as July, CIO Marco Argenti touted "vibe coding" by non-technical employees, who passed their creations to one of the firm's 12,000 engineers to improve.
• What remains: Goldman has built its own AI assistant that combines models from OpenAI, Anthropic and Alphabet.

One detail is looser than most retellings make it. The Bloomberg text names "Microsoft Corp.'s GitHub", not a specific product. Coverage that says Goldman pulled "GitHub Copilot agents" is filling in a product name the report does not give.

Why did Goldman Sachs restrict Claude Code? One reason is on the record

Three explanations circulate, and only one comes from Goldman. If you are going to cite this decision in your own policy discussion, keep them apart.

Explanation	Who says it	Status
A review of "productivity and risk concerns"	Bloomberg, describing the internal guidance	Reported, not a Goldman quote
"We make certain AI tools available to our people to determine the best use cases across different parts of the firm."	Nick Carcaterra, Goldman spokesperson	On the record
Agent-written code on a trading floor creates information-barrier risk	The State of AI	The publication's analysis
Expensive models used for simple jobs	Bloomberg, about JPMorgan asking staff to match models to tasks	Industry context, not Goldman's reason

The spokesperson's line describes a pilot that ended: test the tools, then give them to the people best placed to use them long term. That framing matters more than the risk speculation, because it is a decision about who builds, which is exactly the decision you face.

The strongest case for letting business staff build

The counter-argument deserves its full weight. The traders were not toying with the tools. Monitoring client flows and modelling positions is core work, and the person closest to the problem often writes a better first specification than an engineer who hears about it second-hand. The State of AI argues that withdrawing access through a guideline update, with no replacement, treats the people who found good uses as the problem, and that their needs persist after the tool goes.

Practitioners on Hacker News split the same way. A minority argued the answer is better platforms and guardrails rather than restriction. The more common reply was older than AI: one commenter wrote, "We had this happen with end user scripting pre AI where these scripts became unknown production applications."

Both sides are right about different moments. Letting a trader build a prototype is cheap. Letting that prototype become the thing a desk depends on, with nobody accountable for it, is where the cost lands.

What AI coding agents for non-engineers add to the old shadow IT problem

The security community has already redrawn the map. The OWASP Citizen Development Top 10 began as a low-code/no-code list and broadened its scope to cover "Low Code No Code, AI assisted coding, and AI agent technologies". Three of its ten risks describe the Goldman situation closely.

• CD-SEC-01 Blind Trust: OWASP names automation bias, where citizen developers treat generated code and pre-built components as safe because they are readily available.
• CD-SEC-04 Sensitive Data Leakage and Handling Failures: one scenario has a product manager paste raw support logs, with customer account IDs, into an AI assistant whose script then posts summaries to a public channel.
• CD-SEC-09 Asset Management Failures: easy creation leads to "ungoverned, unpatched, and ultimately orphaned solutions", including a workflow built with AI-assisted coding and deployed as shadow IT without a security review.

The difference an agent makes is scale and plausibility. A spreadsheet macro looked like a spreadsheet macro. An agent produces a web app with authentication, a database and a deploy script, so the tool looks finished long before anyone has reviewed it. We covered how that debt shows up later in AI generated code technical debt.

A citizen developer governance model in three tiers

A workable citizen developer governance model sorts every tool by what data it touches and who depends on it, not by the builder's job title. This is the model we recommend for a 50-500 person company; the controls are borrowed from Microsoft's and OWASP's published guidance, cited below.

Tier	Who may build	Where it runs	Data allowed	Who owns it
1. Personal	Any trained employee	Own workspace, agent under managed settings	Own, public or synthetic data	The builder
2. Team tool	Registered builder	Shared sandbox, separate from production	Internal data, no client records	Builder plus a named engineering sponsor
3. Production	Engineering	Your normal pipeline and SDLC	Classified data, including client data	An engineering team

The tiers mirror how Microsoft runs its own low-code platform. Its Power Platform environment strategy routes makers out of the shared default environment into personal developer environments, calls it a key tenet to "isolate where an asset is built from where it's deployed and used", and suggests a sharing limit for personal-productivity tools: "A common limit is between 5 and 50 users." If you already pay for that platform, the Power Apps Premium price increase changes what tier 2 costs you.

Data classification decides the tier

The moment a tool reads client data, writes to a system of record, or passes its sharing cap, it leaves tier 2. That single rule would have covered the Goldman traders monitoring client flows. OWASP's prevention list for data leakage says the same in control language: "Limit connectors to an approved services list" and involve security teams in reviews of applications with access to sensitive data.

Enforce it in the tool, not the handbook

A policy PDF does not stop an agent from reading a credentials file. With Claude Code, an organisation can deploy managed settings, and the Claude Code settings documentation states that "Nothing in your own settings files or --settings overrides a managed key". That is where tier 1's permission and deny rules belong.

Who owns apps built by citizen developers?

The builder owns a tier 1 tool, and an engineering team owns anything in tier 3; tier 2 is where ownership has to be written down. OWASP's fix for orphaned solutions is a list: enforce application ownership and lifecycle, implement tiered risk classification, mandate version control, and keep an inventory of applications, components and users. The State of AI puts it more bluntly: name an accountable engineer before an agent-built tool touches production data.

Goldman had a handover pipe: traders built, and one of 12,000 engineers improved the result. A company of 200 people does not have spare engineers waiting for prototypes. If nobody has capacity to receive a handover, your tier 2 fills with tools that can never move up, which is the orphan problem with extra steps.

Handover from citizen developer to engineering is where the cost sits

Treat the citizen-built prototype as a specification, not a codebase. It proves the workflow is worth having and shows which screens people use. What it rarely has are the parts that make software safe to depend on: named owners, role-based access and a history of who changed what.

We saw that gap directly on a workflow management build. The client's work had been started through email threads and shared spreadsheets, with no audit trail and no single place to see who owned a task. The product we delivered was not more features than those spreadsheets; it was structure: role-based access, workflows with a responsible owner per step, and a full task audit trail. That is the engineering a handover buys, and it is why the rebuild is usually a project rather than a code review.

Budget for it as a project. If the tool is replacing software you might otherwise license, the trade-offs in build vs buy enterprise software apply before you write anything.

When a ban is the right call

Restricting coding agents to engineers, as Goldman did, is the right choice if any of these hold:

• Your staff work across information barriers or with regulated client data, and you cannot enforce data classification at the tool level.
• You have no engineering capacity to receive handovers, so every useful tool will stall in tier 2.
• You cannot deploy managed settings or an equivalent control, so tier 1 exists only on paper.

It is the wrong choice if you remove access without recording what people were building. Those tools were requirements. Goldman's own spokesperson described the exercise as finding "the best use cases"; the output of that exercise is a backlog, not a blocklist.

Fund engineering or let the business build: deciding the next step

Start by listing the agent-built tools already in use and placing each one in a tier. Anything that reads client data or that a team would miss tomorrow is a tier 3 candidate, and the question is who builds it properly. If your engineering team cannot absorb that list, our custom software development team can take the prototypes your staff have proven, rebuild the ones that earn it with ownership, access control and audit trails, and hand them back to someone accountable.