--- title: "Capability: AI conversation evidence" canonical_url: "https://tokenobserve.com/platform/conversation-evidence" published: 2026-09-06 last_updated: 2026-10-21 --- # Capability: AI conversation evidence What the AI was asked and what it returned, redacted before it is stored and bounded before it is kept. ## What it is Token Observe can retain the normalised text of model requests and responses, with the tool activity the model proposed beside it. It is off by default: ACP_CONVERSATION_CAPTURE ships as metadata, which stores no message text at all, and redacted is a per-deployment decision governing gateway model conversation evidence rather than all audit logging. What redacted keeps is bounded and marked (32,000 characters and 100 messages per event, both configurable), and the personal-data and credential detectors run before truncation, so a credential near the end of a long prompt is removed rather than merely cut off. Hidden chain of thought is not readable from any provider and is not claimed. ## Facts - Default: Metadata only. Text capture is opt-in - Bounds: 32,000 characters, 100 messages per event - Order: Redaction runs before truncation - Sources: Gateway request, provider response, cache ## The limit What the detectors cannot find: Every confidential business fact in free text ## Why it exists: Nobody can say what it was asked. Something goes wrong with an AI-assisted process (a customer receives a reply that should never have gone out, a tool action fires against the wrong record), and the first question is always the same. What was it asked, and what did it say back? A trace showing a request at a timestamp with a token count establishes that something happened and nothing about what. The content that would answer it is the most sensitive material the system touches. So capture is a per-deployment decision rather than a default, what is kept is redacted before storage and bounded before it is kept, and both the bounds and the redactions are visible in the record, so a reader knows what they are not seeing. ## How it works - Default to metadata, opt in to text: Capture ships as metadata and stores no message text. Changing it to redacted governs gateway model conversation evidence and not all audit logging (MCP and OTLP ingestion are governed separately), so it widens nothing else. - Redact, then truncate, in that order: Redaction runs first, independently of outbound policy: content is redacted for storage whether or not a policy fired on it. Truncate first and a credential in the last paragraph of a long prompt survives right up to the cut. - Bound every event, and label its source: 32,000 characters and 100 messages per event, both configurable, and what was omitted is recorded rather than dropped. Every message carries its source — gateway request, provider response or response cache — so a cached reply is distinguishable from a live one. - Keep evidence for refused requests too: Requests blocked by policy or held for approval retain bounded evidence, because the stopped ones are the ones somebody reviews. Blocked model output is withheld: the record shows what was asked and that it was refused. ## What it does not do - It does not record hidden chain of thought. No provider exposes it, and encrypted provider reasoning state is not readable evidence. - It is not on by default. Metadata capture keeps no message text at all, and redacted is a decision somebody has to make. - Redaction is heuristic. The detectors find known personal-data and credential shapes and cannot identify every confidential business fact in ordinary prose. - Related-turn links are an exact agent and session correlation, not a reconstructed thread, because a reused transport session can span unrelated tasks. - Captured evidence is bounded, so a long exchange is retained in part, with the omission recorded rather than hidden. - Provider-native summary paths, signed-state continuation and approved client integrations are work in progress, not shipped behaviour. - No conversation record is a complete claim about the estate. A missing trace cannot prove comprehensive coverage of what AI was asked. ## Read next - https://tokenobserve.com/platform/flight-recorder - https://tokenobserve.com/platform/approved-ai - https://tokenobserve.com/platform/estate-spend ## Questions and answers Q: Does Token Observe store our prompts by default? A: No. ACP_CONVERSATION_CAPTURE ships as metadata, which keeps no message text at all; retaining request and response text is an explicit per-deployment choice. That setting governs gateway model conversation evidence rather than all audit logging, so enabling it does not widen the MCP or OTLP ingestion records. Leave it alone and the product records that a request happened without keeping what it said. Q: Can you see what the model was thinking? A: No, and nobody can. Reasoning models do not return their internal reasoning: some providers return an exposed summary, some an encrypted state token only they can interpret, and none the reasoning itself. Token Observe retains text a provider exposes, including those summaries. Hidden chain of thought is not available, is not recorded, and is not claimed anywhere on this site. Q: If redaction runs, is the stored content safe to keep anywhere? A: Treat it as sensitive regardless. Redaction runs before truncation on the personal-data and credential detectors, which removes the shapes they know. It is heuristic: a prompt describing an unannounced deal in ordinary prose matches no pattern and will be stored, inside the same retention and access controls as the rest of your evidence. The long-form detail on this capability (the anchored sections, the worked policies and the error envelopes) is on the page itself at https://tokenobserve.com/platform/conversation-evidence.