How to Audit Claude with the Compliance API

Anthropic launched the Compliance API on August 20, 2025 as part of a broader Enterprise admin push. The pitch is that compliance teams stop relying on manual CSV exports and start streaming audit events into the SIEM the same way they do for Okta, Workday, or GitHub Enterprise. Real-time monitoring, programmatic deletion, scripted DSAR fulfillment.

Most of that is true for Claude.ai chat and the Claude API. For Cowork, the highest-risk surface in the Anthropic product line, almost none of it is true. That second sentence is the entire reason this post exists.

We covered the Cowork side of the problem in How to Secure Claude Cowork, which focuses on the on-device proxy and policy layer. This post is the audit-side companion. What you actually get from the Compliance API, where the gaps are, and how the three telemetry layers fit together. For the product-level decision framework on which Anthropic surface fits which workload, see Claude Cowork vs Claude Code; for the parallel threat model on the agent's tool layer, see MCP Server Security.

What's In The Box

The Compliance API is two products bolted into one feature.

The first is a programmatic audit-event feed: roughly 30 typed events that cover identity, organization configuration, project lifecycle, conversation lifecycle, and file uploads. Same event shape as the existing audit log export, same 180-day retention window, queryable instead of downloadable. This is the part that closes the "we have no SIEM coverage for Claude" gap.

The second is on-demand access to chat data and file content for a specific conversation or file, plus selective deletion. This is the part that operationalizes GDPR Article 15 and Article 17 work. You can write a script that takes a user identifier, finds every conversation that user touched, returns the content, and on confirmation, deletes it. The audit log export cannot do that. The Compliance API can.

Two things to know up front.

First, the actual endpoint URLs, parameter names, and response shapes are not on the public help center. They live in a PDF that appears after a Primary Owner enables the API in Organization settings → Data and privacy. Several third-party writeups describe production access as NDA-gated, which matches what we have heard from customers. The console toggle is real, and so is the account-team conversation. Plan for both.

Second, this is Enterprise only. Public Sector organizations are explicitly excluded. Team plans get audit log access but not the Compliance API. If you are evaluating Claude on Team and assuming you can graduate into compliance later, the upgrade is real and not free.

The Audit Event Feed

Anthropic's audit log documentation is the canonical reference for the event taxonomy and schema. The Compliance API exposes the same events programmatically. Every event carries:

The event taxonomy splits roughly like this:

Read that list once and notice what is missing. Nothing about which prompts ran. Nothing about which model was invoked. Nothing about what tools Claude called or what those tools returned. No record of MCP server traffic. No sub-agent traces. The audit feed is a record of identity, configuration, and resource lifecycle. It is not a record of what Claude did with that resource once a conversation was open.

That is consistent with how every other major SaaS audit log works. It is also why the second half of the API exists.

The Content Side

The Compliance API's content endpoints let you pull the actual chat data and file content for a specific resource you already identified through the audit feed or through your own search. Selective deletion works the same way, scoped to a single resource at a time.

This is the part of the API that earns its keep for compliance work. Three concrete uses:

GDPR Article 15 (right of access). A subject-access request comes in from an EU user. You query the audit feed for every conversation_* and file_uploaded event tied to their identity, pull the content for each one, package it, and ship it back. The whole thing is scriptable. The export-only path requires a manual download and human-eyeball filtering.

GDPR Article 17 (right to erasure). Same flow, except the last step is a delete call instead of a packaging step. The API gives you per-resource deletion, which is what a defensible erasure workflow needs. Bulk admin deletion is not the same thing; auditors want to see scoped, logged deletes that match a specific request.

HIPAA §164.312(b) audit controls. "Who saw what PHI when" requires reconstructing access by user. The audit feed gives you who created and accessed which conversation. The content endpoints give you what was in it. Together, they produce evidence a HIPAA auditor will accept for Claude.ai chat and the Claude API. Cowork is a different conversation; we will get to that.

The selective-deletion endpoint is also why the API is a real upgrade over the export. CSV export gives you visibility. The API gives you action.

Three Layers Of Telemetry

A production Anthropic deployment generates telemetry at three different layers, and each layer covers a different surface. Understanding which one covers what is the difference between an audit story that works and one that has holes nobody notices until the auditor finds them.

The Compliance API is necessary and not sufficient. OpenTelemetry is informative and not authoritative. The proxy is enforceable and partial. You need all three.

The matrix is the most important thing to internalize from this post. If you walk away with one image, make it that one.

OpenTelemetry Is A Separate Product

The biggest source of confusion we see is treating OpenTelemetry and the Compliance API as the same kind of thing. They are not. They have different scopes, different defaults, and different compliance weight.

Anthropic ships OTel for Claude Code and, separately, for Cowork. Both export the standard OTel signals: metrics as time series, events via the logs and events protocol, optional distributed traces. Both share a prompt.id attribute that ties every event back to the user prompt that triggered it. That correlation key is genuinely useful. It is also why OTel is good for incident investigation and bad for compliance evidence: it is event-shaped operational data, not a schema-stable audit record.

The defaults differ in ways that matter:

The prompt-content default is the one most likely to surprise an enterprise team. Code OTel is conservative; Cowork OTel ships sensitive content in plaintext to whatever OTLP endpoint you configure. That is fine if your endpoint is a hardened SIEM with PII handling, and it is a problem if it is a developer-grade observability vendor with broader access. Decide which one you are running before you save the config.

The crucial line in Anthropic's own Cowork OTel doc: "OpenTelemetry is not a replacement for audit logging. Cowork activity isn't currently captured in audit logs, the Compliance API, or data exports."

Read the second sentence twice. Then keep reading.

The Cowork Gap

Here is what is, and is not, in the audit feed for Cowork as of writing:

That last row is the one that breaks compliance programs. The conversation log itself is on the user's laptop. There is no centrally exportable record. If the user wipes their machine, or never gets backed up, the conversation is gone. That is fine for personal use. It is not fine if you need to produce a record on demand.

Two consequences follow.

First, you cannot rely on Anthropic for Cowork audit. Even with the Compliance API enabled, the Cowork columns of the matrix above are dark. The audit story has to come from your own infrastructure: an on-device policy proxy, an MCP gateway, endpoint telemetry, the Cowork OTel stream piped to a SIEM you control. None of those are optional if Cowork is in scope.

Second, the network controls you get for free are weaker than they look. Anthropic ships Cowork with a hardcoded egress allowlist (api.anthropic.com, pypi.org, github.com, npmjs.org) for code execution, but Harmonic's Cowork guide notes that web search bypasses these restrictions entirely. The default Chrome blocklist covers banking, crypto, adult content, and pirated content. Healthcare and internal tools are not blocked by default. Enterprise ships with Chrome disabled. Team ships with Chrome enabled. If you rolled out Cowork on Team without changing defaults, your users have an authenticated browser agent right now, and there is no audit trail for what it does.

The honest summary: the Compliance API turns Claude.ai chat and the Claude API into a SaaS application your security team can audit normally. It does not change anything about Cowork. The two products live on the same admin console and have completely different compliance postures.

SOC 2, HIPAA, GDPR

Mapping the API to specific frameworks. We are not lawyers, and your specific control mappings will vary, but the high-level story is consistent across the customers we have seen.

SOC 2 CC6.1 / CC6.6 (logical access). Audit-event coverage of SSO, role changes, invitations, and JIT toggles closes the basic access-control evidence requirement for Claude.ai. The export covered this manually. The API closes it continuously, which is what most CC7.2 monitoring requirements want anyway.

SOC 2 CC7.2 (system monitoring). Streaming the audit feed into a SIEM with alerting on anomalous events (org_sso_toggled outside change windows, mass org_user_invite_sent, unexpected org_data_export_started) is the canonical way to satisfy this for Claude.ai. Cowork does not have a streamable equivalent.

HIPAA §164.312(b) (audit controls). For Claude.ai chat, the audit feed plus content endpoints reconstruct who accessed what. Cowork conversations contain PHI on a user's local disk by design. There is no audit trail Anthropic can hand you. The conservative posture is to keep PHI out of Cowork until that changes.

GDPR Article 15 (right of access). Scriptable through the content endpoints. Build a small DSAR worker that takes a subject identifier, walks the audit feed, fetches every referenced resource, packages, sends. We have seen working implementations in under a day of engineering for the Claude.ai surface.

GDPR Article 17 (right to erasure). Same flow with a delete instead of a fetch at the end. The API logs every selective deletion as its own event, which is the audit trail the regulator will ask for. The export-only path cannot prove this.

ISO 27001 A.8.15 (logging). Same answer as SOC 2. Audit feed for Claude.ai. No equivalent for Cowork.

The summary in one line: the Compliance API is a real compliance product for Claude.ai and the Claude API, and a non-product for Cowork.

A Rollout Sequence

If you are turning this on next week, the order of operations matters.

Week 1, scoping. Identify which Claude products your org actually uses. Most will use Claude.ai, some will use the API directly, a smaller subset will have Code or Cowork enabled. The audit story for each is different, and you need that map before you start ingesting data.

Week 1, enablement. Have the Primary Owner toggle the Compliance API in Organization settings → Data and privacy and create access keys. Open the gated PDF and read it end-to-end before writing any client code. Loop in your account team if production access requires the NDA review.

Week 2, ingestion. Stand up a worker that pulls audit events into your SIEM. Start with a polling cadence that matches your existing SaaS audit feeds (every 1–5 minutes is typical) and a 7-day backfill window for sanity checking. Treat access keys as production secrets; rotate on the same schedule as your other admin credentials.

Week 2, alerting. Build the obvious alerts first. SSO toggles, JIT toggles, mass invitations, data exports outside change windows, role escalations. None of these are Claude-specific; they are the same alerts you have for every other SaaS admin surface, applied to a new feed.

Week 3, content workflows. Wire the content endpoints into your DSAR tooling. Test the deletion path on a non-production user. Make sure the deletion event lands in the audit feed and your SIEM picks it up. This is the loop that proves Article 17 works.

Week 3, OTel for Code and Cowork. Configure managed OTel settings through MDM for Code (env vars in ~/.claude/settings.json or equivalent) and through the admin console for Cowork. Pipe both into the same SIEM as the audit events. You now have the operational layer.

Week 4, the proxy layer. This is the part the Cowork post covers. On-device proxy or LLM gateway, policy on the network and tool path, real-time decisions on egress. Without this layer, Cowork has no audit story at all. With it, you have a working enforcement point even though Anthropic does not give you a centralized record.

Week 5, gap acceptance. Document, in writing, what is and is not covered. The Cowork rows of the coverage matrix are the part that needs explicit risk acceptance from your compliance and legal teams. If they will not sign, do not run regulated workloads on Cowork. The Compliance API does not change that calculus.

Things The Public Docs Do Not Make Obvious

A few details we have learned the hard way.

The audit log retention is 180 days, per the canonical Anthropic help center page. Some third-party writeups quote 30 days. Trust the canonical page; the 30-day number is wrong.

The audit feed does not include the title or content of conversations or projects. Only their identifiers. If you need the title, you have to pull the resource through the content endpoints. This trips up SIEM rules that try to alert on conversation names.

client_platform is the field that distinguishes Claude.ai web from desktop from API. If you only run Claude.ai chat, you can ignore it; if you run all three, it is what you group by to attribute events to the right surface.

The content endpoints are per-resource, not bulk. There is no "give me everything for user X" call. You walk the audit feed for that user and pull each resource individually. This makes DSAR work doable but not free; budget engineering time accordingly.

Selective deletion is logged as its own event. That is the property that makes it audit-grade. If your compliance program treats deletion as a controlled action, the resulting org_data_export_completed-style record is what the auditor will look for.

OAuth-mediated admin keys for the Compliance API are scoped to the org, not to a specific human. Treat them like service-account credentials. Rotate, vault, and audit access to the key store itself. We have seen one customer leave a Compliance API key in a Slack DM. Do not be that customer.

The Bottom Line

The Compliance API is the most important thing Anthropic has shipped for enterprise governance, and it solves about half of the actual problem.

For Claude.ai and the Claude API, it turns Claude into an auditable SaaS application: continuous monitoring, scriptable DSAR, real-time policy alerts. The export-only era is over for those surfaces. SOC 2, HIPAA, GDPR, and ISO 27001 control evidence becomes tractable. If you have been waiting to graduate Claude into a regulated environment because the audit story was too thin, the wait is largely over for those products.

For Cowork, nothing has changed. Cowork remains excluded from audit logs, the Compliance API, and data exports. Conversation history sits on user laptops. File reads, browser actions, MCP calls, and scheduled tasks generate no centralized record. The Cowork OTel stream is operational telemetry by Anthropic's own definition, not audit evidence. Until Cowork events ship into the Compliance API, regulated workloads do not belong on Cowork, and the only durable enforcement point is an on-device proxy or LLM gateway you operate yourself.

A complete audit story for an enterprise Anthropic deployment in 2026 has three layers: the Compliance API for the control plane, OpenTelemetry for the agent operational plane, and an on-device proxy or LLM gateway for the network and tool plane. Run all three or you have holes. Treat the Cowork rows of the coverage matrix as risk to accept in writing or as a reason to keep Cowork out of the regulated path. The single biggest mistake we see is treating "we enabled the Compliance API" as a finished compliance story. It is half a story. The other half is the part this post and the Cowork post describe.

We Built The Other Half

The Compliance API closes the audit story for Claude.ai and the Claude API. General Analysis closes the audit story for everything else: an on-device proxy and LLM gateway that intercept agent traffic, run hyper-fast policy guards, record telemetry, enforce on browser-use and computer-use, govern MCP servers, and produce the audit trail Cowork does not. We did the implementation work needed to keep this usable: blocking risky actions without adding meaningful latency or breaking the agent UX that makes Cowork useful in the first place.

Book a demo to see what Cowork audit and enforcement looks like when you do not have to wait for Anthropic to close the gap.