Tenant-Isolated Multi-User Sovereign AI
Many departments or clients on one owned machine, with cryptographic walls, per-tenant governance and no shared cloud tenancy risk
Every regulated organisation eventually asks the same question about artificial intelligence. Can we let several departments, or several clients, share one powerful machine without one leaking into another? In the public cloud the honest answer is that you are trusting someone else's tenancy boundary, someone else's patch cycle and someone else's log. For a bank, a hospital or a defence contractor, that is a leap of faith the regulator will not accept.
Mickai answers this differently. As a Sovereign Intelligence Operating System, a SIOS, we run many tenants on hardware the customer owns, with cryptographic walls between them and a signed record of every action. One instance, many isolated worlds, zero shared cloud tenancy. Here is how that works and why it matters.
The problem with shared cloud tenancy
When you rent intelligence from a hyperscaler, your data sits beside thousands of other customers on infrastructure you cannot inspect. The provider promises logical separation, and for most workloads that promise is sound. But regulated boundaries are not most workloads. Under the General Data Protection Regulation (GDPR), the EU Artificial Intelligence Act (the EU AI Act), the Digital Operational Resilience Act (DORA) and the Health Insurance Portability and Accountability Act (HIPAA), you remain accountable for data you can no longer see, on a substrate you cannot audit line by line.
The cloud giants are allies, and for elastic public workloads they are unmatched. We do not compete with that layer. We serve the boundary it was never designed to cross: the moment when a customer must prove, to a regulator or an auditor, exactly where a decision happened, who approved it and that no other tenant could ever have touched the underlying data. That proof is what shared tenancy cannot give you on your own terms.
One owned instance, many sealed tenants
Mickai runs on hardware the customer owns, air-gapped or on-premise, with zero data egress. On that single owned instance we host multiple tenants: a legal department and a trading desk inside one bank, or several separate client organisations inside a managed service provider. Each tenant is a sealed world with its own data stores, its own brains and its own governance rules.
Isolation here is not a shared setting toggled per customer. Each tenant's data is cryptographically segregated, its brains are scoped so they cannot read across the wall, and its working memory never mingles with another tenant's. Because everything lives on infrastructure the customer physically controls, there is no multi-tenant hypervisor owned by a distant provider standing between two clients. The boundary is yours, on metal you can point at.
Brains you can scope and revoke
Intelligence inside Mickai is delivered by brains, our revocable subsystems of capability. A tenant is granted exactly the brains its role requires and no more. A compliance brain for the legal team, a pricing brain for the trading desk, a clinical brain for a hospital ward. Each brain is bound to its tenant and cannot be summoned across the isolation wall.
Because brains are revocable, a tenant's access can be withdrawn instantly and provably. If a client contract ends, if a department is restructured, or if an incident demands containment, the relevant brains are revoked and the revocation itself is recorded in the ledger. There is no residual capability sitting dormant in a shared model, because there is no shared model reaching across tenants in the first place.
Every action attested before it runs
The heart of Mickai governance is the Operation Attestation Record (the OAR). Before any action executes, whether that is reading a record, generating a document or moving a file, an OAR is produced and cryptographically signed. The action does not run until it has been attested. This inverts the usual order. Instead of logging what already happened, we sign what is about to happen and gate the action on that signature.
Signatures use post-quantum cryptography, specifically the Federal Information Processing Standard 204 (FIPS 204) Module-Lattice Digital Signature Algorithm, ML-DSA-65. That means an attestation you sign today remains verifiable long after a future quantum computer would have broken older schemes. Each attestation is stamped with its tenant, so an auditor can prove a given action belonged to one tenant and could not have originated in another. This capability sits inside the same body of work as our 104 filed UK patent applications, covering about 2,340 claims and owned by Mickai LTD.
Per-tenant governance and a tamper-evident ledger
Isolation is only half the story. The other half is that each tenant carries its own governance and its own audit trail. Every tenant writes to a tamper-evident, cryptographically-signed audit ledger scoped to that tenant alone. The legal department's auditors see the legal department's ledger and nothing else. A client of a managed service provider sees their own chain of custody, verifiable independently, without exposure to any other client on the same machine.
Because the ledger is cryptographically signed, tampering is detectable by anyone holding the public verification keys. And because verification is offline, an auditor does not need to call home to us or to any cloud to confirm that the record is intact. They can validate the entire chain on an air-gapped machine, which is precisely what DORA operational-resilience testing and an EU AI Act conformity assessment want to see.
High-stakes actions need more than one key
Some actions are too consequential to trust to a single approval. Releasing a patient's records, executing a large trade, transferring data across a boundary. For these, Mickai requires multi-brain approval combined with voice-biometric confirmation. More than one brain must independently attest the action, and a named human must confirm by voice before the OAR is sealed and the action proceeds.
This matters enormously in a multi-tenant setting. It means no single compromised credential inside one tenant can trigger a high-stakes action, and it means the human accountability required under HIPAA, GDPR and the International Traffic in Arms Regulations (ITAR) is captured as biometric evidence, tenant by tenant. The approval is bound to the tenant, the person and the moment, and it is quantum-safe.
The bottom line
Running several departments or several clients on one machine has always meant choosing between the economics of sharing and the safety of separation. Mickai refuses that trade-off. On hardware the customer owns, we give each tenant a sealed world, scoped and revocable brains, an attestation signed before every action, and a tamper-evident ledger the tenant can audit offline and alone.
There is no shared cloud tenancy to trust, no distant hypervisor to inspect and no faith required. Just cryptographic walls on metal you control, and a signed record that proves, to any regulator, that one tenant never touched another. That is what sovereign multi-tenancy looks like when it is built to be proven, not merely promised.




