In a previous article, we discussed why PQC compliance does not equal architectural resilience. In this post, we’ll explore why organizations must be prepared to protect identity, context, communications, and paths – not merely ciphertext.
A recently disclosed vulnerability affecting large language model APIs from several leading AI providers illustrates an important cybersecurity lesson: strong encryption does not necessarily mean strong security.
Researchers demonstrated that encrypted AI reasoning generated in one security context could, under certain conditions, be transferred to another model and reconstructed without defeating the underlying encryption. The attack exposed internal model reasoning and sensitive information contained within reasoning traces. The researchers also demonstrated that encrypted reasoning blocks could potentially carry hidden malicious instructions into subsequent AI interactions.
The encryption itself was not necessarily broken.The security architecture surrounding the encrypted information was. That distinction has implications far beyond this particular vulnerability. As enterprises and government agencies deploy increasingly interconnected and autonomous AI systems, securing the cryptographic algorithms protecting information will be essential. But it will not be sufficient.
Organizations must also control who can communicate, what systems can communicate, where encrypted information can travel, and which systems are authorized to process it. In other words: Don't just protect the data. Protect the context. Protect the path.
Modern reasoning-oriented large language models generate internal reasoning while solving complex problems. AI providers generally do not expose all of this information directly. Reasoning traces can contain proprietary information about how a model operates, sensitive information from the model's context, or material that should not appear in the model's final response.
Some AI APIs therefore return reasoning information to the client as encrypted blocks. The client cannot directly read those blocks, but it can return them during subsequent interactions so the model can continue reasoning without requiring the provider to retain all of the session state.
Researchers discovered an architectural weakness in this approach. Encrypted reasoning blocks were sufficiently interchangeable across different sessions, users, and models within a provider's ecosystem that an encrypted reasoning block produced by one model could be submitted to another, less-protected model from the same provider. The researchers demonstrated that the second model could then be induced to reconstruct protected reasoning in plaintext.
Critically, the researchers did not have to mathematically break the encryption or obtain the encryption key. Instead, they caused an authorized system to process legitimate encrypted information in a context in which it should not have been accepted. At scale, the researchers decoded more than 315,000 reasoning blocks obtained from publicly available repositories, identifying hundreds of personally identifiable information artifacts and 182 credentials. They also demonstrated additional attack classes involving proprietary reasoning extraction, disclosure of hazardous information suppressed from final answers, and invisible prompt injection through encrypted reasoning blocks.
The affected providers were notified through responsible disclosure, and mitigations were implemented against the demonstrated attack, but the incident exposes a larger architectural problem that will persist well beyond this particular vulnerability.
It would be easy to describe this as an encryption failure, but that misses the more important lesson.
Those are fundamentally different security problems. An encrypted object can be cryptographically secure while simultaneously being insufficiently bound to the security context in which it was created.
For sensitive AI information, that context may include:
Identity + Tenant + Session + Model + Purpose + Destination + Time
A reasoning artifact authorized for one combination of these attributes should not automatically remain valid when one or more of them changes. If an encrypted artifact created for User A, Session A, and Model A can be presented by User B in Session B to Model B, encryption alone has not preserved the intended security boundary. This leads to an emerging principle for AI security:
AI security architectures should enforce that boundary just as deliberately as they protect networks, endpoints, applications, identities, and data.
Consider a physical analogy. Imagine a perfectly secured package containing highly classified information. An adversary cannot open the package. But suppose the adversary can carry that package into another government facility and hand it to an authorized employee who will open it without verifying where it originated, who presented it, why it was delivered there, or whether that facility is authorized to receive it. The lock worked perfectly. The security system failed. AI creates a digital version of this problem.
Modern AI environments exchange much more than prompts and answers. They increasingly exchange reasoning state, authentication tokens, API credentials, RAG queries and retrieved documents, agent memory, tool calls, MCP traffic, database requests, agent-to-agent messages, and commands to external systems.
Encryption can protect these objects during storage or transmission, but encryption does not inherently determine whether a particular communication relationship should exist in the first place or whether a receiving system should accept a particular artifact. That distinction becomes increasingly important as AI moves from generating information to taking actions.
Generative AI primarily produces information for people. Agentic AI increasingly takes action! An AI agent may query databases, invoke APIs, interact with other agents, access enterprise applications, execute workflows, modify records, initiate transactions, control infrastructure, or interact with operational technology. That fundamentally changes the consequences of misplaced trust.
A malicious artifact no longer has to convince an AI system merely to disclose information. It may potentially convince the system to take an unauthorized action. The recent research therefore illustrates a broader principle: An encrypted AI artifact can be unreadable to an attacker and still be useful to that attacker.
An attacker may not need to decrypt it. The attacker may only need to capture it, redirect it, replay it, inject it, or convince another trusted system to process it. And in an interconnected agentic environment, the number of possible trust relationships expands rapidly:
Each relationship creates a potential security boundary.
The distinction is critical, and neither substitutes for the other. An AI provider can perfectly bind an encrypted reasoning object to the appropriate session and still expose sensitive AI traffic through poorly protected communications infrastructure. Likewise, an organization can perfectly protect communications between two AI systems while remaining vulnerable if the receiving application accepts an artifact that should have been rejected. Effective AI security therefore requires both.
Organizations have spent decades strengthening data protection:
But highly interconnected AI environments require organizations to protect the communication relationships through which information moves.
Communication relationships should therefore be explicit rather than implicit.That principle is particularly important in agentic AI because autonomy magnifies the consequences of excessive connectivity.
AI architectures should not be designed around the assumption that every model, agent, credential, API, and application will remain trustworthy indefinitely. Organizations should instead ask: If this component is compromised, what can it reach? That question changes security architecture from simple prevention to compromise containment.
A compromised agent that can communicate with three explicitly authorized resources represents a fundamentally different risk from a compromised agent sitting on a network from which hundreds of resources are discoverable and reachable. The objective should therefore be straightforward:
Segmentation, communication policy, endpoint protection, identity, contextual authorization, and blast-radius containment become increasingly important as AI autonomy increases.
This incident also provides an important lesson as government and industry begin one of the largest cryptographic migrations in computing history.
Executive Order 14412, Securing the Nation Against Advanced Cryptographic Attacks, issued June 22, 2026, accelerates the Federal transition to NIST-approved post-quantum cryptography. Among its requirements, Federal high-value assets and high-impact systems are to transition cryptographic key establishment to PQC by December 31, 2030, with PQC digital-signature requirements following in 2031. The Order also directs development of acquisition requirements for covered Federal contractors.
That transition is essential. Large-scale quantum computers could eventually threaten widely deployed public-key cryptography. Adversaries can also collect encrypted information today for possible decryption when sufficiently capable quantum computers become available, the threat commonly described as Harvest Now, Decrypt Later.
But post-quantum cryptography would not, by itself, have prevented the AI attack described here. The attacker did not need to defeat the encryption. Replacing vulnerable public-key cryptography with quantum-resistant algorithms such as ML-KEM can protect key establishment from future quantum attacks. It does not inherently determine whether a legitimate encrypted artifact may be moved between sessions, presented by another identity, delivered to another model, or processed in another security context.
The distinction is simple:
An organization can therefore become fully quantum-resistant cryptographically while remaining vulnerable architecturally. Quantum-safe does not necessarily mean cyber-safe.
The vulnerability provides several practical lessons for organizations building or acquiring AI systems.
Sensitive artifacts should be bound to the identity, tenant, session, model, purpose, destination, expiration, and other security attributes appropriate to their use. Moving an artifact outside that context should invalidate it.
Do not assume that network reachability should equal permission to communicate. Define which users, models, agents, APIs, tools, databases, and services are permitted to interact.
Protect the AI object and protect the path carrying it. Neither control eliminates the need for the other.
Assume individual agents, applications, credentials, and endpoints may eventually be compromised. Design the environment so that compromise does not provide unrestricted lateral connectivity.
AI components should not expose network addresses, services, APIs, tools, or data sources they do not need to discover or access.
Organizations already redesigning cryptographic infrastructure for the quantum transition have an opportunity to examine trust concentration, segmentation, communication paths, credential exposure, and blast radius at the same time. The objective should not simply be stronger encryption. It should be stronger security architecture around the encryption.
The recently disclosed LLM vulnerability should not lead organizations to conclude that encryption failed. It should lead them to recognize something more consequential: Encryption is only one layer of security.
As AI systems become distributed, interconnected, autonomous, and increasingly responsible for consequential actions, organizations must protect not only the information being exchanged but also the context in which that information is valid and the communications infrastructure through which it moves. The next generation of AI security therefore requires three complementary objectives: Protect the Data. Protect the Context. Protect the Path.
Post-quantum cryptography will strengthen the first of these against an entirely new generation of cryptographic attacks. It does not eliminate the other two. The lesson from this incident is therefore both simple and important: The encryption worked. The security architecture didn't. And as AI becomes more autonomous and interconnected, understanding the difference will become increasingly important.
It is important to distinguish between the vulnerability itself and the broader architecture that can limit an adversary's ability to exploit vulnerabilities like it.
Dispersive® Stealth Networking does not replace the application-layer correction required for the specific reasoning-block vulnerability described above. AI providers must ensure that protected reasoning artifacts are appropriately bound to the authorized identity, tenant, session, model, purpose, and other relevant security context. A secure communications platform cannot correct an AI application that intentionally accepts an otherwise valid encrypted object in an unauthorized context.
Dispersive addresses a different but complementary security layer: protecting and controlling the communications relationships through which AI systems interact. In an enterprise or government AI environment, Dispersive can create policy-controlled secure connectivity among authorized users, models, agents, APIs, tools, RAG environments, data repositories, cloud resources, and operational systems. Instead of relying solely on conventional network reachability, communications can be constrained to the relationships required for the mission.
This can provide several important protections:
These capabilities would not have corrected the provider-side reasoning-block validation flaw by themselves. But they address an important lesson exposed by the vulnerability: Organizations should not depend upon any single security control, including encryption, to protect an increasingly interconnected AI ecosystem.
Together, those layers provide the defense in depth that increasingly autonomous AI systems require.
Is your organization treating PQC migration as a compliance deadline or an architecture opportunity? We'd like to hear how you're thinking about it.
📞 Book a consultation with Dispersive Stealth Networking: www.dispersive.io
Header image courtesy of OpenClipart-Vectors from Pixabay.