A security reviewer who asks whether a given Claude Code session is on the record is asking a question with no product-level answer.
There is an answer per session, and it turns on how that session was enrolled.
What the session endpoints return, and what they leave out
The Compliance API’s session coverage is scoped by product and by where the session runs. Local session endpoints return Cowork sessions in Claude Desktop and Claude Code sessions in the terminal, in Claude Desktop, or in an IDE extension, all running on the user’s machine. Remote session endpoints return Cowork sessions started on claude.ai web or mobile, which run in the cloud in Anthropic-managed environments. Each returned session declares which of three surfaces it came from — cowork, claude_code, or cowork_remote — and that enumeration is the authoritative statement of what the endpoints cover. Capture of local sessions is tied to the Compliance API being enabled for the organization and applies while users are signed in with their Claude Enterprise account.
The exclusions are enumerated in the same reference, and each one is worth reading for what it turns on.
Claude Code sessions authenticated with a Claude Console API key, or run through a third-party cloud platform such as Amazon Bedrock, Google Cloud, or Microsoft Foundry, are not returned. Claude Code on the web is not returned either — it also runs in the cloud in Anthropic-managed environments, but it is not a remote session, and the remote session endpoints return Cowork sessions only. Local sessions in organizations with HIPAA readiness enabled are not captured at all. Local sessions under zero data retention are excluded from list results, and the retrieve and messages endpoints return 404 for them.
Stated precisely: the first exclusion is about a credential, the second about a platform, the third about a product surface, and the last two about a privacy arrangement. Not one of them is about what the agent was asked to do or what it did. The announcement is consistent on this — the beta excludes Claude Code on the web, Claude Code accessed through the Claude Platform, and sessions run on the three third-party platforms.
The organization is the unit, and it is not one organization
Enrollment has a structural layer beneath the credential. A Claude Enterprise tenant has one parent organization that centralizes identity, with linked organizations of two kinds: claude.ai organizations, where users chat and store content, and Claude Console organizations, where users manage API workloads.
The two key types reach different surfaces. A Compliance Access Key created in claude.ai reaches every endpoint; an Admin API key created in the Console reaches the Activity Feed only. The session endpoints are read-only and are not available to Admin API keys — calls authenticated with one return 403. And the content endpoints, sessions among them, serve Claude Enterprise data only, while a standalone Claude Console organization with no parent is not part of a Claude Enterprise tenant at all: it uses Admin API keys and can query the Activity Feed only.
So an enterprise can hold a Compliance API deployment, a Compliance Access Key, and a live Activity Feed, and still have agent activity running in a part of its own estate that the session endpoints do not reach. Our observation is that the coverage boundary follows the organization graph, and the organization graph is drawn by identity and procurement rather than by whoever owns agent governance.
The enforcement side carries the same shape. One inference hook configuration governs claude.ai, Cowork, and Claude Code sessions across web, desktop, and CLI — and inference hooks are not available on Amazon Bedrock or Google Cloud, with Platform organizations out of scope. Two instruments, one enrollment predicate.
Two records of the same product
Anthropic ships a second record that touches Claude Code, and it divides coverage on the same axis in the opposite direction.
Access Transparency writes an anthropic_access activity to the organization’s Compliance API Activity Feed on each human view of retained data by an Anthropic employee, for safety review or incident response, and it is available to eligible customers on request rather than self-serve. Its surface-eligibility table lists Claude Code using an API key as covered, on the basis that API traffic from Claude Code is covered as Claude API traffic. The same table lists Claude for Enterprise claude.ai seats, Claude for Work, and Cowork as not covered.
Set that beside the session endpoints, which return Claude Code sessions captured while users are signed in with a Claude Enterprise account and exclude sessions authenticated with a Console API key. The axis of division is the credential in both cases, and the direction is reversed.
Worth drawing out carefully, because the two tables are not written to the same schema: Access Transparency’s table names Claude Code on an API key as covered and Claude for Enterprise seats as not covered, and it does not enumerate Enterprise-authenticated Claude Code as a separate row. Reading the two instruments as a strict complement is therefore our inference from how each documents its own scope, not a statement either page makes. What each page does state directly is that its coverage turns on the credential. That much is not an inference.
Two further limits belong in any assurance claim built on Access Transparency. Coverage applies from the time it is enabled, and Anthropic does not guarantee coverage for content written before enablement. And an empty feed means no human at Anthropic has viewed the content; it does not mean the content was not processed by automated systems, which do not generate these events.
Privacy posture is an enrollment decision, and one of them is final
The retention page states the interaction between privacy arrangements and the evidence channel without qualification: the Compliance API does not capture local sessions for which zero data retention is in effect, or any local sessions from organizations with HIPAA readiness enabled.
Three facts from the same page determine what an architect can do about it. HIPAA readiness is enforced at the organization level, and organizations needing both HIPAA-ready and general-purpose access are directed to use separate organizations. Claude Code is not covered under HIPAA readiness. And once HIPAA readiness is enabled for an organization, the configuration is permanent and cannot be disabled by an administrator. Zero data retention is likewise enabled per organization by the account team, and enablement does not automatically extend to other organizations under the same account.
Read together with the organization graph: the decision that removes agent session capture is made at the organization level, is made once, and in the HIPAA case cannot be unmade. The architecture that preserves both postures — a HIPAA-ready organization for regulated workloads and a separate organization where agent sessions remain visible — is available, and it is available before enablement rather than after. That sequencing is the finding. It is not a limitation of the instrument; it is a decision the enterprise owns and can only take in one direction.
The deletion right is not uniform either
Enrollment decides whether a record exists. A second asymmetry decides whether the organization can act on it.
The Compliance API exposes hard-delete endpoints for chats, files, project documents, and entire projects, on a delete:compliance_user_data scope granted separately from the read scope when the Compliance Access Key is created. Every successful delete is permanent and immediate, with no recovery window, and a hard-deleted chat stops appearing in list responses afterward.
The session endpoints carry no equivalent. They are read-only, and local and remote sessions cannot be deleted through the Compliance API. Retention is the only instrument that removes them, and it is configured in claude.ai rather than called through the API. That holds for the Cowork and Claude Code sessions these endpoints return; it is not a general property of everything Anthropic calls a session, and a reader running other agent products should check the deletion semantics of each.
So one key, under one arrangement, holds an irreversible deletion right over chat content and no deletion right at all over agent transcripts. For an organization answering an erasure request, the available response differs by surface — and the surface it can act on is the one where deletion cannot be undone, while the surface it cannot act on is the one retained for six years by default. Both halves of that are documented; neither is a property of what the agent did.
What this does to a hold
Enrollment determines whether a transcript exists. Two further scope properties determine whether a reviewer will find it.
On the remote session list, the user filter matches the session’s owning user, so agent-owned sessions are excluded whenever it is set. A remote session is owned by either a user or an agent and never both: for agent-owned sessions such as scheduled tasks, the owning user is null, an agent identifier is carried instead, and started_by_user identifies the human who initiated the run. So a query scoped to a named custodian omits the agent-owned runs that custodian started, and the attribution needed to recover them sits in a different field from the one the filter reads.
The local session list has no user filter at all; results are bounded in time instead. A custodian-scoped export of local sessions is therefore assembled by the enterprise from a time-bounded organization-wide walk, not requested.
For a litigation team, the practical question is not whether the Compliance API supports eDiscovery exports — the documentation states that it does. It is which sessions were in scope to be captured at the time the events occurred, given the credential, platform, and privacy posture then in effect. That is a question about enrollment history, and it is answered from the organization’s own records.
The hard claim
Visibility is not a property of the product. It is a property of the enrollment: which credential authenticated the session, which platform served it, and which privacy arrangement the organization signed. One of those choices cannot be reversed, and none of them is ordinarily made by whoever governs the agent.
That has a direct consequence for how an assurance program describes its own coverage. “Claude Code sessions are retained and retrievable” is not a statement about Claude Code. It is a statement about a particular organization, holding a particular key, under a particular retention arrangement, on a particular surface — and it stops being true one credential over. A coverage map for an agentic estate is therefore an inventory of enrollments, not an inventory of products, and it has to be maintained as identity and procurement change it.
Which places the duty where it sits. Every enrollment property above is set by identity, procurement, or privacy — functions that do not report to whoever answers for the agent’s behavior, and none of which any vendor can set on the enterprise’s behalf. Assurance is not a property an enterprise procures with an instrument; it is one it owns and assembles, and enrollment is the first thing it has to know about its own estate.
Together with the three that precede it, the set gives a reviewer two questions to put to any agent product, from any vendor. Where does capture bind relative to the write. And what decides whether capture happens at all.
Visibility is not a property of the product. It is a property of the enrollment: which credential authenticated the session, which platform served it, and which privacy arrangement the organization signed.
One of those choices cannot be reversed, and none of them is ordinarily made by whoever governs the agent.
