[FEATURE] Per-team/per-group scoping for managed settings and remote-settings.json

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

remote-settings.json delivered via the Anthropic admin console applies org-wide with no segmentation. Every user in the organization receives the same hooks, deny rules, sandbox settings, permissions, and OTel configuration.

In practice, different teams have different risk profiles and need different policies:

• Platform/infra engineers need allowUnsandboxedCommands: true and broad Bash access for legitimate infrastructure work. Frontend developers should have tighter sandbox restrictions.
• Security team needs access to penetration testing tools that should be deny-listed for everyone else.
• Contractors or external collaborators should have stricter deny rules and more aggressive telemetry than full-time employees.
• Teams handling PII/financial data need additional deny rules for sensitive file patterns that don't apply to other teams.

Currently, the only option is to either set the policy to the lowest common denominator (most restrictive, blocking legitimate workflows) or to the most permissive level (under-protecting teams that should be restricted).

Proposed Solution

Support group/team-based scoping in the admin console and in remote-settings.json. Two possible approaches:

Option A: Named profiles in a single settings file

{
  "profiles": {
    "default": {
      "permissions": { "deny": [...] },
      "sandbox": { "allowUnsandboxedCommands": false }
    },
    "platform-team": {
      "permissions": { "deny": [...] },
      "sandbox": { "allowUnsandboxedCommands": true }
    },
    "contractors": {
      "permissions": { "deny": ["...extended deny list..."] },
      "hooks": { "...additional logging hooks..." }
    }
  },
  "assignments": {
    "platform-team": ["user1@company.com", "user2@company.com"],
    "contractors": ["contractor1@company.com"]
  }
}

Option B: Console-level group assignment

The Anthropic admin console gains a "Groups" or "Teams" concept where admins can:

1. Create named groups
2. Assign users to groups
3. Define settings overrides per group
4. Groups inherit from org-wide defaults and override specific fields

This mirrors how identity providers (Okta, Azure AD) handle policy assignment.

Priority

High - Significant impact on productivity

Feature Category

Configuration and settings

Use Case Example

A 60-person engineering org with 5 teams. The CISO wants:

• All teams: deny access to .env.prod, .pem, .key, force push to main
• Platform team (8 engineers): allow unsandboxed Bash, allow docker and kubectl commands
• Frontend team (15 engineers): deny Bash entirely except npm and node, strict sandbox
• Data team (10 engineers): additional deny rules for PII-containing directories
• Contractors (5 people): all of the above restrictions plus mandatory session logging hooks and no autonomous mode

Today this requires over-permissioning everyone or under-permissioning everyone.

Additional Context

Related but distinct from:

• #30715 — Flexible managed-settings hooks permissions (hook granularity, not team scoping)
• #35527 — Granular permission profiles (per-user permission modes, not per-team settings delivery)
• #30423 — Role-based skill profiles (skill scoping, not settings scoping)