Every message in a Claude Enterprise local session transcript carries a provenance field that states how its content was captured [1]. Anthropic’s guidance is to treat the exceptions it marks as present but unavailable or unverified, not as missing [1]. Our observation is that this field is the record’s own statement of what it can vouch for — and that it has to travel with the content through every system the transcript reaches.
What the Provenance Field Records
Anthropic’s session endpoints return transcripts for the products Claude Enterprise users run on their own machines — Cowork, Claude Code, Claude Science, Claude for Microsoft 365, and Claude in Chrome — and for Cowork sessions that run in Anthropic-managed cloud environments [1]. Coverage is stable for Cowork, Claude Code, and Claude for Microsoft 365, and in beta for Claude Science and Claude in Chrome [1].
Each message in a local session transcript carries a provenance field [1]. When it is null, the content is verified — in Anthropic’s sense, captured by the Claude API as the request reached it. That is the common case. When it is set, its type names the exception:
content_unavailable— the content cannot be returned. The content array is empty and a reason is stated:not_captured,client_aborted,retention_elapsed, oroversize, withcmek_key_revokedreserved for forward compatibility [1].client_asserted— an assistant message the client supplied as conversation history that could not be matched to a captured response. Its authorship is not verified [1].synthetic_marker— a record the endpoint generates itself, such as the marker that stands in for the system prompt [1].
Anthropic’s guidance on these records is direct: treat them as present but unavailable or unverified, not as missing, and tolerate provenance types and reasons a handler does not yet recognize [1]. The guidance anticipates values a handler has not yet seen.
Absence Without a Cause
The reason code that carries the most weight is the one that resolves the least. not_captured means no content is available for the turn. It does not establish that no record was stored. Content that Anthropic’s data-handling policies withhold from the Compliance API reports the same reason, as do individual turns inside an otherwise captured session that are unavailable for such reasons [1].
Our observation is that not_captured is a statement about the record, not about the session. It tells a reviewer that the evidence channel holds nothing for that turn. It does not say why, and it does not say the turn was empty.
The session list sharpens the point. It is built from activity metadata, so it can include sessions that ran before capture began for the organization, as far back as retention allows; those transcripts return each message with content marked unavailable [1]. A session’s presence in the list establishes that it ran. Its transcript establishes only what the channel captured.
One condition is deliberately separated. When a customer-managed encryption key cannot be used, the messages endpoint returns a 503 for the affected pages rather than reporting not_captured [1]. An unavailable key is an operational state the enterprise controls, and the record keeps it distinct from an evidentiary gap.
Authorship as a Field
client_asserted is the provenance type with the clearest evidentiary consequence. A client can send prior conversation history with a request. When an assistant message in that history cannot be matched to a response the Claude API actually produced, the transcript returns it marked as client-asserted, with its model field set to null [1].
Stated precisely, the record declines to vouch for history it did not witness. A reviewer building an eDiscovery production, an incident timeline, or a supervision file is entitled to attribute verified assistant turns to the model that served them — the model field names it [1]. A client-asserted turn carries no such attribution. It is text the client presented as a prior response, and the record says so.
The Boundary of What Was Witnessed
Provenance describes how the transcript’s content was captured. A second boundary defines what it can hold at all. Anthropic records local sessions server-side as their requests reach the Claude API; nothing is installed on the device, and nothing is collected beyond the requests the client already sends [1]. The transcript shows what Claude was asked and what it returned, not what happened on the machine. Activity that never reaches the API is outside it [1]. File and network activity is visible only through the tool calls and tool results in the transcript, so local files a session never sent are not captured, and the transcript carries no host or device metadata [1].
Inside that boundary, several things are structurally absent [1]:
- Thinking blocks are never included.
- The system prompt is never returned; a synthetic marker stands in for it.
- Tool definitions and MCP server configuration are not part of the transcript.
- Images, PDFs, and other binary blocks appear as placeholders, flagged as truncated.
- Citation metadata on text blocks is omitted; the text itself is returned.
- Project instruction files such as
CLAUDE.mdappear as ordinary user content, and skill content is not distinguished from other user text.
Worth drawing out: the inline enforcement point carries the same exclusions. The AI security server behind an inference hook never receives system prompts, tool definitions, or raw file and image bytes [2]. Neither the record nor the gate exposes the system prompt or tool definitions that framed a request.
Tool names carry a blind spot of the same kind. Claude Science calls connectors from code run through its repl tool, so no transcript block is named after a connector, and connector use has to be found by parsing the repl input. Tool inputs and tool result text are cut at 10,000 bytes per entry by default, and Anthropic’s instruction for Claude Science is to request the server maximum of about 1 MiB [1].
Seams in the Session
A transcript also marks where the conversation itself was rewritten. When a client compacts or rewrites its history mid-session, the transcript inserts a marker at that point and continues with what the client sent next. Under a finite retention period, the new content is withheld up to and including its last assistant message, and a second marker records that [1].
Session identity has seams of its own. A local session corresponds to one client session ID; clearing context starts a new record [1]. A Claude Science conversation that continues across some app updates appears as two sessions, and the app’s background work can appear as separate sessions [1]. The unit of evidence is the client’s session, not the user’s conversation.
Two Endpoint Families, Two Signals
The provenance taxonomy belongs to local session transcripts. Remote Cowork transcripts carry a simpler signal: a message whose content cannot be returned is flagged content_unavailable as a boolean [1]. Remote sessions also carry ownership a local session does not. Agent-owned runs, such as Cowork scheduled tasks, record the agent’s ID and the human who started the run, and agent-owned user messages can carry the sending user’s ID where it is attributable [1].
An integration that consumes both families is reading two different signals. Normalizing them into one is an architectural decision; our observation is that the more detailed local signal is the one to preserve.
What the Provenance Field Asks of the Enterprise
The documentation defines the field and how to treat it. Our observation is that three requirements follow for every downstream system the transcript reaches — the archive, the SIEM, the eDiscovery platform, the supervision queue.
Carry provenance as evidence metadata. A pipeline that ingests content and drops the provenance object leaves verified and unverified turns indistinguishable downstream, and nothing in the content itself signals the loss.
Weight by provenance. Verified turns support attribution to a named model. Client-asserted turns support only the claim that the client presented them. Unavailable turns support only the claim that the channel holds nothing.
Pass through what is not yet recognized. Anthropic instructs handlers to tolerate unrecognized provenance types and reasons [1]. A handler that rejects or discards unknown values loses that signal as soon as a new value appears.
In a local session transcript, every message states how its content was captured, and Anthropic’s own guidance treats the exceptions as present but unverified or unavailable — not missing. Our observation: the provenance field is the record’s explicit, structured signal for separating them, so it has to be retained wherever the content goes.
