The Compliance API now returns the settings in force for each Claude Enterprise organization: the enforced state after regulatory restrictions, feature-availability rules, organization-type defaults, and inter-feature dependencies are applied — which Anthropic notes can differ from what an administrator configured [1]. Anthropic states the purpose directly. The endpoint exists to attest that retention windows, content redaction, single sign-on enforcement, the IP allowlist, and session-duration controls match a documented baseline, without administrator Console access [1].
Our observation is that this instrument separates three states an attestation has to keep apart: what an administrator configured, what the platform enforces, and what the enterprise can later prove was in force.
Configured, Enforced, Attested
The effective-settings response is a list of typed rows, each carrying a name, a type, and a value [1]. The values reflect enforcement, not the last stored configuration, and the documentation gives three examples of the difference [1]:
sso_provisioning_modereports a configured SCIM mode only while directory sync is enabled.ip_allowlist_enabledis true only while the allowlist is on and has at least one active range.code_execution_network_egress_enabledis false whenever code execution is off.
In each case the enforced value is a function of the configured value and everything it depends on. An allowlist switched on with no active ranges is configured and not enforced. Stated precisely, the endpoint reports the outcome of the platform’s resolution, and the Console reports the input to it.
A Missing Row
Which rows appear varies by organization. A setting the organization’s administrators cannot change — because Anthropic policy controls it, or because it is not available to that organization — is omitted [1]. Anthropic’s instruction is to treat a missing row as not controllable by that organization’s administrators, not as off [1].
Settings that report a compliance arrangement with Anthropic are the exception. The HIPAA and Access Transparency settings are always included, and Claude Enterprise organizations also report the Claude Code zero data retention (ZDR) and customer-managed encryption key (CMEK) settings [2]. Each reports whether the arrangement is in place at the organization level; a retention setting on an individual workspace is not reflected [2].
Our observation is that a baseline comparison against this endpoint has three outcomes, not two. A row can match the baseline, differ from it, or be absent. The third outcome is neither a pass nor a failure. It is a statement about who controls the setting, and the attestation has to record it as such.
Nothing Is Snapshotted
The response reflects the state at read time, and nothing is snapshotted [1]. Changes to most of these settings surface as events in the Activity Feed, and Anthropic directs integrators to the endpoint for the current resolved state and to the feed for who changed what, and when [1].
The endpoint answers what is in force now. It does not answer what was in force on a date an auditor names. The feed’s change events record who changed what, but the only snapshot of resolved state at a past date is one the enterprise captured at the time — its own read, joined against those events — and the resolution of that history is the enterprise’s polling cadence.
The same read returns the evidence channel’s own access list. An api_keys array names every Compliance Access Key on the parent organization, including deactivated keys, with each key’s scopes, active flag, and creator; the secret is never returned [1]. Who can mint those keys is fixed by role: in Claude Enterprise, only the Primary Owner enables the Compliance API, and Owner keys are limited to their own organization [4]. Our observation is that the instrument attesting the controls also attests who can read the evidence.
Retention Is a Setting in Force
The effective-settings response includes the organization’s data retention periods as a typed row [1]. What that row resolves to governs what the session record holds. Captured local session content is kept for six years by default, or for the organization’s finite custom period, whether shorter or longer; when several are configured, the shortest applies [3]. Shortening the period takes effect immediately — the endpoints stop returning older activity as soon as the setting changes — while each captured message keeps the period in effect when it was captured, so lengthening the period later does not restore content that has already expired [3]. Deletion behavior varies by surface, and none of it runs through the Compliance API, whose session endpoints are read-only [3].
Our observation is that retention is the setting whose enforced value has the longest reach. A shortening attested today determines which evidence exists to be retrieved next year, and the documentation is explicit that a later change cannot reverse it.
What the Setting in Force Asks of the Enterprise
The documentation defines the instrument and its semantics. Our observation is that three practices follow.
Snapshot on a cadence and on change. Read the effective settings, including the key inventory, on a fixed schedule and again whenever the Activity Feed records a settings change. The archive of those reads becomes the basis of the attestation history.
Compare in three outcomes. Match, differ, or absent. Record the absent case as a statement about control, never as compliance.
Gate retention changes. Treat any shortening of the retention period as a change with irreversible evidentiary effect, approved before it is made rather than discovered after.
The effective-settings endpoint reports what the platform enforces, and only at the moment it is read. Our observation: attestation binds to the enforced state, and the history of that state exists only if the enterprise captures it.
