Anthropic Compliance API: audit persistent instructions without building a shadow prompt database

Anthropic's Compliance API can now return the persistent text that current Claude Enterprise members saved as Instructions for Claude and as Cowork Global instructions. The new beta endpoint matters because those account-level instructions can quietly shape answers and agent behavior across organizations. Security, compliance and AI platform teams can now inventory that configuration—but should treat the returned text as sensitive user data, not as a convenient prompt database. The safe design uses a narrowly scoped collection job, encrypts only the minimum evidence needed, separates policy findings from raw text, and records every access.

Anthropic announced the endpoint on 15 October 2026 in the Claude Platform release notes. This article distinguishes the documented API behavior from engineering recommendations. The feature is beta and limited to eligible Claude Enterprise organizations; it is not a model capability and does not expose ordinary Claude API prompts.

What the endpoint actually returns

The documented request is GET /v1/compliance/organizations/{org_uuid}/user_preferences. The organization-data guide says each row identifies a current organization member and can contain two account-level values: conversation_preferences for Instructions for Claude in claude.ai, and cowork_global_instructions for Cowork. Because these settings belong to the account, the same text can appear under every organization that the member belongs to.

By default, the response contains only members who set at least one value. include_unset=true includes all current members and represents missing values as null. A request can target up to ten user IDs. Pagination uses limit and page; the default limit is 20 and the documented maximum is 100. The page token is opaque and must be passed back unchanged with the same filters. A short or empty page is not proof that traversal is finished—continue until next_page is null.

The endpoint requires read:compliance_user_data. A key without that scope receives 403. A normal Claude API key cannot call Compliance API endpoints. Anthropic's setup guide distinguishes Compliance Access Keys from Admin API keys and regular model API keys.

The decision points are straightforward. The endpoint is beta, so keep its parser behind a versioned adapter. Preferences are account-level, so deduplicate by stable user ID and content hash. A regular model key does not work, so compliance credentials need a separate trust boundary. One page does not prove completeness, so follow next_page until null. API workload prompts are outside this endpoint, so never call the inventory a complete AI prompt audit.

Define the audit objective before collecting text

There are at least three valid objectives, and they need different evidence.

First, a configuration inventory answers who has persistent instructions and when the organization last observed them. It may need only user ID, presence flags, a keyed content hash and observation time.

Second, a policy review checks for prohibited instructions such as requests to reveal secrets, bypass approvals, transmit regulated data or treat untrusted content as authority. That review may need temporary plaintext processing, a finding category and a human-review path—but it does not automatically justify long-term storage of every instruction.

Third, incident response may need exact text, chain-of-custody metadata and a legal hold. That is a different retention class with explicit authorization. Do not make the broadest incident-response dataset the default for routine inventory.

Collecting everything because the endpoint permits it creates a shadow prompt repository with a larger blast radius than the original setting. Data minimization is part of the architecture, not a later privacy checkbox.

Put collection behind a narrow trust boundary

The Compliance API setup documentation warns that read:compliance_user_data can read chats, files, projects, session transcripts, organization users, preferences and group membership across the key's coverage. Anthropic says to treat the key like a production database credential. It does not expire automatically, and deletion takes effect on the next request.

A production collector should therefore run in an isolated workload identity with outbound access only to the Compliance API and the approved evidence store. Keep the key in a secrets manager, never in source control, analytics configuration or application logs. Split collection from review: the collector reads and normalizes; a separate service evaluates redacted records; only authorized reviewers can request exact text.

Use separate keys and scopes for unrelated consumers. A SIEM pipeline that only needs the Activity Feed should not inherit read:compliance_user_data. A deletion workflow should not share a key carrying delete:compliance_user_data with a read-only inventory job.

The related Anthropic cyber access architecture guide explains the same principle at a broader level: expanded capability must be paired with shorter credentials, tighter egress and observable approvals.

Build an idempotent paginated snapshot

Treat each run as a snapshot, not a stream of independent user rows. Store a run record with organization ID, filters, start and finish timestamps, page count, member count, request IDs, parser version and terminal next_page=null evidence. Only mark the snapshot complete after the final page succeeds.

An implementation loop can be explicit:

page = null
repeat:
  response = list_user_preferences(org, page, stable_filters)
  for each row:
    normalized = canonicalize(row)
    hash = HMAC(audit_key, normalized preference text)
    upsert(run_id, user_id, presence flags, hash, policy findings)
  page = response.next_page
until page is null
mark run complete

Use the stable opaque user ID as the identity key, not email. Email can change and can also expose unnecessary personal data in downstream systems. Bind every record to organization ID and run ID because the same account-level content may legitimately appear in multiple organization snapshots.

Retries must not create duplicate findings. Use a uniqueness key such as run_id + organization_id + user_id. If a page fails, resume from the last committed opaque page token with exactly the same include_unset and user_ids filters. Do not parse, increment or manufacture page values.

For change detection, compare HMAC values rather than plaintext when reviewers only need to know that a preference changed. Rotate the HMAC key through a controlled re-baseline, not by silently making every member appear changed.

Separate detection from interpretation

Persistent instructions are free-form text. A keyword match can find obvious patterns, but it cannot reliably prove intent or risk. A model classifier can help triage, but sending the text to another model creates an additional data transfer and a new prompt-injection surface.

Use deterministic rules first for high-confidence conditions: secret formats, external destinations, explicit requests to override approvals, forbidden data classes and unsafe tool instructions. Run any model-assisted classification inside the approved data boundary with a constrained output schema. Treat the preference text as untrusted data, never as instructions to the classifier. The classifier should not have tools or network access.

Return policy findings with evidence spans, rule version, confidence and reviewer status. Never let an automated finding directly delete content, suspend a user or modify instructions. High-impact action needs a separate approval step and an audit trail.

Preserve privacy without destroying audit value

The safest routine record may contain only:

- stable user ID and organization ID; - whether each preference field is set; - keyed hash of normalized text; - policy finding codes and matched spans after redaction; - observed_at, run ID and parser/rule versions; - reviewer decision and reason.

Store raw text only when the declared objective requires it. Encrypt it with a dedicated key, restrict search, disable analytics indexing, apply a short retention period and log every read. Avoid copying raw instructions into tickets or SIEM events, where access is usually broader and retention is harder to control.

Anthropic's compliance integration guide documents that Compliance API access itself emits compliance_api_accessed activities. Ingest those records so investigators can attribute reads to a key. The same guide recommends stable user_id rather than email as the primary join key and advises preserving provenance metadata and content hashes for chain of custody.

Know the coverage gaps

This endpoint is not a universal prompt inventory. It returns current members' account-level preferences. It does not claim to expose per-project instructions, application system prompts, API request prompts, tool definitions or every local configuration that can influence an agent.

The Compliance API FAQ states that Claude Console and Claude API workloads authenticated with an API key do not expose prompt text or model responses through the Compliance API. Session transcripts also have explicit exclusions, including some third-party cloud and API-key-authenticated Claude Code sessions, zero-data-retention sessions, thinking blocks and tool definitions.

Therefore report three states: observed, not set, and not covered. Never translate not covered into compliant or empty. Coverage metadata should name product surface, authentication path, organization and observation time.

When not to use this endpoint

Do not use it to personalize another product, rank employees, infer performance or train an internal model. Those purposes are not necessary for configuration compliance and dramatically change the privacy and governance requirements.

Do not use it when the organization only needs to publish guidance for safe instructions. A template, user education and product policy may solve the problem without centralized collection. Do not use the API as a substitute for tool authorization: even a perfectly reviewed instruction cannot grant permission to send email, modify infrastructure or expose data.

For application-owned agents, keep prompts and tool policies in versioned configuration you control. The Anthropic Models API routing guide covers model metadata; the Claude Haiku 5.5 production routing guide covers versioned request bundles. Account preferences are a separate end-user surface.

Production checklist

Confirm the organization is eligible and the endpoint remains beta. Document the audit objective and legal basis. Use a dedicated Compliance Access Key with the narrowest scope. Isolate the collector and secrets. Traverse every page until next_page is null. Preserve stable filters across retries. Deduplicate by stable user ID and run. Store presence and keyed hashes by default; retain plaintext only when justified. Treat text as untrusted input. Separate findings from enforcement. Record coverage gaps. Monitor compliance_api_accessed events. Test key rotation, pagination failure, partial snapshots, schema changes and deletion of exported evidence.

The new endpoint makes persistent Claude instructions observable to enterprise teams. Its value is not in copying every prompt into another database. Its value is in building a narrow, explainable control that can prove what was observed, identify risky configuration, respect users' data and remain honest about what the API cannot see.

Prepared by: Noor Yasser