A reported policy shift at Goldman Sachs raises a useful question for every company: who can use powerful AI tools, on which data, and with whose approval?
A company buys an AI coding assistant for one engineer. Weeks later, an analyst is using a personal account to write scripts for customer reports. Someone in finance has connected a spreadsheet to an unfamiliar automation service. None of these experiments necessarily looks dangerous on its own. Together, they reveal a governance gap.
The debate about AI coding tools at work has sharpened after reports that Goldman Sachs restricted access to some advanced coding products for bankers and traders. The important question for smaller companies is not whether a bank's policy should be copied. It is whether employees are receiving tools without an agreed boundary between drafting, testing and changing real systems.
A business owner may want everyone to experiment. A CTO may be responsible for confidential data and the consequences of an untested script. Both concerns are legitimate. A blanket prohibition can push useful activity into private accounts; unrestricted access can turn a quick prototype into a permanent dependency without anyone accepting ownership.
A workable answer is narrower and more practical. Classify the task, limit its data, assign permissions, check outputs, and make access temporary until results justify more. That approach gives a company room to learn without granting every employee authority over every system.
What did Goldman Sachs actually change?
According to a November 2, 2026 Bloomberg report, Goldman Sachs restricted access to certain advanced AI coding tools for most traders and bankers after an experimentation period. The report described internal guidance updated in October that reserved those tools mainly for engineers, with an exception for specialists known as “strats” who combine finance and engineering work.
That is not the same as banning every employee from using artificial intelligence. The reported change concerned particular coding-capable tools and particular groups of users. The report also described a Goldman spokesperson's explanation that the firm evaluates productivity and risk before deciding where tools belong long term. The underlying internal guidance was not independently reviewed for this article.
A prototype is not a production system
A trader can use an AI assistant to explore an idea, draft a calculation or describe a report. The moment that output becomes an application handling client data or influencing a financial decision, the organization inherits new obligations: access controls, testing, maintenance, records, and accountability when something goes wrong.
The relevant lesson is not that non-engineers cannot contribute software ideas. It is that permission to experiment is different from permission to deploy. A sound policy allows useful experiments without confusing their results with approved production assets.
For a small company, the same distinction applies to a salesperson automating CRM updates, an operations analyst writing a stock script, or a finance manager building an invoicing macro. The risks depend on the data and actions involved, not the prestige of the job title.
Who should get AI coding tools at work?
AI coding tools at work should go to employees whose tasks justify them and whose access can be supervised. Developers often need broader coding permissions, while analysts and operations staff may need controlled experimentation. Production deployment, sensitive records and autonomous actions should require additional approval regardless of job title.
Begin with the work itself. Can the person describe the problem, inspect the output, and identify an error before it reaches a customer or system? Who accepts responsibility if a generated script deletes the wrong record? Will the assistant read confidential material or call external services?
Separate the tool from its capabilities
An AI chat interface that helps someone write a formula is not equivalent to a coding agent with terminal access, repository write permissions, access to production credentials and the ability to open pull requests. Both may carry the same product brand. The permissions matter more than the label.
Similarly, an employee who can read a repository may not need permission to push code. A manager who approves a use case does not need unrestricted technical access to perform the approval. Grant the minimum useful capability and expand it only when an owner can explain the benefit and controls.
For companies already connecting business systems, process automation planning provides a useful starting point: document where records move, who authorizes changes, and which steps must remain human decisions.
AI access needs a workflow map
Identify the systems and handoffs an AI tool could affect before purchasing more licenses.
Review Automation Options1. Classify the task before approving the person
What qualifies
Start with a written list of intended tasks, not a blanket request for an AI subscription. Ask a proposed user to name the business process, the expected output, the source of data, and what they intend to do with that output. The same employee may qualify for a low-risk drafting task and not for a production database operation.
Divide uses into exploratory, assisted operational and production-impacting work. Exploratory uses include sample code against synthetic data and explanations of unfamiliar commands. Assisted operational work might draft a report transformation, but a human must validate the result. Production-impacting work changes real systems, money, customer records or public content.
Who signs off
The team lead confirms that the task is useful. IT or the security owner checks the tool and its connected systems. The relevant data owner approves the class of information used. For a small business, one person may hold multiple responsibilities, but each decision still needs to be recorded.
Do not approve a tool because a role sounds technical. An engineer can accidentally expose credentials; a trained analyst may safely work with a synthetic dataset. Technical competence matters, but access boundaries and workflow design matter too.
For the first pilot, select a repeatable task with a clear manual baseline and a way to detect mistakes. If a task cannot be checked, narrow its scope before granting access.
2. Define which data the tool may see
What qualifies
Separate public information, internal business material, confidential company records, customer personal data, and regulated information. A coding tool might receive examples of a database schema without needing actual customer rows. Use masked values or generated test fixtures where possible.
A contract-approved enterprise workspace does not automatically make every data transfer appropriate. Confirm retention settings, access to conversation history, vendor terms, region and contractual duties, and whether users can connect third-party extensions. Ask how the organization can delete data or revoke tokens if the pilot ends.
Who signs off
The data owner decides whether the proposed information may enter the chosen environment. IT checks connector privileges, logging and account configuration. Finance, legal or privacy owners review especially sensitive categories when applicable. Keep decisions explicit so a staff member does not infer that all company data is permitted.
OWASP identifies sensitive-information disclosure as a risk for generative AI systems. That concern is practical: a pasted access token, unredacted customer file, or proprietary algorithm can create exposure even when the employee's intention is legitimate.
The easiest control to enforce is a short approved-data list. If the user cannot tell whether a document is approved, the default should be to ask rather than upload.
3. Match permissions to the real risk
What qualifies
Set distinct access tiers. A view-and-draft tier can answer questions or create local suggestions without editing shared assets. A sandbox tier can run code against test systems. A repository tier can propose changes through review. Production privileges remain a separate approval, not a benefit automatically attached to the paid license.
Where tools can run terminal commands or connect to applications, limit their environment, available tools, network access and credentials. A user should not be able to turn a report-writing experiment into a production deployment merely because an agent offers the option.
How should AI coding permissions be assigned?
Assign AI coding permissions by task, data sensitivity and potential impact, then add role and training requirements. Allow drafting for a wider group, sandbox execution for approved users, and repository changes through review. Reserve production access for separately authorized staff, with logs and a clear rollback plan.
Who signs off
The system owner specifies actions that the tool may perform. Engineering approves repository and deployment paths. Security reviews credentials, external connectors and scope of access. Managers should not be able to bypass these controls simply by purchasing their own licenses.
If the organization has no sandbox, start with no execution access. That constraint is less costly than investigating an unexpected change to live data.
4. Require review before an output becomes an action
What qualifies
AI output can look polished and still contain wrong assumptions, unsafe code or an inaccurate explanation. Define what review means for each use case. A draft email needs factual and tone review. A spreadsheet formula needs edge-case testing. A code change needs tests, security checks and review by someone who can explain its behavior.
Build evidence into the workflow. Record the requirement, input sources, test cases, reviewer and approval. For production code, use existing change control and version history. Never accept “the tool generated it” as an explanation for an untested dependency or an unexplained permission request.
Who signs off
The business owner checks business meaning; the technical owner checks system safety. If one individual plays both roles, consider a second reviewer for higher-impact work. An exception should be rare, time-limited, and documented rather than silently normalized.
The NIST Generative AI Profile provides a broader governance reference for identifying and managing generative AI risks. It is voluntary guidance, not evidence that any particular tool is safe when used without local controls.
The operational test is simple: if a reviewer cannot reproduce or explain the result, the output stays a draft.
5. Pilot, measure and revoke access when needed
What qualifies
Give every pilot a fixed owner, defined task, review date and stopping condition. Capture what the process required without AI, then compare the quality and time spent including checking, corrections and rework. An apparently quick first draft is not a productivity gain if another employee spends hours repairing it.
Consider an illustrative 35-person distributor. Its operations analyst wants to generate a script that reconciles delivery records. The team approves synthetic sample data and a test spreadsheet, but withholds live database credentials. An engineer reviews outputs against known discrepancies before any production integration is considered. This is an example, not a reported company outcome or a client case.
Who signs off
The business sponsor decides whether the benefit merits continuation. IT confirms that tool access remains appropriate. The data owner revisits access if new information types or connectors enter the workflow. Revoke stale licenses and credentials when users change roles or when a pilot ends.
Make feedback useful. Record prevented errors, false positives, manual intervention and unexpected agent actions, not only prompts submitted. A shared log can reveal where a supposedly convenient workflow introduces hidden effort.
A pilot succeeds when it produces a repeatable, reviewed result under clear permissions. Wider deployment comes later and only with a new authorization decision.
Where should companies place their strictest controls?
The following comparison is a qualitative planning aid, not a measured risk score. Each row corresponds to one of the five policy decisions above.
| Decision area | Governance effort | Exposure if ignored | Primary owner |
|---|---|---|---|
| Task classification | Low | Medium | Team lead |
| Data boundaries | Medium | High | Data owner |
| Permission tiers | High | High | IT or security |
| Output review | Medium | High | Business and technical owners |
| Pilot measurement | Low | Medium | Pilot sponsor |
Where sensitive data and executable permissions meet, a company should demand stronger review before expanding access. These are judgment-based relative labels, not industry benchmarks.
Separate useful pilots from production risks
Compare permissions, integrations and review points before expanding your AI rollout.
Discuss AI Control DesignWhen is restricting AI tools the right decision?
Restrict AI tools when a user cannot verify outputs, approved data boundaries are unclear, or the tool can change sensitive systems without review. A narrower pilot is often better than a permanent ban. Wider access makes sense after controls, training and measurable results support the specific task.
Use a decision record instead of a blanket yes or no
- Write the task in one sentence, with its intended business result.
- List the data types, connected services and actions the tool can take.
- Name a business owner, technical reviewer and approval deadline.
- Assign the lowest permission tier that can complete the pilot.
- Review errors, rework, quality and access after the trial.
A restriction fits when a team requests live financial records for a task that can be tested with synthetic data, or when a coding assistant can publish code without a competent reviewer. It fits poorly when an organization uses it to avoid building training and review processes for otherwise useful, low-risk work.
For mixed teams, an engineer-only production boundary can coexist with analyst-driven prototyping. That is a more precise policy than pretending every nontechnical employee faces the same risk. It also prevents accidental promotion of informal tools into company infrastructure.
Keep a short list of prohibited actions: uploading passwords or secrets, bypassing approved identity controls, connecting personal accounts to restricted data, running generated commands on production without authorization, and using output as unreviewed evidence for financial or personnel decisions.
If an AI experiment begins affecting core systems, review how its data moves through the ERP and integration environment before deciding whether to formalize it.
How KSoft Technologies Helps With Controlled AI Adoption
At KSoft Technologies, we approach AI-enabled workflows as systems that must fit real operating processes. Our published automation and ERP services cover document and data processing, system integration and workflow design; those capabilities can support a review of where a generated output would enter existing business software.
We can help businesses describe the integration boundary, separate test workflows from production transactions, and identify where a human approval belongs. The policy owner, data classification and decision to grant employee access remain the company's responsibilities. To assess a particular workflow, discuss its AI integration and control requirements.
For general demonstrations and company updates, see the KSoft Technologies YouTube channel. Documentation and safe operating procedures should remain the reference for any actual deployment decision.
Make access a decision you can explain in writing
The Goldman Sachs report presents a familiar tension in a new setting. People discover powerful tools, useful experiments spread quickly, and leadership must decide which activity becomes standard practice. Moving from an open trial to narrower permissions does not necessarily mean abandoning AI. It may mean that the company is beginning to treat the technology as part of its operating environment rather than an informal convenience.
For smaller companies, a simple written decision can prevent confusion. State the approved task, the permitted data, the account and system privileges, the reviewer, and the condition under which access expires. Put that decision somewhere employees can find it. Tell them how to request an exception and who can answer questions when the rules are unclear.
Do not use job title as the only filter. An engineer still needs code review, and a non-engineer may perform valuable work in a properly limited sandbox. Nor should security review become an excuse to suppress every experiment. A good policy gives low-risk ideas room to mature while protecting customers, systems and staff from poorly understood actions.
Start with one current AI use case, not a 40-page policy. Ask the owner to explain its data and permissions in five minutes. If they cannot, you have found the first control to establish.
Put an owner behind your AI rollout
Bring one proposed use case, the data involved and the approvals you need to define.
Plan an AI Workflow ReviewFrequently Asked Questions
What are AI coding tools in the workplace?
AI coding tools are assistants that suggest, explain, generate or sometimes execute software-related work. Some operate inside editors; others can use terminals, repositories and connected services. Their risk depends on what information they access and which actions they can perform. Companies should assess those capabilities separately from ordinary text-generation features.
Why did Goldman Sachs reportedly restrict AI coding tools?
Bloomberg reported on November 2, 2026 that Goldman Sachs narrowed access to certain advanced coding tools after reviewing productivity and risk. The reporting describes restrictions affecting most bankers and traders, while engineering-oriented roles retained access. It does not establish a company-wide prohibition on all AI tools, and the internal guidance was not independently reviewed here.
What business problems can uncontrolled AI coding create?
Uncontrolled use can expose confidential information, produce untested code, change shared records or create applications nobody maintains. The harm often comes from excessive permissions combined with weak review, not simply from generating text. A company needs clear data boundaries, named owners and a way to stop or reverse changes.
How do employees get permission to use AI coding agents?
Employees should submit a short use case describing the task, data involved, expected output and systems the agent may access. A manager confirms business need, while the relevant technical and data owners approve permissions. Access should start in a limited environment, with a review date and a documented process for expansion.
How is AI chat access different from agent access?
A chat assistant may only draft answers, while an agent may read files, run commands, call tools and modify repositories. Product names alone do not reveal these differences. Assess each enabled capability, connection and permission separately. An employee permitted to draft code should not automatically receive approval to execute it on production systems.
Can non-engineers use AI coding tools safely?
Yes, when the use case and controls fit their skills. Analysts and operations employees can explore formulas, prototypes or synthetic datasets in a restricted sandbox. They still need someone capable of reviewing relevant technical risks before production use. A non-engineering title should not automatically disqualify a safe, supervised experiment.
When should a company introduce an AI access policy?
Introduce a written policy before employees connect AI products to confidential records, repositories, finance systems or customer workflows. Even a short policy helps during an initial trial. If tools are already in use, inventory accounts and integrations first, then prioritize the highest-impact permissions instead of abruptly blocking every low-risk task.
How do we start an AI tool pilot with limited risk?
Choose one task that has a clear output and can be checked against an existing manual process. Use approved test data, assign one sponsor and one reviewer, and block production changes. Record errors and correction time alongside any time saved. At the review date, expand, modify or revoke access based on evidence.
What does an AI governance rollout usually cost?
Cost varies with employee count, tool licenses, identity management, data sensitivity, training and system integrations. A basic policy and limited pilot need less work than organization-wide agents connected to production tools. Budget for monitoring, review and staff time, not just subscriptions. Any external implementation estimate should be based on the actual scope.
Why is code review necessary when AI produces working code?
Code that runs successfully may still handle edge cases poorly, leak information or use unsafe dependencies. Review checks the business requirement, design assumptions, security implications and test results. The reviewer must understand the change well enough to maintain or reverse it. AI assistance does not transfer accountability away from the organization.
How long should an employee AI pilot run?
Set a defined review date based on the task rather than treating a trial as permanent access. The pilot needs enough repeated work to expose quality problems, review effort and operational exceptions. Finish with a documented decision: continue under the same permissions, expand with stronger controls, change the workflow or revoke access.
Should we ban AI coding tools for everyone outside engineering?
A blanket ban is not the only responsible option. Restrict sensitive code execution, production permissions and confidential data where review is weak; allow controlled drafting or sandbox work when it can be checked. Use task risk, competence and supervision to determine access. The policy should protect systems while preserving useful experimentation.
