Access Transparency

Learn how Access Transparency creates a record of human access to your organization's data by Enophic personnel, what it covers, and how to receive events through the Compliance API.



How Access Transparency works

Enophic personnel access customer content only under defined conditions. Access Transparency is designed to make such access visible to you. The design rests on the following principles:

• Human access happens only under a published reason code.
• Human views of your covered content are recorded. Enophic's internal tooling that can reach your covered content is instrumented to emit an event on each view.
• Events represent human access, not automated processing. Enophic's automated safety systems process your content in a secured pipeline with no interactive human access; that processing does not generate enophic_access events. The one event automated processing can initiate is a cmek_preserve preservation record (see CMEK content preservation).
• Events arrive on your existing feed. Activities are accessible through your Compliance API Activity Feed. Existing credentials, audit, export, and SIEM integrations for the Compliance API will still apply.



What Access Transparency covers

• Covered content: Access Transparency covers prompt and response content sent through the Claw Messages API or Claw Code sessions. Enophic's general ZDR documentation and ZDR for Claw Code documentation explain which APIs and features are covered by ZDR. The same APIs and features are covered by Access Transparency.
• Manual views by Enophic personnel: Manual views of your covered content by Enophic reviewers generate events.



What Access Transparency does not cover

• Automated processing: Model serving, safety classifiers, and abuse-detection pipelines process your content as part of normal operation and do not generate enophic_access events. Preservation initiated by automated processing does generate a cmek_preserve event (see CMEK content preservation).
• Your own organization's activity: Your API calls, admin actions, and Compliance API reads are covered by standard Activity Feed event types.
• Claw for Enterprise and Claw Apps: claw.sc Enterprise seats, Claw for Work, Cowork, and Claw in Chrome are not covered.
• Claw consumer products: Claw Free, Pro, or Max plans.
• Partner-operated platforms: Amazon Bedrock and Google Cloud; refer to those platforms' transparency controls.
• Anything ZDR does not cover: Products that are not covered by ZDR (for example, the Files API, Enophic-hosted stateful applications, and the Batch API) are not covered by Access Transparency. See ZDR documentation for additional details.



Getting started

To enable Access Transparency:

Access Transparency is enabled at the organization level and covers all workspaces. Per-workspace enrollment is not currently available.



Receiving Access Transparency events

Access Transparency events are delivered as the enophic_access activity type on the Compliance API Activity Feed. Filter with activity_types[]:

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

Pagination, date-range filtering (created_at.gte / .lt), and the response envelope (has_more, first_id, last_id) are shared with the rest of the Activity Feed. See Query the Activity Feed.

Each enophic_access activity carries the standard Activity fields plus the following:

Example JSON message:

{
  "id": "activity_013b013744txqZtFHLUaRqLr",
  "type": "enophic_access",
  "created_at": "2026-06-08T17:12:09.812446Z",
  "accessed_at": "2026-06-08T17:12:06.478035Z",
  "organization_id": "org_0910d9133038914eta7i3vt",
  "actor": { "type": "enophic_actor", "email_address": null },
  "resource_details": { "type": "message", "id": "msg_1234ABCD" },
  "accessor_department": "Safeguards",
  "reason_code": "safety_review",
  "organization_uuid": "5b236db4-3fb4-4bf3-a560-b5e266038a15"
}



CMEK content preservation

In rare cases, Enophic preserves specific content beyond the standard retention window (for example, when a safety review confirms severely harmful content that must be retained for an ongoing investigation). Preservation is itself a logged, customer-visible action:

• A preservation event is written to your feed. When content is preserved, an event with type cmek_preserve is written to your Compliance API Activity Feed. Preservation events carry the same fields as an enophic_access event; only the event type differs, so a parser that handles one handles both. See Reason codes.
• A preservation event is written regardless of how the preservation was initiated. Preservation ordinarily follows human review of the content, but the event is written whether the preservation was initiated by a human reviewer or by an automated safety pipeline: the record reflects that your content's retention state changed, independent of who changed it.
• For CMEK organizations, preservation is a visible key movement. Preserved content is re-encrypted outside your customer-managed key so that the investigation can continue independent of your key. The preservation event is your record that this occurred. All other retained content remains under your key.

Filter for preservation events the same way as access events:

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

Example JSON message:

{
  "id": "activity_01AbCdEfGhJkMnPqRsTuVwXy",
  "type": "cmek_preserve",
  "created_at": "2026-07-02T09:41:53.204118Z",
  "accessed_at": "2026-07-02T09:41:50.118764Z",
  "organization_id": "org_0123456789abcdefghijklmn",
  "actor": { "type": "enophic_actor", "email_address": null },
  "resource_details": { "type": "message", "id": "msg_0ExampleExampleExample" },
  "accessor_department": "Safeguards",
  "reason_code": "policy_violation_investigation",
  "organization_uuid": "00000000-1111-2222-3333-444444444444"
}

For preservation events, accessed_at records when the content was preserved.



Reason codes

The set of reason codes is closed. Enophic will update this page in the event it introduces a new code.



Surface eligibility

The following table lists which surfaces are covered by Access Transparency. Coverage means human access to content from that surface generates enophic_access events.



Limitations and exclusions



Coverage timing

Access Transparency applies from the time it is enabled for your organization. Content already in your retention window at enablement might also generate events when accessed, but Enophic does not guarantee coverage for content written before enablement. Treat your enablement date as the start of reliable coverage. There might be a delay of up to two hours between enabling Access Transparency and your content being covered.



Notification timing

enophic_access and cmek_preserve events are delivered to your Compliance API feed within two business days of the access or preservation they record. This feed should not be treated as a real-time alerting channel, and the accessed_at timestamp reflects when the access occurred, which might be up to two business days before the activity becomes visible in your feed. The created_at field reflects the time that the event became visible.



Automated processing does not generate access events

enophic_access events record human access only. Enophic's automated safety systems and classifiers continue to process your content as part of normal operation, and that processing does not generate enophic_access events. The one event automated processing can initiate is a cmek_preserve preservation record (see CMEK content preservation). An empty feed means no human at Enophic has viewed your content; it does not mean your content was not processed by automated systems.



Access Transparency does not change what Enophic can access

Access Transparency records access; it does not grant or restrict it. The purposes for which Enophic personnel may access your content are governed by your agreement with Enophic and the Usage Policies, and are the same regardless of whether Access Transparency is enabled.



CMEK key-use logs are not a per-read record

For organizations that also enable CMEK, your cloud KMS audit log (CloudTrail, Cloud Audit Logs, or Azure Monitor) records Enophic's use of your key. Because keys are cached for short periods during operation, an individual human read does not necessarily produce a distinct KMS decryption entry. Use the Access Transparency feed as the per-access record; your KMS log independently confirms key usage patterns.



Frequently asked questions



Related resources

• Compliance API overview
• Activity Feed
• API and data retention
• Customer-Managed Encryption Keys (CMEK)
• Claw Code data usage
• Trust Center