{"slug": "role-based-access-vs-blanket-bans-for-ai-coding-agents-what-goldman-sachs-shows", "title": "Role-Based Access vs Blanket Bans for AI Coding Agents: What Goldman Sachs Shows", "summary": "Goldman Sachs restricted Anthropic's Claude Code and GitHub's advanced coding tools to engineers after an earlier period when bankers and traders could use them, Bloomberg reported on November 2, 2026, citing internal guidance updated in October. A Goldman spokesperson told Bloomberg that staff may experiment with certain tools to find suitable use cases, with the firm weighing productivity and risk management, and Fast Company noted an exception for quantitative \"strats\" employees. The reported policy illustrates a choice between role-based access and blanket bans for AI coding agents rather than a simple safety-versus-productivity tradeoff.", "body_md": "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.\n\nThat 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](https://news.bloomberglaw.com/tech-and-telecom-law/goldman-restricts-traders-and-bankers-from-using-some-ai-tools), [Fast Company](https://www.fastcompany.com/91636500/goldman-sachs-bans-non-engineers-from-using-advanced-ai-tools))\n\nThis 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.\n\nThe 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.\n\nNeither 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.\n\nA 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.\n\nIt 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.\n\nBut 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.\n\nThe 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.\n\nRole-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.\n\nFor example, a team could distinguish:\n\nThese 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.\n\nA permission model should answer at least four separate questions:\n\nA 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.\n\nModern 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.\n\nAnthropic'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](https://support.claude.com/en/articles/13930458-set-up-role-based-permissions-on-enterprise-plans))\n\nFor 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](https://code.claude.com/docs/en/settings))\n\nOpenAI'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](https://learn.chatgpt.com/docs/permissions), [Codex security cookbook](https://learn.chatgpt.com/docs/enterprise/security-cookbook))\n\nThat 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.\n\nInstead of starting with a company-wide yes or no, use three gates.\n\nWrite 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.\n\nIf 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.\n\nCheck 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.\n\nA 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.\n\nSet 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.\n\nIf you cannot determine what the agent did, what it could access, or who approved the result, the pilot is not ready to scale.\n\nUse this checklist before expanding access to another team:\n\nA 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.\n\nRole-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.\n\nThe 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.\n\nGoldman 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?\n\n**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.\n\nI 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?", "url": "https://wpnews.pro/news/role-based-access-vs-blanket-bans-for-ai-coding-agents-what-goldman-sachs-shows", "canonical_source": "https://dev.to/jamilxt/role-based-access-vs-blanket-bans-for-ai-coding-agents-what-goldman-sachs-shows-4nei", "published_at": "2026-11-10 03:09:45+00:00", "updated_at": "2026-11-10 03:20:55.546455+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "ai-policy", "ai-products"], "entities": ["Goldman Sachs", "Claude Code", "Anthropic", "GitHub", "Bloomberg", "Fast Company"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/role-based-access-vs-blanket-bans-for-ai-coding-agents-what-goldman-sachs-shows", "markdown": "https://wpnews.pro/news/role-based-access-vs-blanket-bans-for-ai-coding-agents-what-goldman-sachs-shows.md", "text": "https://wpnews.pro/news/role-based-access-vs-blanket-bans-for-ai-coding-agents-what-goldman-sachs-shows.txt", "jsonld": "https://wpnews.pro/news/role-based-access-vs-blanket-bans-for-ai-coding-agents-what-goldman-sachs-shows.jsonld"}}