Signed retrieval: how do you prove which source an AI actually used?

You prove which source an AI used by sealing the retrieval, not the citation. Signed retrieval captures each retrieved chunk, the cryptographic hash of its source document and the exact context passed to the model, then seals all of it into a tamper-evident audit record at the moment the answer is produced. Because that record is cryptographically signed, an auditor can later reconstruct the precise evidence chain behind any output and verify it offline. This turns a citation from a claim the system makes about itself into evidence anyone can check.

This question has moved from a technical nicety to a procurement gate. In regulated work, an answer that cannot be audited is a liability, because the organisation carries the consequences of a wrong output without being able to show what produced it. Most retrieval augmented generation systems surface citations, but a citation is metadata the system asserts about itself. When a regulator, an auditor or a court asks which document actually drove a decision, self-asserted metadata is not proof. The 2026 market is pricing that gap.

Why is a normal AI citation not proof?

A footnote in a generated answer is a label the system attaches after the fact. Nothing binds it to the text the model actually read. The retrieved passage can change, the source document can be edited, and the citation still points at a name rather than a verifiable artefact. There is no way to show that the cited chunk is the chunk that shaped the output, and no way to detect whether the record was altered afterwards. In an audit, a citation you cannot reconstruct and verify is a claim, not evidence.

How does signed retrieval work?

Signed retrieval seals the evidence at the moment of generation. The mechanism is deliberately simple to verify:

• Each retrieved chunk is captured verbatim, exactly as passed to the model.
• The source document is hashed, so any later edit to that document breaks the match.
• The exact assembled context, the query and the model identity are recorded together.
• The whole record is sealed with a post-quantum digital signature into a tamper-evident ledger.

Because the seal happens at generation time and covers the real inputs, the record is not a description of what might have happened. It is the evidence itself, frozen and signed.

What exactly can an auditor check?

An auditor does not have to trust our word or the running system. They can take the sealed record and confirm, independently:

• that the cited source hash matches the document on file;
• that the retrieved chunk is present, unaltered, in that source;
• that the context shown to the model is the context recorded;
• that the signature is valid and the record has not changed since it was sealed.

Each of these is a yes or no test against cryptography, not a judgement call. If any check fails, the chain is broken and the answer is flagged. That is what we mean by an evidence chain: reconstructable, verifiable, and offline.

Which rules make this necessary?

Several regimes now expect an organisation to explain and evidence how an automated output was reached.

• The EU AI Act sets record keeping and traceability expectations for high risk systems. The Annex III high risk obligations once due on 2 August 2026 were deferred by the Digital Omnibus to 2 December 2027, with embedded Annex I high risk moved to 2 August 2028 and the Article 50 transparency duties largely unchanged. We read the deferral as a build window, not a reprieve.
• DORA, in force since January 2025, holds financial entities accountable for the resilience and traceability of their systems.
• NIS2 extends security and accountability duties across essential and important entities.
• GDPR gives people rights around solely automated decisions that have legal or similarly significant effects, including meaningful information about the logic involved.
• ISO/IEC 42001 formalises auditable governance for AI management systems.

In each case, proving the source behind an answer moves from good practice to something you must be able to demonstrate.

Why can a public cloud AI service not give you this?

Public cloud AI services are built to be used, not audited by the customer at the cryptographic level. The model, the retrieval layer and the logs sit on infrastructure the customer does not control, and under legislation such as the US CLOUD Act, data held on that infrastructure can be reachable by a foreign jurisdiction regardless of where it is stored. You can read a citation, but you cannot independently hash the source, reconstruct the exact context and verify a signed record offline, because you hold neither the keys nor the perimeter. This is a difference in architecture, not in intent. Proof of source requires that the evidence chain lives inside a boundary the operator owns.

How does a SIOS make this verifiable end to end?

Mickai is a Sovereign Intelligence Operating System, a SIOS. It runs offline on operator owned hardware with every action cryptographically sealed. Signed retrieval is one property of that design:

• A zero egress inbound perimeter means retrieved evidence and audit records never leave the operator's boundary.
• Hardware attested identity binds every sealed record to the machine and the actor that produced it.
• The audit ledger is signed with post-quantum standards, so the seal stays verifiable as cryptography advances. FIPS 204 (ML-DSA) is the primary signature standard, alongside FIPS 205 (SLH-DSA); these sign and verify the ledger. FIPS 203 (ML-KEM) handles key encapsulation and never signs.
• Cross model consensus lets more than one sovereign model answer, so an output can be corroborated rather than taken on trust.

The approach sits within a body of work covering 104 filed UK patent applications, approximately 2,340 claims, owned by Mickai LTD; never granted or patented. The point for a buyer is plain: the evidence behind an answer can be reconstructed and verified offline, by them, without trusting the vendor.

“An answer is only as trustworthy as the evidence you can independently reconstruct and verify behind it.”

Frequently asked questions

What is signed retrieval in AI?

Signed retrieval is a method that seals the evidence behind an AI answer at the moment it is produced. Each retrieved chunk, the hash of its source document and the exact context sent to the model are recorded together and signed into a tamper-evident ledger. The result is that the source of an answer can be reconstructed and cryptographically verified later, rather than merely cited.

Can you prove which document an AI used without trusting the vendor?

Yes, if the evidence chain is sealed and signed rather than asserted. An auditor takes the signed record and checks the source hash, the retrieved text and the signature independently, offline. Because each check is a cryptographic yes or no, the proof does not depend on trusting the system that produced the answer.

Does an AI citation count as evidence in an audit?

On its own, no. A citation is metadata the system attaches to its own output, and nothing binds it to the text the model actually read. It becomes evidence only when it is backed by a sealed, verifiable record showing that the cited chunk is the chunk that shaped the answer and that the record has not been altered.

Which post-quantum standard signs the audit ledger?

FIPS 204 (ML-DSA) is the primary digital signature standard used to seal and verify the ledger, alongside FIPS 205 (SLH-DSA). FIPS 203 (ML-KEM) is a key encapsulation standard and never signs anything. When you need proof that a record is authentic and unaltered, the signature standards are what matter.

Does the EU AI Act require proof of which source an AI used?

The EU AI Act sets record keeping and traceability expectations for high risk systems. The Annex III high risk obligations once due on 2 August 2026 were deferred by the Digital Omnibus to 2 December 2027, with embedded Annex I high risk moved to 2 August 2028 and Article 50 transparency duties largely unchanged. We read this as a build window: the ability to prove sources will be expected, so it is better designed in now.