When an AI coding agent can read files, run commands, and change code, deciding who gets access is not just a tooling preference. It is a question about job responsibilities, data boundaries, review, and the cost of getting a decision wrong.

That tension surfaced at Goldman Sachs. Bloomberg reported on November 2, 2026, that the bank had limited Claude Code and GitHub's advanced coding tools to engineers, after an earlier period when bankers could use them. The report attributed the change to internal guidance updated in October and said traders had used the tools for work such as monitoring client trading flows and modeling markets. A Goldman spokesperson told Bloomberg that staff could experiment with certain tools to determine suitable use cases, and that the firm weighs factors including productivity and risk management before placing tools with people best suited to use them long term. Fast Company, summarizing Bloomberg's report, noted an exception for "strats," employees specializing in quantitative engineering and analytics. So this was not a simple engineers-versus-everyone-else boundary. Bloomberg's report is behind a subscriber wall, and Goldman did not publish the internal guidance, so these details describe reported policy, not a public policy document. (Bloomberg Law, Fast Company)

This can be read as a case for restricting coding agents to engineers. It can also be read as a sign that access policy needs more shape than “everyone” or “nobody.” Those are two very different lessons.

The useful comparison is not “safety versus productivity.” It is role-based access versus a blanket ban. One grants capabilities to defined groups under guardrails. The other removes a tool from a broad group because managing the risks or exceptions is not yet acceptable.

Neither choice is automatically right. The decision depends on the work, the data the agent can reach, the controls the organization can enforce, and whether anyone can monitor the result.

What a blanket restriction gets right

A blanket restriction is easy to explain and relatively easy to audit: a class of users cannot access the tool. If a team handles sensitive information, operates under strict regulatory obligations, or lacks the ability to control agent access, a narrower user group can be a sensible temporary boundary.

It also reduces ambiguity. Managers do not need to decide whether every workflow is acceptable, and support teams have fewer exceptions to maintain. A policy can be enforced centrally rather than depending on each worker to choose the right model, account, or data-sharing setting.

But this approach has a cost. A title is a rough proxy for the work someone performs. A non-engineer may have a legitimate, low-risk task, while an engineer may have access to production data or credentials that make an unrestricted agent session inappropriate. A role-only rule can block safe work and still permit unsafe work by the people it includes.

The Bloomberg report does not tell us whether Goldman considered or rejected more granular controls, how access is technically enforced, or what exceptions exist. It only supports the reported restriction and its broad rationale. So the article should not treat it as proof that blanket bans are the bank's preferred long-term governance model.

What role-based access changes

Role-based access control, or RBAC, assigns permissions to roles or groups, then assigns people to those roles. In a coding-agent setup, roles might distinguish software engineers, data analysts, operations staff, and reviewers. The label alone is not the security boundary, though. The boundary comes from which agent capabilities and resources each role can actually reach.

For example, a team could distinguish:

  • Explore: read approved documentation or public code, with no repository write access.
  • Prototype: work in a sandbox or selected repository, without production credentials.
  • Develop: edit code and run tests in approved repositories, with changes reviewed before merge.
  • Operate: use tightly scoped, task-specific operational tools, with explicit approval for consequential changes.

These are illustrative policy tiers, not product defaults. A company must map them to its own systems and risk model. The point is to grant the smallest useful capability, not to create a bigger menu of labels.

A permission model should answer at least four separate questions:

  1. Who can start a session? This is the account, seat, group, or role question.
  2. What can the agent read and change? This includes files, repositories, connectors, and local services.
  3. Which actions need approval or must be denied? This includes shell commands, network access, and actions such as publishing or deployment.
  4. How is the activity reviewed? Access logs and code review help establish what happened and who remains accountable.

A group assignment is not enough if the agent still inherits broad access from the user's machine or account. Nor is a command approval prompt enough if the agent can reach a different path to the same sensitive resource.

The controls exist, but their boundaries matter

Modern products increasingly offer administrator controls that can support more granular policies. They are not interchangeable, and they do not automatically govern every way an agent can act.

Anthropic's current Enterprise documentation describes role-based permissions for features and connectors, as well as delegated administrative capabilities. It says access may depend on both organization-level and role-level settings, and highlights group assignment, including identity-provider synchronization, as part of setup. Its connector rules are additive across roles: if one role blocks a connector but another grants it, the most permissive grant applies. That gives administrators a way to define access by groups, but it also means group overlap must be part of the review. (Claude Enterprise RBAC guide)

For Claude Code specifically, Anthropic documents managed settings that an organization can deploy, separate from a developer's personal or project settings. Managed settings have the highest precedence for many configuration keys. The docs also describe permission rules, including allow, ask, and deny patterns, while noting that rules combine according to specific precedence behavior. An administrator should test the effective policy rather than assume that a JSON file is enforcing what it appears to say. (Claude Code settings and precedence)

OpenAI's Codex documentation describes named permission profiles for local command execution. Profiles can define filesystem and network boundaries, and administrators can use managed requirements to restrict which profiles are allowed. The permission profiles are currently marked beta, and the managed profile allowlist requires Codex 0.138.0 or later. The docs warn that domain rules only constrain traffic when the network proxy is active. They also say permission profiles govern local commands, while connectors, MCP servers, browser features, cloud environments, and approved escalations have separate controls. (Codex permissions, Codex security cookbook)

That distinction is essential. “We configured an agent policy” is not the same as “every tool, connector, environment, and credential path is covered.” Policies are product-specific, and coverage can vary between a local session and a cloud session.

A practical decision test: ban, pilot, or expand?

Instead of starting with a company-wide yes or no, use three gates.

Gate 1: Can you name the approved work?

Write down the tasks the group is allowed to perform. “Use AI” is not a task. “Draft tests in a selected repository” is more precise. “Analyze this customer export” is not precise enough unless the data classification, approved environment, and allowed output are defined.

If leaders cannot name the work, its inputs, and its acceptable outputs, do not broaden access yet. Keep the scope narrow while those questions are answered.

Gate 2: Can you enforce the boundary?

Check whether the organization can control user access, data sources, write permissions, network destinations, credentials, and high-impact actions. Separate the agent's development environment from production systems where possible. Give it a dedicated identity with only the access required for the task. Do not use a developer's everyday credentials as a shortcut for automation.

A policy is not enforced merely because it is written down. Verify which settings apply, whether users can override them, what happens in cloud sessions, and whether each connected tool has its own permissions. The official product documentation is the starting point; testing the deployed configuration is the evidence.

Gate 3: Can you review the outcomes?

Set a review process proportional to the risk. A generated test in a sandbox might need ordinary code review. A change that touches customer data, security controls, or infrastructure may require additional approval and evidence. Preserve enough audit information to understand the agent's actions without collecting unnecessary sensitive content.

If you cannot determine what the agent did, what it could access, or who approved the result, the pilot is not ready to scale.

A rollout checklist for administrators

Use this checklist before expanding access to another team:

  • Define groups by work and data, not title alone. A job title may help route a request, but it should not be the only control.
  • Start with one bounded use case. Name the repository, data class, tools, and success criteria. Do not begin with unrestricted access to every workflow.
  • Separate read, write, and execute permissions. These are different capabilities. Granting one should not silently grant the others.
  • Use managed policy for organization-wide requirements. Keep team conventions in shared project settings, but do not treat a repository file as a substitute for administrator-enforced controls.
  • Keep production credentials out of agent environments. Use scoped, revocable identities for approved tasks and avoid inheriting broad shell credentials.
  • Test the effective configuration. Check the active policy, account group, local versus cloud behavior, connector permissions, and whether deny rules actually win as intended.
  • Require human approval for consequential actions. Decide in advance which changes need an independent reviewer, and make that requirement enforceable.
  • Measure usefulness and risk together. Track task completion and review burden alongside policy violations, oversharing incidents, and exceptions. Do not use adoption alone as proof of value.
  • Set an owner and a review date. Roles drift. Recheck group membership, permissions, and the original use case on a schedule.
  • Have a stop switch. Know how to suspend access, revoke the agent identity, and preserve necessary logs if something goes wrong.

So which approach should you choose?

A blanket restriction can be the responsible choice when the organization cannot yet enforce or audit a narrower policy. It is especially defensible as a temporary measure while teams inventory data, evaluate vendor controls, and establish review practices.

Role-based access is the better direction when different teams have different legitimate needs and the organization can enforce meaningful boundaries around data, actions, and identity. It allows controlled expansion, but it is more work: group design, permission testing, exceptions, and periodic review all need owners.

The mistake is to treat either approach as a complete security strategy. A ban can drive work into unapproved accounts or shadow tooling if no sanctioned path exists. RBAC can become theater if every role gets broad access or if the permissions do not cover the agent's actual tools. The safer policy is the one people can follow and administrators can verify.

Goldman Sachs' reported restriction is a useful signal that access decisions are becoming part of AI deployment, not an afterthought. It is not enough information to conclude that every organization should make the same choice. The practical question for your team is narrower: what work should this agent do, what must it never reach, and can your controls prove the difference?

Save this decision rule: if you cannot identify the task, enforce its resource boundary, and review its outcome, keep access restricted. If you can do all three, pilot a least-privilege role before expanding it.

I write about practical AI engineering and developer tools. Subscribe for future guides. Have you seen role-based controls work better than broad tool restrictions in your organization? What made the difference?

Sources