When an AI system carries state across turns, models, tools, sessions, or execution environments, that state crosses a trust boundary. Encryption alone does not define the authority under which that state may be reused.
A recent security paper offers a useful lesson for anyone designing agentic systems.
The lesson is not that reasoning models are unsafe. It is not that encrypted reasoning should be abandoned. And it is not that OpenAI, Anthropic, or Google failed to understand modern cryptography.
The more durable lesson is architectural:
When an AI system carries state across turns, models, tools, sessions, or execution environments, that state crosses a trust boundary. Encryption alone does not define the authority under which that state may be reused.
That distinction matters as enterprises move from isolated model calls to long-running agents that preserve context, invoke tools, resume work, hand tasks to other agents, and operate across multiple execution environments.
In August 2026, researchers published Stealing Reasoning Traces from Proprietary LLM APIs, an empirical study of encrypted reasoning artifacts returned by model APIs. The authors examined implementations from Anthropic, OpenAI, and Google and reported that, during their testing in early July, encrypted reasoning artifacts could be replayed more broadly than their original execution context. They used that portability to recover hidden reasoning through other compatible models and demonstrated several resulting attack paths, including reasoning extraction, exposure of sensitive information contained in published agent traces, and opaque prompt injection.[1]
The work was responsibly disclosed before publication. The researchers state that all affected model providers acknowledged their report and that, following disclosure, they could no longer reproduce the same attacks. Their own reproducibility statement is explicit: the attacks described in the paper were no longer reproducible as of August 2026.[1]
That matters. The publication should be read as evidence about a class of architectural risk, not as a description of a currently exploitable OpenAI, Anthropic, or Google service.
For enterprise architects, however, remediation does not make the underlying lesson disappear. It sharpens it.
The question is no longer simply whether an opaque artifact is encrypted or authentic.
The question is:
Under what identity, session, model, workflow, policy, and execution authority should that artifact be allowed to influence future behavior?
That is an assurance question. And it belongs in the architecture.
How to read the evidence in this Dispatch
This Dispatch keeps three kinds of statements deliberately separate.
Research finding — what the paper reports. These statements describe the authors’ experiments, measurements, limitations, and responsible-disclosure account. They are attributed to the publication and should not be read as provider admissions.
Provider public guidance — what OpenAI, Anthropic, and Google currently document. These statements describe the platforms as their public documentation presents them today. None of the three providers has, in the public record we reviewed, published an advisory explicitly confirming this paper’s characterization of the flaw or tying current documentation changes to the disclosure.
Luminity architectural interpretation — what we derive from the evidence. These are our enterprise-architecture conclusions. They are not claims made by the researchers or by the model providers. They translate the evidence into design principles for governed, production-grade agentic systems.
That separation is essential. The value of the paper is not that it gives architects permission to speculate about proprietary internals. Its value is that it supplies empirical evidence strong enough to expose a general systems question: when opaque state can affect future execution, what must the architecture prove before that state is trusted?
What the researchers found
Modern reasoning models may perform substantial internal computation before producing the response visible to a user. Providers have strong reasons not to expose that internal reasoning directly: intellectual-property protection, safety considerations, model-quality concerns, and the risk that intermediate reasoning contains information that should not become part of the user-facing response.
At the same time, a multi-turn system needs a mechanism for preserving relevant reasoning state between calls.
OpenAI’s current model guidance, for example, supports persisted reasoning across turns. When an application manages history manually under store: false or Zero Data Retention, OpenAI instructs developers to preserve and replay encrypted reasoning items returned by the API.[2]
Anthropic similarly documents encrypted thinking signatures used to reconstruct prior thinking for multi-turn continuity. Its current documentation says those thinking blocks are tied to the model that produced them and advises stripping them when switching models.[3]
Google describes thought signatures as encrypted representations of internal reasoning. Its Interactions API recommends server-managed state when possible; in stateless mode, applications preserve thought blocks and resend them as part of conversation history.[4]
These are legitimate architectural mechanisms. They allow reasoning continuity without simply returning unrestricted internal reasoning as plaintext.
The 2026 paper investigated what happens when the security semantics of those opaque state objects are broader than the context in which they were originally created.
The authors reported three forms of portability during their testing:
- Cross-session compatibility — reasoning state could be reused outside the conversation that created it.
- Cross-user compatibility — state obtained from one user’s published trace could be submitted from another account.
- Cross-model compatibility — in some provider/model combinations, reasoning state generated by one model could be processed by another model in the same ecosystem.[1]
The researchers then exploited a behavioral asymmetry.
A highly capable model might resist requests to expose its internal reasoning. A smaller compatible model might not enforce exactly the same behavioral boundary. If the smaller model could receive the larger model’s valid encrypted reasoning state, it could sometimes be prompted to reconstruct the underlying reasoning.
The important technical distinction is easy to miss:
The researchers did not report breaking the encryption algorithm or recovering provider encryption keys.
Instead, they presented a valid encrypted artifact back to the provider infrastructure. The provider could legitimately process the artifact. The attack then attempted to make an authorized model reveal information reconstructed from that state.
This is why the paper is more interesting architecturally than the phrase “encrypted reasoning was cracked” suggests.
The problem was not simply confidentiality of ciphertext.
It was the relationship between authenticated state and authorized context.
This is the first architectural simplification readers need. Without it, the paper can easily be misunderstood as a conventional cryptographic compromise.
It was something subtler.
The enterprise concern is not chain-of-thought theft
The intellectual-property implications of reasoning extraction are significant for model providers. For an enterprise architect, they are not the most important part of the paper.
The more consequential finding is that opaque agent state can contain information and instructions that the enterprise cannot inspect using ordinary plaintext controls.
The researchers scraped 6,708 publicly available agent trajectories and report reconstructing 315,320 reasoning blocks. Across the larger corpus they identified hundreds of privacy and credential artifacts. In genuine user traces, recovered material included API keys, passwords, access tokens, personal email addresses, names, addresses, and other identifiers.[1]
Some artifacts were reportedly present in the hidden reasoning even when they were absent from the visible transcript.
That creates an important enterprise control failure:
A sanitized transcript is not necessarily a sanitized execution record.
An organization may remove visible credentials from logs before sharing them and still retain opaque state derived from a workflow that encountered those credentials.
The same problem applies to far more than reasoning traces.
An agentic system may preserve:
- tool outputs,
- retrieved documents,
- cached context,
- memory objects,
- workflow checkpoints,
- delegated credentials,
- signed tool calls,
- generated plans,
- approval state,
- agent-to-agent handoff artifacts,
- session resumptions,
- or serialized execution histories.
Every one of those objects can influence future execution.
That makes them part of the system’s effective control plane, whether or not a human can read them.
Opaque does not mean inert
Traditional security thinking often treats an encrypted object as data at rest or data in transit.
Agentic systems complicate that model.
An opaque artifact may be more than stored information. Once replayed into an agent runtime, it may alter what the system believes, remembers, prioritizes, or does next.
The reasoning-trace paper demonstrates this through a second class of experiment: hidden prompt injection.
The researchers placed malicious instructions into reasoning state and then reused that state in another workflow. The receiving model treated the state as part of its prior reasoning and could follow the embedded instruction, even though the malicious instruction was not visible in the ordinary transcript.[1]
Again, the durable lesson is not about a specific provider implementation.
It is about the architecture of stateful agency.
State that can alter future behavior is executable context.
Once we treat it that way, several architectural consequences follow.
An opaque state object should not be trusted merely because:
- it is encrypted,
- it carries a valid signature,
- it came from an approved model,
- it was generated inside an authenticated session,
- or it originated inside the enterprise.
Those properties establish useful facts.
They do not, by themselves, establish whether the object is authorized to influence this execution.
Integrity is not authority
This is the most important distinction in the paper.
Cryptographic integrity can answer a question such as:
“Was this object produced by the expected system, and has it remained unmodified?”
Enterprise authorization asks a different question:
“May this object be used by this actor, in this workflow, at this point in the execution, under this policy, to influence this decision or action?”
Those are not equivalent guarantees.
A perfectly authentic state object can still be used in the wrong context.
A correctly signed instruction can still exceed the recipient’s authority.
A valid agent checkpoint can still belong to another workflow.
A legitimate memory can still contain data that should not cross a tenant boundary.
A provider-generated artifact can still be inappropriate for another model, another agent, or another execution lineage.
This is familiar territory in mature distributed systems. A valid token is not necessarily valid for every audience. A signed message is not necessarily authorized for every operation. A credential is constrained by subject, audience, scope, lifetime, and policy.
Agent state deserves the same discipline.
This is the point where the paper becomes an enterprise architecture discussion rather than a security-news story.
What the paper proposes
The researchers propose several mitigations, including server-side retention of reasoning state, tighter cryptographic binding, model isolation, replay controls, key rotation, anomaly detection, and model-level defenses.[1]
Their most architecturally important proposal is context-bound state.
Rather than authenticating only the contents of an encrypted envelope, the envelope can be associated with properties of the context in which it is valid: user identity, session, predecessor state, conversation position, or other execution metadata.
The paper explores hash chaining and Merkle-style structures to preserve useful properties such as branching and compaction while reducing arbitrary replay. These are research proposals, not published OpenAI, Anthropic, or Google architecture, and they should be read that way.[1]
But the design principle is highly transferable:
Security-relevant state should carry, or be resolvable to, enough provenance and authorization context for the runtime to determine where it may legitimately be used.
The exact implementation may differ.
A provider may keep the state server-side and return only an identifier.
A runtime may cryptographically bind state to an account, tenant, conversation, agent, model, or policy domain.
An enterprise orchestration layer may maintain state provenance independently of the model provider.
An agent platform may introduce expiry, revocation, nonce tracking, or replay detection.
The architectural requirement is more durable than any one mechanism:
state must have enforceable semantics, not merely a serialization format.
Luminity architectural interpretation: what an enterprise architect should keep in mind
The architect’s job is not to duplicate provider-level security controls. OpenAI, Anthropic, Google, and other platform providers will continue hardening their own runtimes.
The enterprise responsibility begins one layer above that boundary.
When we assemble models, tools, memory, APIs, retrieval systems, orchestration frameworks, approval workflows, and enterprise data into a functioning agent, we create a new system with its own trust relationships.
Those relationships belong to the enterprise architecture.
1. Treat agent state as governed data
Do not classify state artifacts by whether humans can read them.
Classify them by what they may contain and what they may influence.
If an artifact can carry enterprise information, derived context, instructions, credentials, tool results, or decision history, it should inherit appropriate data-handling requirements.
That can include retention policy, residency, classification, access control, redaction policy, logging restrictions, and destruction requirements.
2. Treat replay as an explicit architectural decision
Resumability is valuable. So are retries, checkpointing, handoffs, model routing, and workflow recovery.
But every replay capability creates a question:
What constitutes the same execution context?
A production design should be able to answer whether state may move across:
- users,
- tenants,
- agents,
- models,
- model versions,
- workflows,
- environments,
- regions,
- or security domains.
The default should not be accidental portability.
3. Separate provenance from payload visibility
A human operator may never be permitted to inspect raw reasoning, and that can be entirely appropriate.
Governance does not require revealing protected model reasoning.
It does require enough metadata and runtime evidence to establish where state came from, how it moved, what consumed it, and what actions followed.
This distinction is central to assurance by architecture.
We do not need unrestricted visibility into every internal representation. We do need verifiable visibility into the control path.
4. Include hidden state in threat modeling
Threat models for agents often focus on visible prompts, retrieved content, tool calls, and final outputs.
That boundary is too narrow for stateful systems.
Architects should inventory all persistent or replayable artifacts that can affect future execution, including provider-managed and application-managed state.
The question is not simply, “Can an attacker read it?”
It is also:
“Can an attacker cause the system to trust, replay, reinterpret, or propagate it?”
5. Design for revocation and containment
Once agentic systems become long-lived, the enterprise will eventually need to invalidate state.
A compromised session, poisoned memory, obsolete checkpoint, revoked delegated credential, or incorrectly classified artifact should not remain indefinitely influential merely because it was once valid.
Architectures therefore need practical answers for:
- expiry,
- invalidation,
- version boundaries,
- session termination,
- rollback,
- quarantine,
- and blast-radius containment.
6. Observe the state transition, not only the model output
A system can produce a perfectly acceptable final response while taking an unacceptable path to get there.
Conversely, a system can use protected internal reasoning appropriately without exposing it.
The enterprise assurance surface therefore sits at the transition layer:
input → state → decision → tool authority → action → evidence.
That is where traces, evaluations, policy checks, approvals, and audit evidence become architectural primitives.
This is the core enterprise translation of the research.
Provider public guidance: what is documented today
The details of the provider implementations continue to evolve, which is exactly why architects should avoid designing around the paper’s July 2026 behavior as though it were a permanent platform property.
Provider stance note. In the public record reviewed for this Dispatch, OpenAI, Anthropic, and Google document how their current reasoning-state mechanisms work, but none has published an advisory explicitly endorsing the paper’s description of the vulnerability or attributing current behavior to this disclosure. The researchers report that the demonstrated attacks stopped working after responsible disclosure; that remediation account remains the researchers’ statement rather than a public vendor confirmation.[5]
OpenAI currently supports persisted reasoning for multi-turn workflows. With server-managed continuation, applications can use prior response identifiers; when manually managing history under store: false or Zero Data Retention, OpenAI’s guidance is to preserve the encrypted reasoning items returned by the API.[2]
Anthropic’s current documentation describes encrypted thinking signatures and now states that thinking blocks are tied to the model that produced them. When switching models, Anthropic recommends removing prior thinking blocks because another model will ignore them.[3]
Google recommends stateful mode for its Interactions API, where the service manages thought state server-side. In stateless operation, thought blocks remain part of the history supplied by the application.[4]
These are not identical designs, nor should enterprise architects assume they will converge on one design.
The architectural responsibility is therefore to understand the semantics of the platform being used and then impose enterprise controls at the composition layer.
A provider secures its service.
The enterprise must secure the system it creates from that service.
A note on evidence and restraint
This paper is unusually useful because it combines a concrete API-level finding with large-scale experiments and a responsible disclosure process.
It should still be read with appropriate qualification.
The authors acknowledge that they did not possess the ground-truth plaintext for proprietary reasoning and therefore could not prove perfect reconstruction of every extracted token. They used token-count correspondence and qualitative evidence as proxies for extraction fidelity.[1]
The privacy scan was substantial but not an exhaustive audit of all agent traces in the wild.[1]
The paper also infers aspects of provider cryptographic architecture from observed API behavior. Internal key management and implementation details were not publicly documented by the providers.[1]
Finally, the authors report that the attacks stopped working following disclosure.[1]
Those limitations do not weaken the enterprise architectural conclusion.
They help define it correctly.
We do not need to claim that a particular provider remains vulnerable. We do not need to speculate about undisclosed implementation details. And we do not need access to proprietary reasoning to draw the important lesson.
The empirical evidence demonstrates that portable opaque state can become a security boundary when its context of use is broader than its intended authority.
That is enough to inform architecture.
Luminity conclusion: from model security to system assurance
Enterprise AI is rapidly moving beyond the model-response pattern.
The emerging unit of architecture is the governed workflow: a system in which agents maintain context, make decisions, invoke tools, access enterprise data, delegate work, and persist state over time.
As that happens, trust cannot depend on a sequence of assumptions:
- the model is aligned,
- the artifact is encrypted,
- the provider generated it,
- the user is authenticated,
- the tool is approved.
All of those controls can be true while the composition is still unsafe.
Assurance requires us to prove something stronger:
The right state influenced the right execution, under the right authority, through the right controls, and produced evidence sufficient to reconstruct why the resulting action was permitted.
That is Assurance by Architecture.
It shifts governance from documentation about the system to enforceable properties inside the system.
For agent state, those properties include identity, provenance, context binding, authorization, replay policy, lifecycle controls, observability, and evidence.
None of them require an enterprise to see a model’s private chain of thought.
They require something more useful operationally:
the ability to demonstrate control over how state becomes action.
The durable architectural claim
The reasoning-trace research will eventually become historical. APIs will change. Models will change. Encryption schemes will change. The specific replay paths described in this paper have already reportedly been mitigated.
The architecture lesson will remain.
In an agentic system, state is part of the authority path. Any state capable of influencing future reasoning, decisions, tool use, or action must be governed according to where it came from, where it is allowed to travel, what it is allowed to influence, and how its use can be evidenced.
Encryption protects contents.
Signatures establish authenticity and integrity.
Enterprise architecture must establish contextual authority.
That is the difference between an intelligent system that appears trustworthy and one whose trustworthiness can be demonstrated.
In an agentic system, state is part of the authority path. Any state capable of influencing future reasoning, decisions, tool use, or action must be governed according to where it came from, where it is allowed to travel, what it is allowed to influence, and how its use can be evidenced.
