Anthropic Claude Workspace User Permissions Explained

If you're setting up Claude for a team, you've probably hit the question: who in your Anthropic Workspace can do what? Anthropic's Console gives you a handful of roles — Primary Owner, Owner, Developer, Billing, and User — and each one controls access to API keys, billing, usage data, and workspace settings differently. Getting this wrong either locks your engineers out of what they need or hands billing access to people who shouldn't have it.

This article walks through what each Anthropic Workspace role actually permits, where the model falls short for teams building products on top of Claude, and how to layer proper per-application access control on top using an API gateway like SubToAPI.

Anthropic Workspace Roles, Explained

Anthropic organizes permissions at two levels: the Organization and the Workspace. A Workspace is a sub-container inside your Organization where you group API keys, usage, and members for a specific team or project.

• Primary Owner — one person per organization, full control over billing, members, and workspace creation. Cannot be removed by anyone else.
• Owner — can manage workspace membership, create and revoke API keys, and view usage within that workspace. Cannot touch organization-level billing unless also granted that separately.
• Developer — can create and manage API keys within a workspace, view usage, but cannot manage members or delete the workspace.
• Billing — read access to invoices and spend, no access to API keys or prompts.
• User — can view workspace resources but cannot create or revoke keys.

Permissions are assigned per workspace, not globally, which is useful if you run multiple products or environments (staging, production, client A, client B) under one Anthropic account. You move members between workspaces, and each workspace has its own API keys and spend limits.

What This Model Does Well

For internal governance, this is reasonable. You can isolate a staging workspace from production, give your billing lead read-only access to invoices without exposing prompts, and let a tech lead rotate keys without giving them organization-wide control. It maps cleanly onto how most teams think about environments.

Where It Falls Short for Product Teams

The gap shows up once you're not just using Claude internally but building a product that other people — customers, contractors, other internal apps — need to call through an API.

1. No per-application scoping. An Anthropic API key tied to a workspace can call every model and every endpoint that workspace is allowed to use. There's no built-in way to say "this key can only be used by the billing microservice" or "this key expires in 30 days." You either share one key broadly or create workspaces just to separate keys, which gets unwieldy fast.

2. No usage breakdown by consumer. Anthropic's usage dashboard reports at the workspace and key level. If five different internal apps share a workspace, you can't easily tell which one is driving token spend without adding your own logging layer.

3. No native streaming or tool-use management for external consumers. If you're exposing Claude functionality to customers through your own product, Anthropic's Console roles don't give you any way to issue scoped, revocable credentials to those customers. You'd be building that layer yourself — key issuance, rate limiting, usage metering — from scratch.

4. Role granularity stops at five options. There's no custom role creation, no attribute-based access control, and no way to restrict a Developer role to specific tools or specific model versions.

Adding a Scoped API Layer on Top

This is the gap SubToAPI is built to close. Instead of handing out raw Anthropic keys, you issue sub_live_... application keys from a dashboard, each one scoped to a specific app, environment, or customer. You keep your underlying Claude access centralized, but every consumer gets its own revocable credential with its own usage metadata.

Practically, this means:

• Your frontend team gets a key scoped to the chat feature.
• A contractor gets a key that expires after the project ends.
• Each customer-facing integration gets its own key so you can see exactly how much it's costing you.

Issuing a request looks the same as calling Claude directly, just pointed at SubToAPI's endpoint:

curl https://api.subtoapi.app/v1/messages \
  -H "Authorization: Bearer $SUBTOAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-sonnet-4-5",
    "max_tokens": 1024,
    "messages": [
      {"role": "user", "content": "Summarize this changelog."}
    ]
  }'

Because each key is scoped per application, you get the equivalent of Anthropic's Developer role but applied at the application level instead of the workspace level — without needing to fragment your Anthropic Workspace into dozens of sub-workspaces just to isolate keys. Team plans add seats so multiple people can manage keys from one dashboard, closer to how Workspace roles work today but with finer-grained control over what each key can touch.

See the docs and quickstart for the full request/response shape, or check streaming and tool use if your application needs either.

Setting This Up in Practice

A reasonable split for most teams:

1. Use Anthropic Workspace roles for your internal governance — who can see billing, who can provision workspaces, who manages the organization.
2. Use a scoped key layer like SubToAPI for every actual application, script, or customer-facing feature that calls Claude. This is where usage tracking, revocation, and per-app isolation matter most.
3. Rotate and audit application-level keys regularly, independent of your Anthropic Console role assignments.

This keeps your Anthropic account lean — fewer workspaces, fewer shared keys — while giving you the granular control that product development actually needs. Check pricing or start a free trial at signup if you want this scoping layer without building it yourself.

Questions

Can I create custom roles in an Anthropic Workspace? No. Anthropic currently offers five fixed roles — Primary Owner, Owner, Developer, Billing, and User — with no custom role or permission editor.

Do Workspace permissions apply across my whole organization? No, permissions are assigned per workspace. A member can hold different roles in different workspaces within the same organization.

How do I give different applications different access levels to Claude? Anthropic's roles don't support this natively. A scoped API layer like SubToAPI issues separate, revocable keys per application with individual usage tracking, sitting on top of your existing Claude access.