Is an enterprise RAG assistant safe for privileged and classified documents?

A cloud enterprise RAG assistant is not safe for privileged or classified documents. The moment those documents are indexed and embedded on a vendor's infrastructure, the index becomes a second copy of your material that you no longer physically control, and that index is an exfiltration surface in its own right. A RAG assistant becomes safe for this material only when retrieval, embeddings and inference all run inside your own perimeter, on hardware you own, with every retrieval cryptographically signed so an auditor can prove which source produced each answer. Safety here is a question of architecture, not of a vendor's privacy policy.

The question matters in 2026 because enterprise search assistants have started ingesting everything: contracts, case files, board minutes, intelligence products, source code and email. Buyers in law, defence, finance and national government are realising that a hosted index is a distinct risk from the documents that fed it. Under the US CLOUD Act a provider can be compelled to hand over data it holds, wherever that data physically sits. Public cloud AI services are built to send text to someone else's computers, which is precisely what a regulated buyer cannot allow for material under legal privilege or national classification.

Why is a cloud RAG index an exfiltration surface?

Retrieval augmented generation works by cutting documents into chunks, converting each chunk into a numerical embedding, and storing those embeddings in an index. When you ask a question, the assistant retrieves the closest chunks and feeds them to a model that writes the answer. Every stage creates a copy.

The index is not a harmless summary. Embeddings can be partially inverted to reconstruct the source text, so the vector store leaks even when the original files are locked away. The chunk store usually holds the raw text outright. On a cloud RAG assistant all of this lives on infrastructure the vendor administers, which means vendor staff, a compromised support account, a misconfigured bucket or a lawful production order can all reach it. The documents may never have moved, and the secret has still left the building.

Retrieval also widens the attack surface at query time. A single poisoned document placed in the corpus can carry instructions that a naive assistant will follow, turning your own search index into a channel for prompt injection and cross-tenant data pulls.

What makes retrieval over classified material safe?

Safety comes from one rule: nothing that touches the document leaves the perimeter. That means three components must sit inside the operator's own boundary, not just one.

• Retrieval: the chunk store and vector index run on operator-owned hardware.
• Embeddings: documents are embedded locally, so the plaintext is never sent to an external embedding service.
• Inference: the model that reads the retrieved chunks and writes the answer runs locally too.

If any one of the three is hosted, the material is exposed at that stage. A common half-measure keeps the files on-premises but calls a cloud embedding or inference endpoint, which quietly ships the very sentences you were protecting. The safe design is a zero-egress inbound perimeter: requests can come in, but no document text, embedding or model call goes out. The plain test is to pull the network cable and confirm the assistant still answers from the classified corpus. If it cannot, it was never self-contained.

What is signed retrieval and what does it prove?

Signed retrieval means every answer is bound to cryptographic proof of the exact source chunks that produced it. When the assistant returns a sentence, it also returns a signature over the retrieved passages, the model identity and the time, written to an append-only audit ledger.

This matters because a privileged answer with no provenance is a liability. Signed retrieval lets you show, later and to a hostile reviewer, that a given output came from an authorised document and not from a hallucination or a leaked source. We sign the ledger with post-quantum digital signatures: FIPS 204, the ML-DSA standard, as the primary scheme, with FIPS 205, SLH-DSA, available as a stateless hash-based alternative. These are signature standards. FIPS 203, ML-KEM, is key encapsulation and does no signing, so it is never what makes the ledger verifiable. Identity is hardware-attested and bound to the same chain, so each entry names the operator and device that ran it.

“A retrieval assistant is only as trustworthy as its ability to prove, after the fact, exactly which document produced each sentence it returned.”

What can an auditor actually check?

An auditor should be able to run four checks without trusting the vendor.

• Provenance: pick any answer and verify its signature resolves to specific source chunks in the ledger.
• Containment: inspect network egress and confirm no document text, embedding or model call left the perimeter.
• Identity: confirm each ledger entry is bound to a hardware-attested operator and device, not a shared service account.
• Integrity: confirm the ledger is append-only and that its post-quantum signatures still verify end to end.

Cross-model consensus adds a further check. For high-stakes answers, several sovereign models can be required to agree before an answer is released, and each model's vote is recorded in the same signed ledger. Disagreement becomes a visible, auditable event rather than a silent error.

Which rules make an in-perimeter assistant necessary?

Several regimes converge on the same conclusion for sensitive corpora.

• US CLOUD Act: data held by a US-linked provider can be compelled regardless of where it is stored, so hosting the index abroad does not protect it.
• GDPR: personal data in the corpus and in the embeddings must have a lawful basis and a controlled processing boundary.
• DORA: in force since January 2025, it holds financial entities accountable for the resilience and traceability of their ICT and third-party services.
• NIS2: covers essential and important entities and pushes accountable, auditable security controls across the supply chain.
• ISO/IEC 42001: the AI management-system standard expects documented governance over how models handle data.

The EU AI Act completes the picture, with a nuance worth stating precisely. The high-risk Annex III obligations, once due on 2 August 2026, were deferred by the Digital Omnibus to 2 December 2027, with embedded Annex I high-risk systems moving to 2 August 2028 and the Article 50 transparency duties left largely unchanged. We read that not as a reprieve but as a build window: the time to move retrieval inside the perimeter before the obligations bite.

How does Mickai run RAG over privileged and classified documents?

Mickai is a Sovereign Intelligence Operating System, a SIOS. It runs offline on operator-owned hardware, and retrieval, embeddings and inference all execute inside the operator's boundary with no external calls. Every action is cryptographically sealed to a post-quantum signed audit ledger under FIPS 204, and identity is hardware-attested and bound to that chain. The inbound perimeter is zero-egress by design, so a document indexed for search never becomes a copy on someone else's infrastructure.

The design is covered by 104 filed UK patent applications, approximately 2,340 claims, owned by Mickai LTD, filed and patent pending. For privileged and classified work the practical upshot is simple: the corpus stays where it is lawful for it to be, the index stays with it, and every answer carries proof of the source it came from.

Frequently asked questions

Can I use a public AI assistant for privileged legal documents?

No. Public cloud AI services send your text to the provider's own computers, and under the US CLOUD Act that provider can be compelled to disclose what it holds. For material under legal privilege or national classification, retrieval, embeddings and inference must all run inside your own perimeter on hardware you own.

Are embeddings safe to keep in the cloud if the source files stay on-premises?

No. Embeddings can be partially inverted to reconstruct the underlying text, so a cloud vector index leaks even when the original documents never leave your building. If the embedding step or the vector store is hosted, the sensitive content has effectively left the perimeter. Local embedding is not an optional extra.

What is a zero-egress RAG assistant?

A zero-egress assistant accepts incoming queries but sends no document text, embedding or model call out of the perimeter. You can verify it by disconnecting the network and confirming the assistant still answers from the classified corpus. If it stops working offline, it was relying on an external service and was never self-contained.

Does signed retrieval prevent hallucination?

It does not stop a model from generating a wrong sentence, but it makes any answer checkable. Signed retrieval binds each output to the specific source chunks and the model that produced it in an append-only, post-quantum signed ledger, so an unsupported answer is exposed on audit rather than trusted blindly. Cross-model consensus can be required for high-stakes outputs so several models must agree first.

Is on-premises RAG on its own enough for classified material?

On-premises retrieval is necessary but not sufficient. You also need local embeddings and local inference, a zero-egress perimeter, hardware-attested identity, and a signed audit ledger so provenance can be proved. On-premises storage paired with a cloud embedding or inference call still exports the very text you meant to protect.