The Compliance API Now Covers Cowork and Claude Code. Here Is the Audit Gap It Actually Closes.

Anthropic's Compliance API launched on May 21 with a specific, load-bearing promise: programmatic, per-event access to an organization's Claude activity, for the security and legal teams who have to answer 'who did what, and can you prove it' without deploying separate logging infrastructure for every surface. What it did not cover, for the nearly three months between launch and August 11, was two of the fastest-growing surfaces in the product: Cowork and Claude Code. A compliance team could pull a complete record of every claude.ai chat and still have no visibility into what happened in a Cowork session or a Claude Code run, the exact places where an agent is most likely to touch a filesystem, call a tool, or take an action with consequences.

On August 11, that gap closed. The Compliance API now covers Cowork across desktop, web, and mobile, and Claude Code in the CLI and desktop app, through the same endpoints and the same Compliance Access Key organizations already have provisioned. No new integration to build, no new key to request if compliance access is already enabled. That operational simplicity is real, and it is also exactly the kind of update that gets a one-paragraph changelog mention and nothing else, when the actual content, what these sessions expose and what they still do not, is worth sitting with for longer than a paragraph.

This is a direct update to Phase 4's audit trail requirement, the same way inference hooks was a direct update to Phase 4's PII filtering and CISO sign-off requirement two weeks earlier. The two releases are complementary, not overlapping, and understanding the difference between them is the actual practitioner content here.

What a Session Transcript Actually Contains

The new session endpoints return two things: full session content and session metadata. Content means prompts and responses, tool calls including MCP tool invocations, and any skills or artifacts the session produced, not a summary or an event log, the actual transcript. Metadata means the verified user ID and email, the organization ID, session and message IDs, and timestamps, the fields that let a retrieved transcript be tied to a specific person, a specific time, and a specific organizational context during an audit or an eDiscovery request.

That is a meaningfully richer return than what most teams built their original Compliance API integration around. A chat-only audit pipeline was already answering 'what did someone ask Claude and what did it say back.' A Cowork or Claude Code session, once retrievable, answers a harder and more consequential question: what did an agent actually do, across which tools, producing which artifacts, on whose authority. For any organization running MCP-connected use cases, the kind covered extensively in Phase 3, tool call content now shows up in the same retrievable transcript as the prompt that triggered it.

Local Sessions and Remote Sessions Are Not the Same Retrieval

The documentation draws a specific distinction worth carrying into any retrieval plan. Local sessions are Cowork and Claude Code running on a user's own machine, captured while they are signed in with their Claude Enterprise account. Remote sessions are Cowork sessions started on claude.ai web or mobile, which actually run in the cloud, in Anthropic-managed environments, not on the user's device at all. Both are retrievable through the same Compliance API. They are not retrievable under the same rate budget.

All Compliance API endpoints share a limit of 600 requests per minute per parent organization, and local session retrieval counts against that shared pool. Remote session retrieval carries a second, separate request budget on top of it. A retrieval pipeline built and load-tested against local sessions alone will behave differently, and can throttle unexpectedly, the moment a team's Cowork usage shifts toward the cloud-run remote sessions that Anthropic has been expanding access to throughout the summer.

What Is Still Out of Scope

Three explicit exclusions matter more than the coverage announcement itself. Claude Code on the web is not covered. Claude Code accessed through the Claude Platform, meaning direct API usage rather than the CLI or desktop app, is not covered. And none of this reaches sessions run on Amazon Bedrock, Google Cloud Vertex AI, or Microsoft Foundry, the three platforms an organization might be using specifically because Phase 1's platform decision landed on a cloud-native deployment rather than direct Anthropic API access.

That last exclusion is the one worth flagging hardest to a client mid-deployment. An organization that chose Bedrock in Phase 1, for entirely sound data-residency or existing-cloud-relationship reasons, gets none of this coverage expansion. The Compliance API, in its current form, is an Anthropic-direct-access feature. A hardening track that assumed 'the Compliance API covers our audit trail requirement' without checking which platform the organization actually deployed on has a documentation gap waiting to surface at exactly the moment a CISO's review packet gets built.

Where This Fits Next to Inference Hooks

Anthropic's own documentation draws the comparison directly, and it is the single most useful sentence in the release for anyone building a Phase 4 hardening track: inference hooks act inline, checking each governed prompt before inference and returning an allow or deny verdict in real time, while the Compliance API retrieves records after the fact and returns richer data than a real-time check could carry, including full non-text files and organization settings.

Those are two different jobs, not two versions of the same job. Inference hooks is the control that stops a bad request before it happens. The Compliance API is the control that proves, afterward, exactly what did happen, to an auditor, a regulator, or opposing counsel in a legal hold. A Phase 4 gate that has one without the other has real-time prevention with no evidentiary record, or a complete record with no ability to stop anything in the moment. Neither is a substitute for the other, and a CISO review packet should document both, not pick one.

What This Means at the Phase 4 Gate

Task 4.7 of the Phase 4 hardening track requires an audit trail that can answer who accessed what, through which tool, and what the model returned, for any given request, months after the fact. Before August 11, that requirement was only fully satisfiable for claude.ai chat traffic. An organization running MCP-connected use cases through Cowork or shipping Claude Code to engineering teams had a documented gap between what the audit trail covered and what the deployment actually did.

That gap is now closeable without new integration work, which is the kind of update that should trigger a quick, specific action: pull up the Phase 4 audit trail documentation for any deployment that already passed its gate, and confirm whether Cowork and Claude Code sessions were in scope when that documentation was written. If they were assumed out of scope because the Compliance API did not cover them yet, the documentation is now stale, not wrong. It described an accurate limitation that stopped being true on August 11.

What to Do Now

Three things are worth doing this week for any organization with an existing Compliance API integration. First, confirm the Compliance Access Key already provisioned actually has the scope for the new session endpoints, since coverage being included does not mean every existing key was issued with every scope. Second, update the retrieval plan to account for the local-versus-remote rate budget split before, not after, a retrieval job starts throttling during an actual audit or eDiscovery request. Third, revisit the Phase 4 audit trail documentation for any already-hardened deployment and note explicitly whether it now needs a one-line update to reflect that Cowork and Claude Code sessions are in scope.

For organizations still evaluating platform choice in Phase 1, this is also a data point worth weighing honestly: Compliance API coverage, including this expansion, is an Anthropic-direct-access feature. Bedrock, Vertex AI, and Foundry deployments do not inherit it. That does not make those platforms the wrong choice, Phase 1 has legitimate reasons to land there, but it does mean the audit trail strategy for a cloud-native deployment has to be built without assuming this specific capability will ever apply to it.