Goldman Sachs Restricts Access to Claude Code: From Vibe Coding to Enterprise AI Engineering Governance—and Rethinking the Boundaries of AI Innovation

How high-risk enterprises can build a sustainable AI operating model that balances business innovation, software engineering accountability, and organizational risk

From Open Experimentation to Restricted Access: What Exactly Happened at Goldman Sachs?

On November 2, 2026, Bloomberg reporter Todd Gillespie reported that Goldman Sachs was tightening employee access to advanced AI coding tools. According to internal guidance updated in October and reviewed by Bloomberg, Goldman had previously allowed bankers to use Anthropic’s Claude Code and certain Microsoft GitHub tools. The bank has since narrowed access to these tools, largely restricting their use to engineering staff. As a result, some traders and bankers lost access to tools they had been using for several months.

The change attracted attention because Goldman had previously taken a notably positive approach to AI-assisted coding by non-technical employees. In July 2026, Goldman CIO Marco Argenti publicly described how traders, bankers, and other non-technical employees could use AI tools to build solutions for business needs and then hand those solutions over to the firm’s approximately 12,000 engineers for further development. This approach, commonly known as vibe coding, aims to bring the people closest to business problems directly into the process of creating tools, reducing the distance between identifying a need and implementing a technical solution.

Just a few months later, access policies changed. Bloomberg linked the decision to assessments of productivity and risk management. Goldman spokesperson Nick Carcaterra said that the firm makes selected AI tools available to employees to identify the most promising use cases across different business areas. After a period of experimentation and an assessment of factors including productivity and risk management, the tools are placed in the hands of employees best positioned to use them over the long term. This statement is significant: it suggests that Goldman’s policy adjustment reflects an evaluation of experimentation and a reallocation of resources, rather than a wholesale rejection of the commercial value of AI-assisted coding.

The limits of the available evidence should be made explicit. Public reporting has not disclosed Goldman’s internal assessment, a list of specific risk incidents, quantitative productivity results, or the individual reasons for restricting each tool. There is therefore no basis for claiming that the bank experienced a data breach, a code-related incident, or a regulatory violation. What can be established is that access was narrowed and that the firm reassessed productivity and risk during its experimentation phase. Any conclusions about specific technical weaknesses or management problems must be treated as analysis, informed by Goldman’s published security policies, the engineering requirements of financial institutions, and the organizational logic behind the decision.

Why Goldman Initially Allowed Bankers to Use Claude Code

Business Professionals Are Closer to the Problems They Need to Solve

To understand why Goldman initially opened access to AI coding tools, it is important to understand how business knowledge is distributed within a financial institution. Traders work directly with client trading flows, market movements, positions, and price fluctuations. Investment bankers routinely handle corporate financial data, transaction materials, client research, and complex documentation. These activities contain many localized needs that are not fully addressed by formal enterprise software systems.

Traditional enterprise software development often suffers from a mismatch between demand and delivery. A business unit submits a request, which is then translated by product managers, assessed by technical teams, incorporated into an architecture, scheduled for development, tested, and eventually deployed. By the time the solution reaches the user, the original business opportunity may already have passed. This is particularly relevant in trading and market research, where requirements are highly time-sensitive. Even a delay of several days can reduce the value of an analytical tool.

AI-assisted coding changes this process. Business professionals can describe a problem in natural language and use tools such as Claude Code to inspect relevant code, generate scripts, create data-processing workflows, build interfaces, or develop analytical prototypes. A trader no longer needs to become a professional software engineer before attempting to turn a recurring calculation or information-processing task into a working tool.

Goldman’s publicly discussed use cases for non-technical employees included monitoring client trading flows, modeling market movements and positions, and generating written and graphical content. These use cases share several characteristics: business professionals possess the relevant domain knowledge, tasks are often repetitive, results can be evaluated through relatively rapid business feedback, and prototypes can be explored at comparatively low cost.

From the perspective of enterprise AI transformation, this addresses a longstanding problem: some of an organization’s most valuable innovation opportunities emerge at the operational front line, while software development resources are traditionally concentrated in technology departments. AI lowers the cost of expressing requirements and validating ideas, allowing business innovation to become less dependent on IT development queues.

Vibe Coding Changes How Enterprises Discover Software Requirements

The significance of vibe coding goes beyond generating code from natural-language instructions. Its deeper impact lies in changing how software requirements are discovered.

Traditional software development generally begins with a business unit submitting a reasonably well-defined requirement. In practice, however, many business needs are unclear at the outset. Users often discover whether a problem has been correctly understood—and which features are genuinely useful—only after they can interact with a working prototype.

AI-assisted coding enables business professionals to conduct repeated experiments at low cost: describe a problem, generate a prototype, run it, observe the results, refine the instructions, and generate another version. Some of the work that once took place through meetings, requirements documents, and repeated rounds of communication can now be moved into tools that can actually be executed and evaluated.

In this sense, the initial value of AI-assisted coding should be measured by the efficiency of requirements validation, not simply by the speed of code generation. A prototype may never enter production and still create meaningful value if it helps a team identify a real problem, validate a business assumption, or rule out an unsuitable approach.

Goldman’s initial experiment was therefore reasonable. It sought to make business professionals the initiators of innovation and engineers the specialists responsible for implementation and quality assurance. The real challenge was how to turn open-ended prototyping into an enterprise software delivery process with clear ownership, engineering standards, and defined access boundaries.

Engineering Refinement Does Not Automatically Resolve Production Risk

Marco Argenti described a model in which engineers would further improve solutions created by business professionals. This is an attractive organizational design, but it rests on an assumption that is often overlooked: engineering teams can take ownership of all prototypes and turn them into reliable software.

In reality, there is a substantial engineering gap between a prototype and a production system. A prototype running on an individual's computer demonstrates only that a particular function works under limited conditions. It does not demonstrate that the software has authentication, access controls, data isolation, exception handling, audit logging, automated testing, deployment rollback, or ongoing maintenance capabilities.

Tools created by business professionals may also proliferate into multiple versions, duplicate implementations, individually owned scripts, and informal team-wide distributions. Once other employees begin using a tool, a script originally intended for personal validation can gradually become an operational dependency. As its user base expands, the implications for data access, calculation logic, error propagation, and maintenance responsibility change as well.

Engineering teams face a new resource-allocation challenge when they take over these prototypes. Engineers must understand the business logic, inspect AI-generated code, add tests, establish permissions, manage dependencies, and maintain deployment environments. AI may shorten prototype generation time, but it can shift work into engineering review and productionization. Without standardized intake and acceptance criteria, the more prototypes an organization creates, the greater its engineering governance burden may become.

The underlying issue revealed by Goldman’s early experimentation is therefore this: the pace of business innovation has changed, but the enterprise mechanisms for software delivery and risk governance may not have evolved at the same speed.

Why Access Was Restricted: An Analysis of Enterprise Engineering Considerations

Goldman has not publicly disclosed the specific findings of its internal risk assessment. The following analysis distinguishes publicly reported facts from reasonable inferences based on financial-sector engineering practices. These inferences should not be mistaken for incidents or conclusions confirmed by Goldman.

Productivity Assessment: Faster Code Generation Does Not Necessarily Mean Higher Business Productivity

Goldman’s spokesperson explicitly referred to productivity assessment. This is an important starting point for understanding the access restrictions.

AI coding tools can generate code quickly, but enterprises need to evaluate the efficiency of the complete task-delivery process. Imagine that a trader uses Claude Code to build an analytical tool prototype in half an hour, completing work that would otherwise have taken two days to obtain through conventional development. The apparent productivity gain is substantial. However, if engineers then spend three days checking data definitions, rewriting code, adding tests, and configuring deployment, the overall delivery cycle for the team may not have become shorter.

Maintenance costs must also be considered. If only the original creator understands a tool’s data sources, calculation assumptions, and operating procedures, other employees may struggle to verify or take over the system. The cost of generating AI code may be low, but the subsequent costs of understanding, reviewing, correcting, and maintaining it do not disappear.

Enterprises should therefore distinguish at least four productivity measures:

• Prototyping efficiency: The time required to move from a business problem to a working prototype.

• Productionization efficiency: The time required to move from prototype submission through engineering review and testing to formal deployment.

• Net task productivity: The change in total business and engineering effort required to complete a task at an equivalent quality level.

• Long-term maintenance cost: The ongoing cost of troubleshooting, modifying code, maintaining permissions, and upgrading versions.

If an organization focuses exclusively on prototype generation speed, it may improve local efficiency while reducing overall delivery efficiency.

Data Security: AI Coding Tools Expand the Surface Area of Data and System Access

Claude Code differs from an ordinary chatbot in an important respect: within an authorized environment, it can read files, inspect code, execute commands, and modify projects. Depending on its deployment configuration, it may also access external services through MCP, APIs, or other integrations.

This means that enterprises must govern more than the information employees submit to a model. They must also manage what an AI Agent can access, modify, invoke, and transmit during execution—and where the results of that execution can go.

Consider Goldman’s trading business. Trading flows, client positions, trading strategies, internal research, and material non-public information are subject to different levels of sensitivity. If an AI coding tool can access these data in an inadequately isolated environment, risks may arise from improper data handling, sensitive information being written to logs, unapproved external connections, incorrect file access, or tools being shared with employees who do not have the corresponding data permissions.

It is important to distinguish between two separate questions: whether a model is permitted to process a particular category of data, and whether the execution environment surrounding that model is secure. Even when an enterprise uses a commercially licensed model, this does not automatically mean that its code execution environment, third-party dependencies, plugins, and data flows satisfy financial-sector security requirements.

Goldman’s publicly available 2024 Client Security Statement provides relevant context. Its security framework emphasizes identity-based access, approvals, least-privilege controls, authorization for critical production environments, logging, and periodic reviews. For AI, the firm describes a firmwide AI policy and a federated model for use-case development, bringing together business units and AI platform teams. The statement also makes clear that access to external LLMs is intentionally restricted and requires prior approval before such models can be accessed from firm systems or used for business purposes.

The document predates the October 2026 access changes. It cannot establish that a specific security incident caused the restrictions, but it does illustrate a longstanding principle in Goldman’s enterprise security approach: AI innovation must operate within a firmwide governance framework.

Software Quality: A Program That Runs Is Not Necessarily a Reliable Business System

Financial software has requirements that differ significantly from those of ordinary personal productivity tools. An incorrect formula, data mapping, or unrecognized edge case can affect business decisions.

For example, suppose a trader uses AI to generate a market-position simulation tool. The program can read data, generate charts, and produce forecasts. But does it correctly handle time zones, trading days, currencies, product units, missing data, and abnormal market conditions? Does its calculation logic conform to the business definitions? Can it reproduce the result for a historical point in time? Does it record the input data and model version?

These questions cannot be answered simply by checking whether the interface displays correctly.

AI-assisted coding can also create a strong sense of completion. The interface has been generated, the script has executed, and an output is visible. Yet successful execution is only the minimum threshold for software quality. Financial software must additionally demonstrate that its calculations are correct, its results are reproducible, its data is traceable, its permissions are verifiable, its exceptions are handled, and its important changes are subject to review.

From an engineering perspective, code review, static analysis, dependency scanning, unit testing, integration testing, business-rule validation, and production-environment verification must not be waived simply because the code was generated by AI.

Accountability and Auditability: Individually Created Tools Can Become Organizational Dependencies

Another organizational risk is easy to overlook: ownership of software assets and accountability for their operation.

In conventional development, enterprises can usually identify system owners, code repositories, deployment environments, change records, and operations teams. In an open-ended vibe-coding environment, however, employees may create tools in personal workspaces, independent scripts, or temporary projects. Colleagues may then begin using those tools.

This can create a form of shadow software asset: the organization has become dependent on the tool, but its registration, maintenance ownership, risk classification, and change-management procedures may not yet exist.

Once a tool is used for client analysis, trade monitoring, or internal decision-making, the enterprise must be able to answer several questions: Who approved it? What data does it use? Who validated its calculation logic? Who is accountable if it produces an error? Can historical results be reproduced? Is there an alternative process if the tool becomes unavailable?

In a regulated environment, the absence of such an evidence trail can make it difficult for an enterprise to demonstrate that its business processes comply with internal controls and regulatory obligations.

The governance of AI coding therefore ultimately becomes a question of software asset governance. Business professionals may create the tools, but production systems must have clearly designated organizational owners and accountability structures.

Engineering Capacity: Prototype Generation May Outpace Productionization Capacity

Another reasonable inference is that enterprises may need to reassess the balance between the rate of prototype generation and the capacity of engineering teams to absorb and productionize those prototypes.

Goldman has approximately 12,000 engineers, but the software assets, legacy systems, and business rules of a large financial institution are highly complex. Engineering teams must maintain core trading systems, data platforms, infrastructure, security controls, and systems related to regulatory obligations, in addition to reviewing AI-generated prototypes.

If business professionals can continuously generate large numbers of prototypes without a consistent mechanism for value assessment, code acceptance, and project prioritization, engineering teams may become occupied by low-value, duplicated, or difficult-to-maintain work.

AI tools may then increase individual creative capacity while reducing overall organizational delivery efficiency. Goldman’s spokesperson included productivity in the assessment, suggesting that the firm ultimately needs to evaluate the long-term contribution of AI tools across the complete operating model—not merely individual user experience.

The Real Challenge for Goldman: Bridging the Gap Between Business Innovation and Software Production

Taken together, Goldman’s experience can be understood as a typical organizational tension that emerges when enterprise AI applications move from experimentation toward production governance.

This tension has three layers.

The first is business discovery capability. Business professionals can identify problems, describe requirements, and build prototypes. AI significantly lowers the cost of initiating innovation. This layer needs to remain open because discovering valuable opportunities depends on understanding the operational environment. Excessive centralization within IT can suppress those opportunities.

The second is engineering transformation capability. Business prototypes must pass through code review, architectural adaptation, testing, data governance, permission configuration, and deployment validation before they can become systems on which an organization can reliably depend. This layer requires professional expertise and standardization; it cannot rely solely on individual experience.

The third is enterprise operating governance. Once software enters production, it requires continuous monitoring, auditing, maintenance, upgrades, and risk management. This layer depends on clearly assigned organizational responsibilities, technical controls, and institutional safeguards.

These three layers have a clear relationship. Business innovation can be widely distributed; engineering production requires professional oversight; and production operations must remain under enterprise control. If an organization builds only the first layer, it risks accumulating prototypes that cannot be maintained. If it focuses exclusively on the second, it may recreate the bottlenecks of traditional software development and slow business innovation. Without the third, even AI applications that have entered production can become new operational risks.

The central question raised by Goldman’s experience is therefore whether enterprises can establish an integrated mechanism that keeps business innovation open, engineering production professional, and system operations under control.

Lessons Beyond Goldman: How Enterprises Should Design Their AI Coding Operating Model

Establish a Dual-Track Model for Prototypes and Production Systems

Enterprises should neither require every piece of AI-generated code to follow the full development process for production systems nor allow every prototype to evolve naturally into production software. A more practical approach is to establish separate tracks for prototyping and production.

The objective of a prototyping environment is to validate business assumptions. Employees should be able to use AI coding tools with controlled datasets, simulated data, and isolated execution environments. They can create scripts, interfaces, analytical workflows, and automation tools, but the permitted scope, data boundaries, and validity period of each prototype must be explicit.

Production environments, by contrast, must have formal engineering acceptance criteria. When a prototype is submitted, it should include its business objective, intended users, data sources, calculation rules, dependencies, expected outputs, and potential impact. Engineering teams then decide whether to accept it based on business value and risk level, before completing code review, testing, permission configuration, and deployment.

The key is to avoid imposing production-level governance costs on every early-stage idea while also preventing a successfully running prototype from being mistaken for a production-ready system.

Establish an AI Application Risk Classification and Permission Matrix

Tool permissions should not be determined solely by whether an employee belongs to the engineering function. They should also reflect task risk, data sensitivity, execution capabilities, and potential business impact.

For example, an enterprise could establish the following risk classification:

This model allows non-technical employees to continue using AI coding tools within appropriate boundaries, while restricting direct access to high-risk production systems. Employee roles remain relevant, but permissions should also be determined by task risk and the specific capabilities required for execution.

In particular, enterprises should distinguish among code-generation permissions, file-read permissions, external network access, API invocation, production-data access, and write access to production environments. Separating these capabilities is more effective than simply allowing or prohibiting an entire tool.

Establish an Engineering Acceptance Process from Prototype to Production

AI-generated prototypes created by business professionals should enter a formal engineering delivery process with clearly defined stage gates.

Stage 1: Confirm the business problem. The business owner must define the problem to be solved, the cost of the current process, the expected benefits, and the intended scope of use. Prototypes without demonstrable business value do not need to proceed to productionization.

Stage 2: Review data and security. Confirm that the data used by the prototype is authorized and determine whether it involves non-public client information, personal information, or restricted internal data. Check whether external models, third-party dependencies, MCP services, and network connections have been approved.

Stage 3: Conduct technical review. Engineers examine the code structure, dependencies, calculation logic, exception handling, permission model, logging, and potential security issues. For calculations that affect critical business activities, domain experts should also provide verifiable rules and test cases.

Stage 4: Test and accept. Establish unit tests, integration tests, and business acceptance criteria. Validate normal inputs, abnormal inputs, boundary conditions, error recovery, and reproducibility. Tools with significant business impact should undergo independent validation.

Stage 5: Deploy to production. Once approved, the solution enters the formal environment using enterprise-managed code repositories, identity systems, credential management, deployment pipelines, and monitoring systems. Deployment must preserve version records and provide a rollback plan.

Stage 6: Operate and reassess. Monitor usage, failures, permission changes, data access, operating costs, and business benefits. Significant changes to business rules, model versions, data interfaces, or execution permissions should trigger a new assessment.

The purpose of this process is to transform AI-generated software from an individually created tool into an enterprise asset that can be verified, transferred, audited, and maintained.

Redefine Engineers as Owners of AI System Quality, Not Just Producers of Code

In the age of AI-assisted coding, the responsibilities of engineers are changing. They no longer need to write every line of code themselves. They increasingly need to establish the engineering environments that enable AI to work correctly.

In August 2026, Goldman CIO Marco Argenti discussed the need to transfer internal knowledge—such as data standards, security protocols, and organization-specific engineering practices—to AI Agents as engineers make broader use of them. Goldman needs AI to understand its own technical environment so that generated code can better conform to the firm's requirements.

Combined with the subsequent restrictions on access for some non-engineering employees, this observation points to a deeper lesson: enterprises must translate engineering standards, business rules, data permissions, and operational constraints into context that AI can read, execute, and validate.

This requires standardized code templates, architecture specifications, testing frameworks, approved tool lists, data-access interfaces, API permissions, and deployment policies, integrated into AI Agent execution environments.

The engineer’s core contribution will increasingly lie in defining constraints, designing systems, building verification mechanisms, and taking responsibility for production outcomes. AI expands implementation capacity; engineers ensure that implementation meets organizational requirements.

A Cross-Industry Perspective: Financial Institutions Are Seeking More Mature Models of AI Engineering Governance

Goldman’s restrictions are not an isolated experiment in the financial sector. Other major financial institutions are also addressing AI Agent access control, execution isolation, cost management, and production accountability.

JPMorgan: Controlling Agent Risk Through Isolated Execution Environments

In September 2026, Business Insider reported that JPMorgan Chase was introducing monthly spending limits for some Claude Code users and rolling out a containerized development environment called Devspace. According to the report, Devspace runs on AWS and is designed to isolate Agents from employee credentials, sensitive files, and internal systems, while allowing the bank to monitor and authorize Agent activity.

This approach offers a useful contrast with Goldman’s access restrictions. Public reporting on Goldman describes a narrowing of the range of employees permitted to use certain tools. JPMorgan’s reported initiative illustrates another engineering governance path: retaining AI coding capabilities while constraining their execution environments.

These approaches are not mutually exclusive. In high-risk enterprises, personnel access controls and execution-environment isolation should work together. Determining who can use a tool is not enough to control what the tool does at runtime. Likewise, providing a sandbox cannot replace business approval, data permissions, or clear accountability.

Goldman’s Own Federated Model for AI Governance

Goldman’s 2024 security statement also reveals an organizational design worth examining. The firm uses a federated model for AI use-case development, bringing together the commercial expertise of business units and the GenAI capabilities of platform teams, under firmwide and divisional governance and oversight.

This model helps explain why enterprise AI innovation should not be determined entirely by central IT, nor left entirely to individual business users. Business units identify use cases, define business value, and validate results. Platform teams provide models, tools, and technical standards. Risk and compliance functions provide independent oversight.

Goldman’s 2026 access adjustment can be understood as a change in how this type of governance is applied to specific tools. However, available public information is not sufficient to establish that the decision was made entirely through the organizational model described above. It should therefore be treated as relevant institutional context and a source of practical insight—not as a direct account of Goldman’s internal decision-making process.

A Key Industry Tension: How Should Open Innovation and Centralized Governance Be Balanced?

Financial institutions face a common challenge: AI-assisted coding is becoming widely available, lowering the barrier to creating software internally, while responsibility for software production remains unchanged.

An open model allows business units to identify and validate requirements quickly, but can lead to tool proliferation, duplicated development, and unclear accountability. A centralized model helps maintain engineering quality and consistent governance, but may recreate traditional development queues and slow innovation.

More mature enterprises will not simply choose between these two models. They will establish common platforms and rules that provide different execution environments for innovation at different risk levels. Business professionals will be able to create within controlled environments; engineers will receive and improve solutions through standardized pipelines; and governance teams will determine whether systems can enter production based on risk and evidence.

This is why lessons from financial institutions have relevance well beyond the financial sector.

HaxiTAG’s Perspective: Moving from AI Tool Management to AI Production Systems Engineering

In our enterprise AI transformation work, we are increasingly focused on a fundamental shift: once an organization introduces AI Agents, the objects requiring governance extend beyond models and tools. They now include tasks, context, execution environments, data, permissions, workflows, and final delivery outcomes.

Goldman’s experience demonstrates that granting employees access to AI tools is only the beginning of deployment. Enterprises must also determine where AI executes, which data it can access, which systems it can invoke, how its outputs are validated, and who is accountable for the final business outcome.

HaxiTAG’s position is that enterprises should build AI applications as governable production systems, rather than allowing fragmented automation capabilities to emerge from individual employees’ prompts and tool-use habits.

From Know-How to AI-Executable Context

Business professionals possess substantial tacit knowledge, including operating rules, decision criteria, exception-handling procedures, client requirements, and organizational experience. This knowledge is often scattered across documents, systems, individual experience, and departmental workflows.

An AI Agent given only a task description cannot automatically understand the real operating rules of an enterprise. It needs task-relevant knowledge, data definitions, business constraints, execution permissions, tool documentation, and acceptance criteria.

We describe this transformation as converting Know-How into AI-executable Context.

In engineering practice, enterprise knowledge should be organized into structured context assets, including:

• Business knowledge: Business objectives, terminology, business rules, and exception conditions.

• Data knowledge: Data sources, field definitions, quality standards, and access permissions.

• Execution knowledge: Tool documentation, API interfaces, operating procedures, and workflows.

• Constraint knowledge: Security policies, compliance requirements, approval conditions, and prohibited actions.

• Acceptance knowledge: Output formats, quality metrics, validation methods, and failure-handling procedures.

These assets should be maintained centrally and supplied dynamically to Agents according to the task, user identity, and execution stage through mechanisms such as a Context Builder. This is how AI execution can remain aligned with the enterprise’s actual operating rules.

From Agent Loop to Workflow, Gate, and Workboard

A single Agent Loop can handle task interpretation, planning, tool invocation, and result generation. Enterprise work, however, often involves multiple roles, steps, and approval points.

Consider an automated trading research workflow. It may involve data retrieval, definition validation, model calculations, result analysis, report generation, and business approval. Each stage has different permission requirements and acceptance criteria.

HaxiTAG therefore advocates extending the Agent Loop with three additional engineering capabilities: Workflow, Gate, and Workboard.

Workflow breaks complex business tasks into steps with defined inputs, outputs, and execution sequences. Gate enforces data permissions, execution approvals, quality checks, and risk controls. Workboard records task status, execution evidence, owners, and delivery outcomes.

Together, these capabilities turn an Agent from an intelligent program that can invoke tools into a controlled execution unit within an enterprise workflow. Every task can be tracked, every critical operation can be reviewed, and abnormal conditions can be traced to their source, with execution restored when necessary.

From Tool Permissions to Runtime Authorization Governance

One of the most direct technical lessons from Goldman’s experience is that enterprises must distinguish between whether an employee can use an AI tool and what an AI Agent is actually allowed to do at runtime.

A business professional may have permission to develop prototypes, but an Agent must still obtain authorization before accessing enterprise data. An engineer may be allowed to modify code, but that does not mean the Agent automatically receives write access to production systems.

HaxiTAG recommends implementing access controls directly within execution environments, rather than relying exclusively on account-level permissions. Enterprises should establish the following controls:

1. Identity binding: Every Agent task must be associated with a real user, organizational identity, and business context.

2. Least privilege: Agents should receive only the data and tool permissions required for the current task.

3. Execution isolation: Code should run in controlled containers or sandboxes, with restrictions on file, network, and system access.

4. Credential protection: API keys, database passwords, and other secrets should be managed through secure credential services and never exposed directly to the model.

5. Operational auditing: Record tool calls, data access, file modifications, command execution, and key decisions.

6. Human approval: Actions affecting funds, client interests, production configurations, or material business outcomes must have explicit approval gates.

7. Failure recovery: Establish timeout, termination, rollback, and human takeover mechanisms.

It is important to recognize that sandboxing alone cannot solve every security problem. It must work alongside identity authentication, data-access controls, network policies, approved tool lists, and auditing systems to form an effective runtime governance framework.

From Code Evaluation to AI Task Outcome Evaluation

Enterprises should not measure success simply by counting how often employees use Claude Code or how many lines of code AI generates. What matters is whether AI improves business outcomes and whether those outcomes can be delivered reliably and consistently.

HaxiTAG recommends an evaluation framework that covers the full lifecycle of task execution:

These metrics should be established against scenario-specific baselines and assessed through before-and-after comparisons. In high-risk business scenarios, risk events and control effectiveness must remain hard constraints; productivity improvements cannot simply offset failures in these areas.

An Implementation Roadmap for Enterprise AI Transformation: Avoiding Repeated Access Reversals

Goldman’s experience suggests that enterprises should establish mechanisms for experimentation, validation, productionization, and governance before granting broad access to AI coding tools. We recommend a six-stage implementation roadmap.

Stage 1: Identify and Prioritize Business Opportunities

Begin with high-frequency, repetitive, relatively well-defined tasks with clear data sources. Identify scenarios in which AI can deliver measurable value.

Each candidate use case should have an opportunity assessment card that defines the current process, manual effort, business pain points, data sensitivity, impact of errors, expected benefits, and acceptance metrics. Scenarios involving funds, client interests, or consequential decisions should face higher entry requirements.

Stage 2: Conduct Controlled Experiments

Provide business professionals with isolated AI coding environments. Prioritize simulated data, masked data, and approved data interfaces. Allow employees to create prototypes quickly, but explicitly prohibit unapproved connections to production databases, the use of sensitive client information, and deployment to formal business systems.

At this stage, focus on prototype completion rates, business-user participation, the extent to which real problems are solved, and the potential for subsequent engineering adoption.

Stage 3: Conduct Joint Value and Risk Assessment

Business owners, engineering teams, security, risk, and compliance functions should jointly evaluate experimental outcomes. The assessment should determine whether a prototype solves a real problem, duplicates existing capabilities, has reasonable engineering costs, and presents risks that can be controlled through technical and organizational measures.

The assessment should produce an explicit decision: continue investment, adjust the approach, pause the experiment, or terminate the project.

Stage 4: Productionize Through Engineering

Prototypes that pass assessment should enter the enterprise’s standard engineering process. Architecture design, data governance, access controls, automated testing, code review, logging, deployment, and rollback capabilities must be completed.

This stage requires clearly identified system owners, business owners, technical owners, and risk owners. Production systems must not remain dependent on the personal knowledge of their original creators.

Stage 5: Operate and Monitor in Production

After deployment, continuously monitor Agent execution, data access, task success rates, business outcomes, exceptions, and operating costs. Establish change-management procedures for model upgrades, prompt changes, tool-permission adjustments, and changes to business rules.

In particular, enterprises must prevent AI Agents from gradually acquiring unreviewed capabilities during operation. Adding tools, expanding data access, or increasing execution permissions should all trigger reassessment.

Stage 6: Continuously Improve Organizational Capabilities

Use production results to improve Context, Skills, tool interfaces, workflows, and evaluation standards. Convert high-value, reusable business experience into enterprise knowledge assets so that subsequent Agents can draw directly on validated organizational practices.

The result should be a continuous improvement cycle: discover business problems, validate AI prototypes, productionize through engineering, collect operational feedback, consolidate organizational knowledge, and initiate the next round of innovation.

The Proliferation of AI Will Not Eliminate Engineering Accountability; It Will Make Engineering Governance More Important

At first glance, Goldman’s decision to restrict some employees’ access to Claude Code appears to be a change in tool permissions. At a deeper level, it reflects the effort of a large enterprise to rebalance the speed of AI innovation against its organizational governance capabilities.

Vibe coding allows business professionals to create tools more directly, while AI Agents further reduce the barriers to software development and automated execution. Yet enterprise software quality requirements, data security obligations, business continuity responsibilities, and regulatory duties have not diminished. AI can create programs faster, but it can also expand their impact more quickly. Innovation without engineering constraints can generate large numbers of software assets that are difficult to audit, maintain, or assign responsibility for.

We believe that the next stage of enterprise AI transformation will increasingly be defined not by the breadth of model and tool adoption, but by an organization’s ability to establish reliable AI production systems. Business professionals should be empowered to identify problems and validate ideas. Engineers should be responsible for building reliable execution environments and quality assurance systems. Management must use permissions, processes, auditing, and evaluation mechanisms to ensure that innovation remains within organizational control.

For HaxiTAG, this is also the central challenge of Forward Deployment Engineering (FDE): translating enterprise Know-How into AI-executable Context, turning AI tool invocation into controlled Workflows, converting execution processes into verifiable Evidence, and transforming business outcomes into organizational capabilities that can continuously improve.

The lesson from Goldman is not that enterprises should use AI less. It is that they need to redesign how AI is used. A mature AI-native organization should enable more employees to participate in innovation while ensuring that every AI system entering production has clearly defined boundaries, explicit accountability, verifiable quality, and sustainable operating capabilities.

That is the critical step from widespread AI tool adoption to enterprise AI productivity.

Fact-checking and source references

• Bloomberg — Goldman Restricts Traders and Bankers From Using Some AI Tools, November 2, 2026

• Goldman Sachs — Client Security Statement, October 2024

• Business Insider — JPMorgan Rolls Out Claude Changes: Spending Limits and Additional Security, September 2026

• Enterprise AI Coding Through the Lens of Claude Code Best Practices: What Companies Need Is Not More Code Generation, but a Verifiable Engineering System

• AI Coding Makes One Node Faster; Enterprise AI Engineering Keeps Many Nodes from Falling into Disorder

• Component Security in the AI Coding Era: From Dependency Management to Software Supply Chain Governance

• From Agent Experimentation to Agent Operations: The Key to Scaling Enterprise AI Is Building the Next-Generation Intelligent Production Infrastructure

• When AI Agents Enter the Office: The Hidden Management War Behind the ServiceNow Case

• FDE: The Last Mile of Enterprise AI Deployment — Redefining Field Deployment Engineering from the HaxiTAG Perspective

• From Token Cost to Task-Level Intelligent Compute Orchestration: Databricks’ AI Coding Experience and Forge’s Engineering Delivery Practice