Platform Security

Anthropic Workspaces Security Model (Feb 2026): Workspace Isolation, Key Scoping, and the Gaps Operators Still Need to Plug

Anthropic spent February 2026 pushing the workspace boundary deeper into the Claude API: prompt caches moved from organization-level isolation down to per-workspace isolation, and the surrounding RBAC, spend-cap, and Compliance API surfaces got incremental polish. The model is materially better than it was. It is also incomplete in ways most teams have not audited.

By Austa · Published May 27, 2026 · ~12 min read

What changed in Feb 2026

Workspaces are not new. Anthropic launched the Workspaces feature in the Claude API Console on September 10, 2024, as an organizational primitive that grouped API keys, spend caps, and rate limits into named sub-containers within an organization. What shipped in February 2026 was not the container, but a tightening of what that container actually isolates. According to Anthropic's documentation, prompt caches on the Claude API, the Claude Platform on AWS, and Microsoft Foundry (beta) became isolated at the workspace boundary rather than the organization boundary, with an effective date documented as February 5, 2026 in the platform docs.

The shift sounds minor and is not. Before the change, two teams that lived in different workspaces inside the same organization could observe each other's cache hits when their prefixes matched. After the change, they cannot. This forecloses a cross-workspace side channel that was always more theoretical than practical -- the workspace boundary already enforced key scoping for files, batches, and skills -- but it brought caching in line with the rest of the model.

The Feb 2026 update did not unify isolation across all deployment channels. Amazon Bedrock and Google Vertex AI continue to scope prompt caches per organization (per AWS account or Google Cloud project, respectively). Any threat model that assumes "Anthropic workspaces isolate caches" without qualifying the deployment channel is wrong on Bedrock and Vertex. We have seen this misread in three audits already this year.

Workspace key scoping in depth

The unit of scoping is the workspace, identified by a wrkspc_ prefix (for example wrkspc_01JwQvzr7rXLA5AGx3HKfFUJ). Each organization may have up to 100 active workspaces; archived workspaces do not count. Every organization has a Default Workspace that cannot be renamed, archived, or deleted, and which surfaces with a null workspace ID in Usage API responses. This is more important than it sounds for audit work: any usage record that comes back with workspace_id: null is Default Workspace traffic, and Default Workspace cannot have its own spend or rate limit. Organizations that never created additional workspaces are running everything under a container they cannot constrain independently from the organization itself.

Three resource types are workspace-scoped: files created through the Files API, Message Batches created through the Batch API, and Skills created through the Skills API. A standard API key in workspace A cannot enumerate or read files, batches, or skills created with a key in workspace B. This is the strongest isolation guarantee the platform makes. It is enforced server-side; an attacker holding a leaked workspace key cannot widen its scope by manipulating headers, the way some API platforms historically allowed tenant escape through trailing parameters.

Three resource types sit at the organization level and are explicitly outside the workspace boundary. MCP tunnels (managed via a separate Tunnels API with an OAuth scope of org:manage_tunnels) cap at 10 active tunnels per organization, not per workspace. Workspace management itself runs through the Admin API and requires an sk-ant-admin key. Organization members and SCIM provisioning are also organization-scoped. None of these can be reached with a standard workspace key, but all of them are visible to any organization admin, which collapses the workspace boundary for that role.

Spend caps stack as a floor-and-ceiling pair. A workspace can set a monthly spend limit lower than the organization's limit, but never higher. If both are set, every request is evaluated against both; the lower value wins. This means a misconfigured organization-level cap will silently override workspace-level controls intended to enforce per-team budgets. We audit this by pulling both layers via the Rate Limits API and comparing them in a single sheet.

Rate limits follow the same pattern. Each workspace can carry its own requests-per-minute, input-tokens-per-minute, and output-tokens-per-minute limits per model tier, capped by the organization's limits. Notably, there is no first-class model allow-list at the workspace level. The practical model-access control is to set the rate limit for a given model tier to zero in workspaces that should not use it. This works but is awkward; it is one of the most common operator surprises.

Prompt-cache workspace isolation

The Feb 2026 change made workspace-level cache isolation the default on three of the five distribution channels. Anthropic states the cache key is partitioned per workspace, which means a cached prefix written by workspace A cannot be reused by a request from workspace B even if the prefix text is byte-identical. From an auditor's perspective, that closes the bench-mark cache-side-channel attack where one workspace probes for the presence of a sensitive prefix used by another workspace by measuring response latency and token-count signals from cache hits.

The control is not perfect. Two practical caveats apply. First, the isolation domain is the workspace, not the API key. Two API keys in the same workspace can still share cache entries with each other, which is documented and intentional, but worth understanding when one of those keys is held by a build pipeline and the other by a developer. Second, the deployment-channel asymmetry mentioned earlier means Bedrock and Vertex caches remain organization-scoped. If your stack uses both the direct Claude API and Bedrock for the same models, you are running two different cache isolation models in the same logical environment.

For workspace-internal threats -- a malicious insider with workspace-developer access running cache probes against the same workspace -- the cache is shared by design and probing is feasible. The mitigation is to keep highly sensitive prompts (those containing PII, secrets, or proprietary system prompts) in workspaces whose developer role is granted sparingly, not to assume the cache itself protects them.

RBAC: admin vs developer vs viewer

Workspaces expose five roles. The naming matters because the role string is what you grep for in Compliance API events.

Two inheritance rules collapse the model in practice. Organization admins automatically receive Workspace Admin on every workspace. Organization billing members automatically receive Workspace Billing on every workspace. Neither inheritance can be revoked without changing the organization-level role. This is the principal RBAC gap we flag during audits: an organization with five admins effectively has zero workspace isolation against those five identities. SOC 2 reviewers expect to see workspace-admin lists that are smaller than organization-admin lists, and that is structurally impossible in the current model.

There is no explicit Auditor role. The closest available role is Workspace User, which provides Workbench access but no key creation. For a security engineer who needs to read activity logs but not run inference, the practical path is to grant them Workspace User and provision Compliance API access at the organization level through an admin-issued Admin API key. This is not clean -- there is no read-only key type below organization admin -- and most teams we audit have not noticed it.

Cross-workspace key leak prevention

Anthropic's documentation states that API keys are scoped to a single workspace and cannot access resources outside it. Two practical aspects of this guarantee are worth pulling apart.

The first is server-side enforcement. We have not seen a public disclosure of a workspace-scoping bypass in the Claude API itself. A workspace key tested against another workspace's file or batch ID returns the same not-found response as for a non-existent ID, which is the desired behavior (no oracle on existence). The Admin API correctly rejects standard workspace keys, returning an authentication error before any workspace context is consulted.

The second is the local-environment surface, which the platform cannot defend. CVE-2025-59536 and CVE-2026-21852, disclosed by Check Point Research in early 2026, allowed Claude Code to issue API requests to an attacker-controlled ANTHROPIC_BASE_URL before showing the workspace trust prompt, exfiltrating the API key. Anthropic patched both by gating any network egress on the trust dialog. That mitigation depends on a current Claude Code version on the developer's machine. A workspace's own isolation guarantee is irrelevant if a key from that workspace was already leaked off the developer's laptop. The shared-responsibility line is clear: Anthropic owns the boundary; operators own the key custody.

Workspace keys do not carry source-IP enforcement, hardware binding, or short-lived OAuth alternatives at the standard-key tier. Workload Identity Federation exists, but only for organization-scoped org:manage_tunnels use today, not as a general workspace authentication option. Operators who want IP allowlisting need to put the key behind their own egress proxy and treat the proxy hostname as the canonical Anthropic endpoint.

Audit logging and SIEM integration

The Compliance API launched on August 20, 2025, on Enterprise plans, and is the supported path for SIEM integration. The endpoint is GET /v1/compliance/activities, returning structured events with microsecond timestamps, actor metadata (email, user ID, IP, user-agent), and one of 150-plus activity types across 35-plus categories. Concretely useful event types for workspace audit include admin_api_key_created, org_user_invite_accepted, workspace-mutation events, member role changes, and SSO sign-ins.

The current integration model is pull-based. There is no push, no webhook, and no streaming delivery. Documented connectors exist for Cribl, Datadog, Splunk, and Elastic, with Cribl Stream being the easiest path for teams that already standardize on it. An Anthropic blog post dated May 21, 2026 announced 28 additional partner integrations (Cloudflare, CrowdStrike, Palo Alto Networks, Microsoft Purview, Okta, Netskope, Fortinet, Wiz), most of which sit on top of the same Compliance API.

Two gaps to know. First, Claude.ai Cowork activity is explicitly excluded from the Compliance API. If your organization uses Cowork for end users, that surface needs separate handling. Second, the API has no per-request inference-payload logging. You can prove a key was used at a timestamp; you cannot reconstruct the prompt or completion. Teams that need prompt-level audit must implement it themselves at the egress-proxy layer.

Workspaces vs OpenAI Project Keys vs Google Cloud Vertex

The fairer comparison is Anthropic Workspaces against OpenAI Projects. Both are sub-organization containers added on top of an API platform that did not start with one. Anthropic's role model is slightly more granular (the Workspace Limited Developer role has no equivalent), and Anthropic's cache-isolation model is now slightly stricter where it applies. OpenAI's project-level model allow-list is more usable than Anthropic's rate-limit-to-zero workaround. Both expose pull-based audit feeds. Vertex is a different category: there is no API-key concept, the boundary is the GCP project, and IAM is doing the work that workspaces do for Anthropic.

Operators running multi-provider stacks should not assume one provider's controls translate. We have seen teams configure Anthropic with five workspaces (good) and then reuse a single OpenAI key across all five (bad), undoing the isolation they spent the prior quarter establishing.

The 7 controls operators still need to add on top

The platform model is a floor. Audit findings consistently surface the same seven controls that teams need to layer on themselves. None of them are exotic; all of them are missing in the average production Anthropic deployment we review.

1. Programmatic key rotation. Implement quarterly rotation through the Admin API. Generate a new key, deploy to the secret store, invalidate the old key. The Admin API supports this end to end; nothing in the platform forces rotation, so it has to live in your scheduler.
2. IP allowlists at an egress proxy. Workspace keys do not carry source-IP restrictions. Front the Anthropic API with a forward proxy (your existing one is fine), pin DNS, and treat any request that originates outside the proxy's egress CIDR as a leaked-key incident.
3. Request-rate alerting. Poll the Rate Limits API on a five-minute interval, alert on workspace-level utilization above 80 percent. Without this, the only signal of a leaked key being abused is the spend-cap firing, which is hours or days late.
4. Prompt-template signing. If your application sends templated prompts (system messages, tool descriptions, function schemas), hash the canonicalized template at deploy time and verify the hash in CI on every change. This catches upstream tampering that no platform-level control will catch, and it intersects directly with the threat model in our MCP server audit checklist; workspace-level controls are necessary but not sufficient.
5. Output-side DLP. Anthropic returns whatever the model produces. If your downstream tool surface includes ticketing, code execution, or outbound HTTP, run a DLP filter on completions before they hit those tools. The set of regexes and entropy checks you would use for human outbound email is a reasonable starting point.
6. Audit-log forwarding. Wire the Compliance API into your SIEM with the existing pull-based connector for your platform. Build dashboards on admin_api_key_created, role changes, workspace creation, and SSO sign-ins from unusual geographies. Many of the same patterns show up in our OWASP Top 10 for Agents analysis.
7. Incident playbook for leaked keys. A documented runbook: how to revoke a workspace key via Admin API, how to rotate dependent secrets, how to invalidate cached prefixes (Anthropic does not expose a cache-purge primitive, so the practical answer is to rotate the system prompt), how to retrieve Compliance API logs for the affected window, and how to scope blast radius across the workspace's files and batches. This belongs alongside the items in our LLM security checklist.

FAQ

What changed when Anthropic introduced Workspaces in Feb 2026?

Workspaces themselves shipped in September 2024 as an organizational container for API keys, spend caps, and rate limits. The Feb 2026 change moved prompt-cache isolation from the organization boundary down to the workspace boundary on the Claude API, the Claude Platform on AWS, and the Microsoft Foundry beta. The practical effect is that two workspaces in the same organization can no longer share or observe each other's cached prefixes. Bedrock and Vertex were not part of the change and still scope caches per organization.

Are API keys scoped per workspace or per organization?

Per workspace. Each standard API key is bound to a single workspace identified by a wrkspc_ prefix and can only access resources created in that workspace, including Files API objects, Message Batches, and Skills. Admin API keys, which start with sk-ant-admin, sit at the organization level and are required for workspace management itself. A leaked workspace key cannot reach across into another workspace's cached prefixes, files, or batches, but it has full access within its home workspace.

Does prompt caching now isolate properly across workspaces?

On the Claude API, Claude Platform on AWS, and Microsoft Foundry beta, prompt caches have been isolated at the workspace level since the Feb 2026 update. On Amazon Bedrock and Google Vertex AI, prompt caches remain isolated at the organization level, so two Bedrock workloads under the same AWS account can still observe each other's cache hits. Any threat model that assumes cache isolation everywhere should explicitly check the deployment channel. Inside a single workspace, two keys still share the cache by design.

What RBAC roles are available in Anthropic Workspaces?

Five roles per workspace: Workspace User (Workbench only), Workspace Limited Developer (manage keys, use API, no session tracing or file download), Workspace Developer (manage keys, use API), Workspace Admin (full settings and member control), and Workspace Billing (inherited from the organization billing role, not assignable). Organization admins automatically receive Workspace Admin on every workspace, which is the most consequential gap in the model. There is no Auditor or Read-Only Security role distinct from Workspace User.

Can I forward Anthropic audit logs to my SIEM?

Yes, through the Compliance API launched in August 2025 for Enterprise plan customers. Cribl, Datadog, Splunk, and Elastic all have documented connectors, and Anthropic announced 28 additional partner integrations in May 2026. The GET /v1/compliance/activities endpoint returns structured events including admin_api_key_created, org_user_invite_accepted, and workspace mutations with microsecond timestamps and actor metadata. Console-side Claude.ai Cowork activity is explicitly excluded, and there is no push or webhook delivery, so SIEM ingestion is pull-based.

How does Anthropic Workspaces compare to OpenAI Project Keys?

Both bind keys to a sub-organization container with independent spend caps and rate limits. OpenAI Projects expose per-project model allow-lists more directly; Anthropic Workspaces do not expose a first-class model allow-list, relying on rate limits per model tier as the practical control. Both forward activity logs to SIEMs through pull APIs. Google Vertex is a different model entirely, leaning on Google Cloud IAM and Workload Identity Federation rather than a sub-organization scope. Multi-provider stacks should not assume controls translate; configure each platform on its own terms.

What controls do operators still need to add on top?

Seven gaps recur in audit reports. Programmatic key rotation through the Admin API, IP allowlists at an egress proxy because Anthropic does not enforce source IP on keys, request-rate alerting wired to the Rate Limits API, prompt-template signing or hashing to detect upstream tampering, output-side data-loss prevention before responses hit downstream tools, audit-log forwarding into the existing SIEM, and a documented incident playbook for the leaked-key scenario. All are operator-side; none are provided by the platform.

Has any workspace-isolation bypass been disclosed?

No bypass of the workspace boundary itself has been publicly disclosed as of May 2026. CVE-2025-59536 and CVE-2026-21852, reported by Check Point Research in early 2026, allowed Claude Code to exfiltrate API keys before showing the trust prompt when launched in an attacker-controlled repository. That is a key-theft vector, not an isolation bypass, but a stolen workspace key still gives the attacker full read and write inside that workspace. Anthropic patched the Claude Code issues; the broader lesson is that operator-side key custody sits outside the platform boundary.

Related reading

• Auditing MCP servers in 2026 -- the workspace boundary does not protect you from tools the agent is allowed to call.
• OWASP Top 10 for Agents 2026 -- platform isolation is one row in a longer threat model.
• LLM security checklist 2026 -- where workspace controls sit in a defense-in-depth posture.