Treat Reasoning Traces Like Production Data (Because They Are)

Engineering teams debug agents by logging everything the model thought. Then they leave those logs sitting in a shared bucket with a long retention window and no owner.

We ask one question in every agent readiness review: where do the traces go? Almost nobody has a confident answer. That's a field observation, not a measured figure, but it holds up across the agentic builds we work on.

Here's the argument. Your prompt is governed. Your output is governed. The reasoning in between usually isn't, and it's often the richest thing in the log. Reasoning traces are production data. Give them the retention policy and access controls you already give your customer databases.

The research that made this concrete

On 10 August 2026, eight researchers published "Stealing Reasoning Traces from Proprietary LLM APIs" (arXiv:2608.09867). The abstract states that the encrypted reasoning blocks these APIs return are "fully compatible and interchangeable across different sessions, users, and models within a provider's ecosystem." Inject a trace from one model into a weaker, less safeguarded sibling, and it prints the reasoning verbatim in plaintext. No jailbreak of the more capable model required (arXiv).

The scale finding is what turns this from a cryptography story into a logging story. Decoding 315,320 reasoning blocks scraped from public repositories, the team recovered 367 PII artifacts and 182 credentials (arXiv). Tech Times reports those blocks came from 6,708 public agent trajectories on GitHub and Hugging Face, and that among artifacts from genuine user sessions were 62 API keys, 33 passwords, 24 access tokens and 7 private keys (Tech Times).

One number should end the debate about whether prompt-and-output sanitisation is enough: 64 of the 704 artifacts from genuine user sessions appeared only in the hidden reasoning and nowhere in the visible conversation (Tech Times). Sanitise the visible transcript and those 64 artifacts stay put.

The same report pins the failure on a deployment choice, not broken cryptography: the encrypted envelopes weren't bound to session ID, user ID or model identity, so integrity was authenticated but context wasn't (Tech Times). The Hacker News covered the work on 12 August 2026 and describes the main extraction attack as now mitigated (The Hacker News). No provider advisory has surfaced confirming which fix shipped where, so treat the mitigation as reported rather than verified.

Why the exposure outlives the patch

A patch closes an extraction path. It doesn't delete the corpus. Every trace already written to a shared bucket, a public repository or a third-party trace store is still sitting there under whatever retention policy someone set once and never revisited.

The underlying structure hasn't changed either. Anthropic's documentation describes thinking content blocks as carrying a signature field, defined as "an encrypted copy of the full reasoning that you pass back unchanged in multi-turn and tool-use conversations." The visible thinking text is a summary, never the raw chain of thought (Anthropic docs). On current models the display field defaults to omitted, so you get a block with an empty thinking field. It's billed the same and passed back the same (Anthropic docs).

That default shrinks the plaintext surface, so the headline exposure is smaller than it sounds. Reasoning state still travels with the conversation, which means any system persisting raw request and response JSON is persisting more than prompts and outputs.

Where the traces actually go by default

This is where teams get surprised. The Claude Agent SDK runs the Claude Code CLI as a child process, and that CLI has OpenTelemetry instrumentation built in. It emits three kinds of signal, each enabled by environment variables (OpenObserve):

• Traces: spans for each interaction, model request, tool call and hook.
• Metrics: tokens, cost, sessions and tool decisions.
• Log events: structured records for each prompt, API request, API error and tool result.

Langfuse documents the same pattern, where "every tool call and model completion is captured as an OpenTelemetry span" with prompts and model inputs and outputs visible in the dashboard (Langfuse).

That instrumentation is the point, an agent loop needs it. The question is the destination. Set an OTLP endpoint pointing at a hosted trace store, and the full content of your agent's work leaves your project, inheriting that vendor's IAM model and retention defaults instead of yours.

The GCP-side controls worth setting this week

On Google Cloud the levers are concrete and checkable. Four of them matter most.

• Know what logging is on. Google's zero-data-retention page states that request-response logging is disabled by default and that achieving zero data retention requires customers to take specific actions in each area (Google Cloud). Audit logs (who called which model, when) and request-response logging (the actual bodies) are two distinct layers (dev.to).
• Name the destination deliberately. Request-response logging persists API call data to a BigQuery destination you specify in the form bq://PROJECT.DATASET.TABLE, with a sampling_rate and an enable_otel_logging flag; for Anthropic models, logging configuration is supported via REST only (Google Cloud). If a dataset holds inference bodies, it needs a partition expiry and a named IAM grant, not the project defaults.
• Separate retention from your audit logs. Cloud Logging's _Default bucket retains 30 days by default, configurable at project level, with custom retention up to 3,650 days (Google Cloud). You get up to 100 log buckets per project, 30 log views per bucket and 200 sinks per project (Google Cloud). That's enough to give trace-bearing logs their own bucket with their own retention and their own access list. A short-lived debug bucket at 7-day retention is a one-line gcloud logging buckets create --retention-days (OneUptime). The _Required bucket is commonly documented at 400 days (OneUptime); confirm current defaults against Google's docs before you write a policy around the number.
• Treat log routing as an exfiltration path. VPC Service Controls define a perimeter around Google Cloud resources to constrain data and mitigate exfiltration, including for AI data sources and models (Google Cloud). Google's own guidance recommends using IAM at folder or organisation level to stop aggregated log sinks moving data out of a perimeter (Google Cloud). Audit which aggregated sinks can write outside the perimeter, and grant sink-creation rights at the folder level only.

Govern traces, don't delete them

The lazy conclusion here is "stop logging reasoning." We disagree, for two reasons.

First, engineering. A multi-step agent loop with tool calls and connector hops can't be debugged from a duration metric. Reasoning is where agent failures hide. Aggressive redaction has a real cost, and thinking blocks have to be passed back unmodified for signature validation to hold, so runtime scrubbing isn't always on the table. The control belongs at the persistence and access layer.

Second, safety. A multi-org position paper argues that models reasoning in legible natural language is a fragile opportunity that should be preserved and turned into a systematic safety agenda (LessWrong summary). Broadly, that's an argument for capturing and monitoring chain-of-thought, not suppressing it. Blanket deletion advice runs straight into it.

Capture traces, then govern them like the sensitive production data they are.

What this means for your compliance scope

If PII can land in retained reasoning while never appearing in the visible conversation, your data-minimisation and subject-access scopes have a gap. Trace stores are in scope. So are the BigQuery datasets behind request-response logging, and any third-party observability backend holding spans with tool arguments in them.

This is also why keeping inference and its telemetry inside your own project is more than a preference. Data that stays in the project inherits your IAM and your bucket retention rather than a vendor's defaults. Worth being honest about the limit: Google's documentation warns zero data retention may not be possible with some Advanced AI features (Google Cloud). "In your project" isn't the same as "retained nowhere."

The review to run

Start with the audit, not the architecture. Find every destination receiving agent telemetry. For each one, answer four questions: which exporters are enabled, where the spans land, who holds IAM on that destination, and what the retention is. Then purge what predates your policy. The published corpus described in the research is historical, and that's the part you can still act on.

After that, make the answer a default rather than a discovery. New agentic work should ship with its trace destination, retention and access grants defined as infrastructure code on day one, the same way you'd treat a customer database.

If you want a second set of eyes on where your agent telemetry currently lands before you scale a build, our Claude Discovery & Assessment produces a prioritised, costed roadmap, trace handling included.