By Micky Irons, founder and CEO of Mickai.
Sealed end to end means one thing: the prompt, the retrieval over your private data, the inference and the returned output all happen inside a single hardware-attested boundary, and nothing crosses that boundary to an outside service. It holds because the perimeter is built to accept inbound requests only and to make no outbound connections at all, so no stage can quietly forward text, embeddings or logs to a third party. Every action inside the boundary is signed against a hardware-bound identity, so a sealed run is not a claim you take on trust. It is a record you can verify after the fact.
This matters in 2026 because most enterprise assistants are not sealed. In a typical hosted setup the model call is one hop, but retrieval, telemetry, safety filtering and logging are separate hops to separate services, often in another country. Each hop is a place where regulated data leaves your control. Regulated buyers in finance, health, defence and government now have to prove where data went, not merely promise it stayed put. Sealed end to end is the architecture that makes that proof possible.
What does sealed end to end actually mean?
It means four stages that are usually distributed are collapsed into one attested boundary. The prompt is read locally. Retrieval runs against your private index on the same hardware. Inference runs on a sovereign model held on that hardware. The output is composed and returned without ever leaving. Mickai is a Sovereign Intelligence Operating System, a SIOS, and it runs offline on operator-owned hardware with every action cryptographically sealed. Sealed is not a marketing word. It is a measurable property of the run.
How does it work stage by stage?
Each stage is bound to the same perimeter and the same identity.
- Prompt: the request enters through a zero-egress inbound perimeter. Data can come in. Nothing initiates a connection out.
- Retrieval: the search over your documents happens against a local index. Your files, chunks and embeddings never transit an external vector service.
- Inference: a sovereign model runs on the operator's own hardware. There is no remote model endpoint to call.
- Output: the answer is assembled and returned inside the boundary, and the whole run is written to a signed audit ledger.
Because no stage is allowed to reach out, there is no silent side channel where retrieval or logging leaks to somewhere else.
How is a hosted setup different?
A hosted assistant looks like one system to the user, but underneath it is a chain of external services. The prompt goes to a model API. Retrieval calls a hosted vector database. Telemetry and safety checks call further endpoints. Logs land in a provider's storage. Any of those hops can sit in a different country and under a different legal regime. The point is architectural, not a claim about any provider: in a hosted design your data crosses several boundaries you do not control, and you cannot prove it did not. Sealed end to end removes those hops entirely.
A system is sealed only when the prompt, the retrieval, the inference and the output can all be shown to have stayed inside one attested boundary, and nothing had the ability to leave it.
What can an auditor actually check?
An auditor should not have to accept assurances. A sealed boundary produces evidence. There are concrete tests to run.
- Egress test: place the boundary under network monitoring and confirm zero outbound connections during a full prompt-to-output run.
- Attestation check: verify that the hardware identity in the audit record matches the machine that served the request.
- Ledger integrity: confirm the audit ledger is a post-quantum signed chain, where each entry is signed and tamper-evident, using signature schemes aligned with FIPS 204 (ML-DSA).
- Offline verification: replay the ledger with the machine disconnected from any network and confirm the signatures still validate.
If any stage had reached out, the egress test catches it. That is the difference between a promise and a proof.
Which rules make this necessary?
Several regimes now push in the same direction. DORA has been in force since January 2025 and holds financial entities accountable for the resilience and traceability of third-party ICT, including AI services. NIS2 raises the same bar for essential and important sectors. GDPR still governs where personal data may be processed and transferred. The US CLOUD Act means data held by a US-connected provider can be compelled regardless of where the server sits, which is precisely the exposure a sealed offline boundary removes. On the EU AI Act, the high-risk Annex III obligations once expected on 2 August 2026 have been deferred by the Digital Omnibus to 2 December 2027, with embedded Annex I high-risk moving to 2 August 2028 and Article 50 transparency duties largely unchanged. We read that as a build window, not a reprieve. ISO/IEC 42001 gives buyers the management-system language to demand this now.
Why can a sealed boundary carry sensitive workloads that a public service cannot?
Public AI services are capable, but a regulated buyer often cannot send the underlying data to them, because doing so exports it to infrastructure outside the buyer's control and possibly outside the jurisdiction. A sealed SIOS keeps the data on hardware the operator owns and can point to on a floor plan. Identity is hardware-attested and bound to the audit chain, so the record shows which machine did what. Cross-model consensus can run several sovereign models against the same task inside the boundary and compare their outputs, without any of them being a remote call. The capability is described in Mickai LTD's estate of 104 filed UK patent applications and approximately 2,340 claims, owned by Mickai LTD, patent pending and never granted or patented.
Frequently asked questions
What is the difference between sealed end to end and a private cloud deployment?
A private cloud deployment still relies on a provider's control plane, and retrieval, logging or telemetry can reach services outside your instance. Sealed end to end runs on hardware the operator owns, with a zero-egress perimeter, so no stage can leave the boundary. The test is simple: monitor the network during a full run and check for outbound connections.
Can a sealed system still be audited if it never connects to the internet?
Yes, and offline is the stronger position. The audit ledger is a post-quantum signed chain held on the machine itself, so an auditor can replay and verify every entry with no network at all. Hardware attestation ties each record to the specific machine that served the request. Verification does not depend on a vendor being online.
Does keeping retrieval local hurt answer quality?
No. Retrieval quality depends on the index and the model, not on where they physically run. Keeping retrieval inside the boundary means the system can search sensitive documents that could never be uploaded to a hosted vector service, so in regulated settings a sealed system often answers questions a hosted one is simply not allowed to touch.
Is 2 August 2026 still the EU AI Act high-risk deadline?
No. The Digital Omnibus deferred the Annex III high-risk obligations to 2 December 2027, with embedded Annex I high-risk moving to 2 August 2028 and Article 50 transparency duties largely unchanged. We treat the extra time as a build window rather than a reprieve, because the underlying obligation to prove where regulated data went does not go away.
How do we prove to a regulator that no data left the boundary?
Run three checks. First, network monitoring across a full prompt-to-output run to show zero egress. Second, an attestation check confirming the hardware identity in the audit record matches the serving machine. Third, an offline replay of the signed ledger to confirm integrity. Together these turn a claim into checkable evidence a regulator can accept.
Written by Micky Irons. Originally published at https://mickai.co.uk/articles/sealed-end-to-end-prompt-retrieval-inference-output-inside-one-boundary. More from Micky Irons and Mickai at mickai.co.uk.
Top comments (0)