Claude Access Transparency Compliance API: What Enterprise Operators Must Know Before the First cmek_preserve Event Arrives

Every enterprise operator running AI workloads on sensitive data faces the same governance question: when Anthropic reviews content, will you know? With the July 10 expansion of the Claude Access Transparency documentation — adding cmek_preserve reason codes, a filter example, and clarification that automated pipelines can trigger preservation events — the answer is now definitively yes, as long as you have the Compliance API wired up before that first event arrives.

This is not a new capability. Access Transparency has existed on the Anthropic platform for some time. What changed in July is the documentation depth: two new cmek_preserve reason codes (policy_violation_investigation and csae_report), an example event payload, and explicit clarification that preservation can be triggered by automated safety pipelines, not just human reviewers. For any operator who hasn't yet integrated this into their audit stack, the expanded docs are the signal to act now.

What happened

Anthropic expanded the Access Transparency reference page with three material additions for operators:

Two new cmek_preserve reason codes. The existing reason-code table now includes policy_violation_investigation (content preserved during a Trust and Safety investigation) and csae_report (content preserved as evidence for a child safety report). The previously documented codes — safety_review and incident_response — still apply to anthropic_access events. The preservation codes apply exclusively to cmek_preserve events.

Clarification on automated pipeline triggers. The docs now explicitly state that a cmek_preserve event is written "whether the preservation was initiated by a human reviewer or an automated safety pipeline." This is a meaningful change for operators whose threat model assumes that a lack of human access events means zero Anthropic-side activity on their data. An empty anthropic_access feed is not the same as no content review — automated classifiers run on traffic and can independently trigger preservation without generating an anthropic_access event first.

A filter example and example payload for cmek_preserve events. Operators can now query:

curl --fail-with-body -sS -G \
  "https://api.anthropic.com/v1/compliance/activities" \
  --data-urlencode "activity_types[]=cmek_preserve" \
  --data-urlencode "limit=50" \
  --header "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY"

The event payload mirrors an anthropic_access event — same fields, different type value — meaning any parser built for access events handles preservation events without modification.

Why it matters for AI engineering teams

Enterprise operators routing AI API traffic through Claude need to treat anthropic_access and cmek_preserve as two distinct but complementary signals:

• anthropic_access = a human at Anthropic viewed your content, under a named reason code, in your retention window.
• cmek_preserve = your content's encryption state changed; content was re-encrypted outside your CMEK key, extending its retention beyond your standard window.

The second event is the one with direct compliance implications. For regulated industries — healthcare (HIPAA), financial services, legal — a cmek_preserve event signals that content that was supposed to rotate out of retention has been held. That is a material data-lifecycle event that your compliance and legal teams need to know about, often within 72 hours under frameworks like GDPR.

The two-business-day delivery window documented by Anthropic means this feed is not a real-time alerting channel. It is an audit record. Configure any SIEM lookback windows or scheduled exports to match: a 48-hour lookback on a daily export schedule will miss events; a 7-day lookback will not.

The router/operator angle

For teams running AI gateways that proxy Claude API traffic, Access Transparency introduces two operational considerations:

Logging the msg_id for joinability. The anthropic_access and cmek_preserve events carry resource_details.id, which is the msg_... ID from the Messages API response. If your gateway does not log this ID alongside your internal request metadata (user ID, tenant, workflow), the event tells you that access occurred but not which downstream application, user, or conversation was involved. This is a gap in most gateway logging setups — fix it before you enable Access Transparency, not after.

Surface coverage gaps in multi-provider stacks. Access Transparency covers api.anthropic.com traffic and Claude Code sessions using an API key. It also covers Claude Platform on AWS. It does NOT cover Amazon Bedrock, Google Cloud Vertex AI, Microsoft Foundry, or the Batch/Files APIs. Operators running a multi-provider routing stack that distributes traffic across both api.anthropic.com and Bedrock need separate transparency mechanisms for each path. Bedrock traffic falls under AWS CloudTrail for key usage and AWS service controls for access — not the Anthropic Compliance API.

Cost and eligibility. Access Transparency is not self-serve. It requires contacting your Anthropic account representative and meeting eligibility criteria defined in your contract terms. For teams without an enterprise contract, this feature is out of reach. This also means that AI gateway vendors who offer managed Claude routing without enterprise contracts cannot provide this audit layer to their customers — a governance gap worth factoring into build-vs-buy decisions.

What TheRouter users should watch or try

If your organization is evaluating or actively using Claude API traffic through a routing gateway, the action items from this documentation update are:

1. Confirm whether Access Transparency is enabled for your org. Contact your Anthropic account representative if you have an enterprise contract and haven't enrolled.
2. Add msg_id logging to your gateway. Log the id field from every Messages API response body alongside your internal request metadata. Without this, future audit events are hard to trace to a specific workflow.
3. Configure Compliance API polling with a 7-day lookback. Don't rely on real-time event delivery — treat the feed as a delayed audit log and set your SIEM integration accordingly.
4. Separate anthropic_access and cmek_preserve alert thresholds. An access event warrants review; a preservation event may require legal notification depending on your data-processing agreements.
5. Audit your multi-provider routing coverage. If you route traffic to both api.anthropic.com and Bedrock, you need separate audit mechanisms. TheRouter's provider routing policy can help you tag and separate these traffic streams for downstream compliance reporting.

For teams exploring AI routing governance, this feature represents the emerging norm: providers building observable, auditable data-access layers that give enterprise operators a verifiable record of how their data is handled.