Goldman’s AI Restrictions: The Enterprise Lesson

A business user asks AI to build a small tool. It works. A colleague starts using it. Soon, a team depends on it.

At what point did an experiment become a system the company must maintain, secure and stand behind?

That is the question I kept returning to after reading State of AI’s report on Goldman Sachs restricting AI coding tools. It matters far beyond banking. As the founder of Kognosys, building SenangAI, I see it as a useful challenge to anyone promising to make enterprise AI easier.

Making a tool easier to create also makes it easier to create obligations nobody has agreed to own.

Quick answers

• What was reported? Bloomberg reported that October guidance narrowed access to Claude Code and GitHub to engineers after a review of productivity and risk.
• Does this establish a general rejection of AI? No. The reporting concerns particular tools and access arrangements.
• What is my interpretation? Companies need an explicit path from individual experimentation to dependable organisational use.
• What does this mean for SenangAI? We need to make evidence, authority, ownership and recovery practical parts of the experience. Those are design commitments to test, not benefits to assume.

What the reporting establishes—and what it does not

Bloomberg’s publicly accessible excerpt, published on 2 November 2026, confirms that its reporters saw updated internal guidance. It also describes frustrated traders who had used the tools in their work. The full article is subscription-restricted.

State of AI adds that quantitative specialists known as “strats” retained access and that Goldman’s internal AI assistant remained available. It distinguishes the role-based change from earlier location-related restrictions in Hong Kong.

These reports do not give us Goldman’s full risk assessment, measured return on investment, or complete replacement arrangements. I would not infer a specific data breach, financial loss or failed model from the access change.

The corporate reasoning below is my analysis of the decision such an organisation faces, rather than a claim to know Goldman’s internal deliberations.

The employee and the company are measuring different things

For an employee, a tool that saves two hours can be an obvious success. For the company, those two hours sit inside a larger calculation.

Who checks the result? Who investigates when a source changes? Who supports colleagues using a copied version? Who retires the tool when its creator moves to another job?

The CFO may ask whether time saved becomes additional capacity or merely more output to review. The security team may ask which systems the tool can reach. Operations may ask whether it fails visibly. A business leader may ask whether its assumptions remain valid under unusual conditions.

These are different responsibilities, and all can be reasonable.

My proposed measure of value is therefore the improvement in an accepted business outcome after including verification, maintenance, operating cost and failures. Faster generation is useful evidence, but it is only one part of that measure.

A company can rationally restrict an individually useful tool when the surrounding support model is incomplete. It can also make a poor decision by restricting access without preserving the useful work employees discovered.

A job title is a starting filter, not a complete control

Restricting powerful tools to engineers is administratively simple. It creates a more manageable group to train, support and supervise.

However, engineering expertise alone does not establish business correctness. A technically competent person can implement the wrong definition of revenue, misunderstand a customer exception, or automate an outdated process perfectly.

Equally, a business specialist may understand a decision deeply while needing help with software testing and security.

I would divide responsibility across three questions: who understands the business meaning, who validates the implementation, and who authorises operational use? One person may cover several roles, but those responsibilities should be explicit.

This also changes the access question. Instead of deciding only which people receive a tool, decide which combinations of person, task, data and action are permitted.

An analyst exploring synthetic data, an assistant reading approved records and an agent updating customer commitments present different operating risks, even if they use the same underlying model.

Useful autonomy requires enforceable boundaries

It would be unfair to describe coding agents as having no safeguards. Anthropic’s documentation describes configurable permissions, organisational controls and filesystem and network isolation. It also places responsibility on users to review proposed code and commands.

The enterprise question is whether those controls are configured appropriately, enforced consistently and connected to the organisation’s approval responsibilities.

A user’s ability to open a file does not automatically mean that an automated process should combine it with every other accessible record, send its contents elsewhere or change the system it came from.

For SenangAI, I think about this as three separate permissions: permission to know, permission to recommend and permission to act.

Those boundaries should be checked by the systems executing the work. A sentence in a prompt telling an agent to behave carefully cannot carry the entire burden.

The same applies to retrieved documents. A document should supply information; it should not gain the authority to change the agent’s operating rules simply because the agent reads it.

Approval must contain enough information to be meaningful

“Human approval required” sounds reassuring. Its value depends on what the human can actually judge.

Imagine a recommendation to change a delivery commitment. An approval screen should identify the customer and order, show the current and proposed commitment, explain the supporting evidence, surface conflicting records, and describe what will happen next.

If the relevant stock position changes before execution, the earlier approval may no longer cover the proposed action. The system should recheck the conditions and, where necessary, return for review.

A stream of vague confirmation boxes can train people to approve without thinking. I would reserve deliberate review for meaningful consequences and make low-risk, reversible work proceed within pre-agreed limits.

The design challenge is to place attention where it changes the outcome.

A practical example: finding a margin opportunity

Consider an illustrative distributor whose sales, inventory and service records suggest a product line is becoming less profitable. This is a hypothetical workflow, not a claim about Goldman or a measured SenangAI customer result.

An AI system might identify rising service costs, repeated discounts and slow-moving inventory. That discovery could reveal a pricing opportunity, an operational problem or a misleading accounting entry.

Before recommending action, the system needs to establish which records belong together, whether their reporting periods align, and whether returns or rebates have been counted consistently.

A citation helps a reviewer inspect evidence. It does not prove that the evidence supports the conclusion. A source can be accurate while the comparison built from it is wrong.

The next step could be a proposed investigation or draft pricing scenario. Changing prices, sending customer messages or adjusting a commercial commitment would require separate authority.

This is where useful business intelligence becomes useful business action: through a visible sequence of evidence, interpretation, decision and controlled execution.

Sovereignty includes operational choices

For organisations considering private or sovereign AI, deployment location is an important decision. It is also only one part of control.

A locally hosted system can still expose information to the wrong employee or execute an inappropriate change. A centrally managed service can still leave the organisation dependent on a model, integration or permission arrangement it cannot easily replace.

The questions I would ask include: can we revoke an agent’s access quickly? Can we export our knowledge and activity records? Can we change a model without rebuilding every workflow? Can we identify which version produced a consequential recommendation?

These questions extend the perspective in my earlier article on sovereign AI. Control has to remain usable when something changes, including during an incident or a supplier transition.

What this asks of SenangAI

Kognosys is my company, so I have a commercial interest in this discussion. I also have an obligation to distinguish the direction we are building towards from capabilities proven in a particular deployment.

My ambition for SenangAI is to help businesses discover issues, understand causes, identify opportunities and act with appropriate authority.

That ambition creates tests we should be willing to face. Can a user retrieve information outside their access rights? Does the system expose conflicting evidence? Can a reviewer understand a proposed change? Does revocation take effect when it matters? Can a failed action leave a partial update, and if so, who is told?

A successful demonstration cannot answer all of these. They need evaluation against the actual data, integrations, permissions and operating conditions of each deployment.

We should also measure how much work reviewers must do. An AI system that produces plausible recommendations faster than people can validate them may simply relocate the bottleneck.

Give experimentation a route into everyday use

My preferred corporate response would provide a progression: experimentation with safe data, controlled evaluation with a named owner, and operational use with monitoring, support and recovery arrangements.

Each step should have a clear entry requirement and someone accountable for the decision. Employees should be able to see how a promising idea advances, rather than facing an unexplained refusal or an indefinite engineering queue.

Smaller organisations need the same clarity, even when one person holds several responsibilities. They may start with one approved source, one repeatable task and a tightly limited action. That is a manageable place to learn.

The lesson I take from this reporting is that AI adoption creates an ownership problem as quickly as it creates a capability opportunity.

For me, SenangAI’s credibility will depend on whether we help organisations manage both. The standard is whether people can understand the evidence, control the consequences and keep the work dependable after the excitement of the first demonstration has passed.