Anthropic Enterprise RBAC
Overview
Anthropic provides organization-level access control through Workspaces, API key scoping, and member roles via the Console at console.anthropic.com.
Organization Structure
Organization (billing entity)
├── Workspace: Production
│ ├── API Key: sk-ant-api03-prod-main-...
│ ├── API Key: sk-ant-api03-prod-batch-...
│ └── Rate limits: Tier 4
├── Workspace: Staging
│ ├── API Key: sk-ant-api03-stg-...
│ └── Rate limits: Tier 2
└── Workspace: Development
├── API Key: sk-ant-api03-dev-...
└── Rate limits: Tier 1
Console Roles
| Role |
Capabilities |
| Owner |
Full access, billing, member management |
| Admin |
Manage workspaces, API keys, view usage |
| Developer |
Create/revoke own API keys, view own usage |
| Billing |
View invoices and usage reports only |
Application-Level RBAC
# Implement your own RBAC on top of Anthropic Workspaces
from enum import Enum
import anthropic
class UserRole(Enum):
VIEWER = "viewer" # Can read Claude responses (no direct API)
USER = "user" # Can send prompts (rate limited)
POWER_USER = "power" # Can use Opus, higher limits
ADMIN = "admin" # Can access all models, no limits
ROLE_CONFIG = {
UserRole.VIEWER: {"allowed": False},
UserRole.USER: {
"allowed": True,
"models": ["claude-haiku-4-20250514"],
"max_tokens": 512,
"rpm_limit": 10,
},
UserRole.POWER_USER: {
"allowed": True,
"models": ["claude-haiku-4-20250514", "claude-sonnet-4-20250514", "claude-opus-4-20250514"],
"max_tokens": 4096,
"rpm_limit": 60,
},
UserRole.ADMIN: {
"allowed": True,
"models": ["claude-haiku-4-20250514", "claude-sonnet-4-20250514", "claude-opus-4-20250514"],
"max_tokens": 8192,
"rpm_limit": 200,
},
}
def create_message(user_role: UserRole, model: str, **kwargs):
config = ROLE_CONFIG[user_role]
if not config["allowed"]:
raise PermissionError("Role does not allow API access")
if model not in config["models"]:
raise PermissionError(f"Role cannot access model: {model}")
kwargs["max_tokens"] = min(kwargs.get("max_tokens", 1024), config["max_tokens"])
client = anthropic.Anthropic()
return client.messages.create(model=model, **kwargs)
Key Management Best Practices
| Practice |
Implementation |
| One key per service |
prod-auth-service, prod-search-service |
| Rotate quarterly |
Calendar reminder + automated rotation |
| Least privilege |
Dev workspace for dev keys only |
| Audit trail |
Log which key made each request |
| Revoke immediately |
On employee departure or compromise |
Error Handling
| Issue |
Cause |
Fix |
| Key works in dev, fails in prod |
Wrong workspace key |
Verify key belongs to prod workspace |
| New team member can't access |
Not added to workspace |
Invite via Console > Members |
| Usage not visible |
Viewing wrong workspace |
Switch workspace in Console |
Prerequisites
- Obtain the organization owner’s approved workspace map, role matrix, service inventory, key owners, rotation schedule, and incident/revocation contacts.
- Create isolated dev/staging workspaces with synthetic requests; production changes require an approved change record and least-privileged service identity.
- Define the allowed models, token/rate budgets, data classes, destinations, and redacted audit fields for each role and service.
Instructions
- Map each human and service to the minimum Console role and workspace required for its job. Separate development, staging, and production keys; store them only in the approved secret manager.
- Enforce application RBAC before constructing a request, including model, token, rate, data-class, and destination checks. Treat unknown roles, stale memberships, and missing workspace mappings as deny.
- Test grants, denials, key rotation, revocation, and cross-workspace isolation with synthetic fixtures. Verify that audit records identify the actor and decision without recording prompts, responses, credentials, or personal data.
- Roll out policy changes to one sandbox workspace or internal canary. Require owner approval and review aggregate authorization failures, usage, and spend before production promotion.
- On suspected compromise or policy drift, revoke the affected key, disable the route, restore the last approved role policy, and document the redacted evidence.
Output
Produce an RBAC receipt containing policy/version, workspace and service classes, role decision counts, model/token/rate constraints, test and canary outcomes, key rotation/revocation status, approver, and rollback reference. Exclude key values, member emails, prompts, responses, and raw Console exports.
Examples
In a sandbox, assign fixture-service the user role, request a permitted Haiku call, and assert an Opus request is denied with decision=deny; reason=model_scope; prompt_logged=0. Rotate the synthetic service key, verify the old key is rejected, and record only the redacted receipt.
Resources
Next Steps
For major migration strategies, see anth-migration-deep-dive.
1---2name: anth-enterprise-rbac3description: Configure Anthropic enterprise organization management, Workspaces, and role-based access control for teams. Trigger with phrases like "anthropic enterprise", "claude rbac", "anthropic workspaces", "claude team access", "anthropic organization".4license: MIT5---6# Anthropic Enterprise RBAC
7
8## Overview
9
10Anthropic provides organization-level access control through Workspaces, API key scoping, and member roles via the Console at [console.anthropic.com](https://console.anthropic.com).
11
12## Organization Structure
13
14```
15Organization (billing entity)
16├── Workspace: Production
17│ ├── API Key: sk-ant-api03-prod-main-...
18│ ├── API Key: sk-ant-api03-prod-batch-...
19│ └── Rate limits: Tier 4
20├── Workspace: Staging
21│ ├── API Key: sk-ant-api03-stg-...
22│ └── Rate limits: Tier 2
23└── Workspace: Development
24 ├── API Key: sk-ant-api03-dev-...
25 └── Rate limits: Tier 1
26```
27
28## Console Roles
29
30| Role | Capabilities |
31|------|-------------|
32| Owner | Full access, billing, member management |
33| Admin | Manage workspaces, API keys, view usage |
34| Developer | Create/revoke own API keys, view own usage |
35| Billing | View invoices and usage reports only |
36
37## Application-Level RBAC
38
39```python
40# Implement your own RBAC on top of Anthropic Workspaces
41from enum import Enum
42import anthropic
43
44class UserRole(Enum):
45 VIEWER = "viewer" # Can read Claude responses (no direct API)
46 USER = "user" # Can send prompts (rate limited)
47 POWER_USER = "power" # Can use Opus, higher limits
48 ADMIN = "admin" # Can access all models, no limits
49
50ROLE_CONFIG = {
51 UserRole.VIEWER: {"allowed": False},
52 UserRole.USER: {
53 "allowed": True,
54 "models": ["claude-haiku-4-20250514"],
55 "max_tokens": 512,
56 "rpm_limit": 10,
57 },
58 UserRole.POWER_USER: {
59 "allowed": True,
60 "models": ["claude-haiku-4-20250514", "claude-sonnet-4-20250514", "claude-opus-4-20250514"],
61 "max_tokens": 4096,
62 "rpm_limit": 60,
63 },
64 UserRole.ADMIN: {
65 "allowed": True,
66 "models": ["claude-haiku-4-20250514", "claude-sonnet-4-20250514", "claude-opus-4-20250514"],
67 "max_tokens": 8192,
68 "rpm_limit": 200,
69 },
70}
71
72def create_message(user_role: UserRole, model: str, **kwargs):
73 config = ROLE_CONFIG[user_role]
74 if not config["allowed"]:
75 raise PermissionError("Role does not allow API access")
76 if model not in config["models"]:
77 raise PermissionError(f"Role cannot access model: {model}")
78 kwargs["max_tokens"] = min(kwargs.get("max_tokens", 1024), config["max_tokens"])
79
80 client = anthropic.Anthropic()
81 return client.messages.create(model=model, **kwargs)
82```
83
84## Key Management Best Practices
85
86| Practice | Implementation |
87|----------|---------------|
88| One key per service | `prod-auth-service`, `prod-search-service` |
89| Rotate quarterly | Calendar reminder + automated rotation |
90| Least privilege | Dev workspace for dev keys only |
91| Audit trail | Log which key made each request |
92| Revoke immediately | On employee departure or compromise |
93
94## Error Handling
95
96| Issue | Cause | Fix |
97|-------|-------|-----|
98| Key works in dev, fails in prod | Wrong workspace key | Verify key belongs to prod workspace |
99| New team member can't access | Not added to workspace | Invite via Console > Members |
100| Usage not visible | Viewing wrong workspace | Switch workspace in Console |
101
102## Prerequisites
103
104- Obtain the organization owner’s approved workspace map, role matrix, service inventory, key owners, rotation schedule, and incident/revocation contacts.
105- Create isolated dev/staging workspaces with synthetic requests; production changes require an approved change record and least-privileged service identity.
106- Define the allowed models, token/rate budgets, data classes, destinations, and redacted audit fields for each role and service.
107
108## Instructions
109
1101. Map each human and service to the minimum Console role and workspace required for its job. Separate development, staging, and production keys; store them only in the approved secret manager.
1112. Enforce application RBAC before constructing a request, including model, token, rate, data-class, and destination checks. Treat unknown roles, stale memberships, and missing workspace mappings as deny.
1123. Test grants, denials, key rotation, revocation, and cross-workspace isolation with synthetic fixtures. Verify that audit records identify the actor and decision without recording prompts, responses, credentials, or personal data.
1134. Roll out policy changes to one sandbox workspace or internal canary. Require owner approval and review aggregate authorization failures, usage, and spend before production promotion.
1145. On suspected compromise or policy drift, revoke the affected key, disable the route, restore the last approved role policy, and document the redacted evidence.
115
116## Output
117
118Produce an RBAC receipt containing policy/version, workspace and service classes, role decision counts, model/token/rate constraints, test and canary outcomes, key rotation/revocation status, approver, and rollback reference. Exclude key values, member emails, prompts, responses, and raw Console exports.
119
120## Examples
121
122In a sandbox, assign `fixture-service` the user role, request a permitted Haiku call, and assert an Opus request is denied with `decision=deny; reason=model_scope; prompt_logged=0`. Rotate the synthetic service key, verify the old key is rejected, and record only the redacted receipt.
123
124## Resources
125
126- [Console](https://console.anthropic.com)
127- [Workspaces](https://docs.anthropic.com/en/docs/administration/workspaces)
128
129## Next Steps
130
131For major migration strategies, see `anth-migration-deep-dive`.