Multi-tenant isolation and access control
Multi-tenant isolation lets one device serve several tenants, such as a clinical, an enterprise and an individual context, with cryptographic separation between them so nothing leaks across the boundary. Tenant switching is voice-gated and biometric-attested, ledger entries are partitioned per tenant, and access control descends to the row and column of a data store, gated per voiceprint rather than per shared username. Skills are gated behind five clearance levels with sessions that stale and require fresh re-authentication, so a forgotten unlocked terminal cannot be used to reach sensitive capability.
Wherever one system serves more than one context, whether that is a clinician moving between a hospital tenant and a private one, or a firm holding several clients on one deployment, the danger is cross-tenant leakage: data or a decision from one context bleeding into another, which for personal and clinical data is a direct GDPR and confidentiality breach. Shared cloud multi-tenancy places the isolation boundary inside the vendor's infrastructure, where the customer cannot inspect it and where a misconfiguration or a shared-model side channel can expose one tenant to another, and access is typically gated per username, which a shared or forgotten login undermines. Regulated buyers need isolation they can prove and access control fine enough to reflect who may see which specific record, tied to the actual person rather than a reusable credential. Mickai provides this on hardware you own: the Adaptive Multi-Tenant OS gives cryptographic isolation between tenants with per-tenant ledgers, tenant switching is voice-gated and biometric-attested so a move between contexts cannot silently carry data across, access control reaches the row and column and is gated per voiceprint, and skills sit behind clearance levels with staling sessions. Because it all runs inside your perimeter and every access is sealed to the Open Audit Record, isolation is both enforced and demonstrable.
The 5 controls in this domain, each enforced by construction on hardware you own and mapped to the subsystem that provides it.
Cryptographic Tenant Isolation
The Adaptive Multi-Tenant OS lets a single device serve clinical, enterprise and individual tenants with cryptographic isolation between them, so data and decisions from one context cannot bleed into another. The isolation boundary sits inside your own perimeter where you can prove it, rather than inside a vendor's shared infrastructure where you cannot inspect it. This closes the cross-tenant leakage risk that is a direct GDPR and confidentiality breach for personal and clinical data. Tenant isolation is anchored in the filed Adaptive Multi-Tenant OS patent.
Voice-Gated Tenant Switching
Switching from one tenant to another is voice-gated and biometric-attested, so a clinician moving from a hospital tenant to a private tenant cannot accidentally carry data across the boundary. The switch requires a fresh, on-device voice match against a hardware-bound template, which makes the transition a deliberate, verified act rather than a silent context change. This closes the everyday leakage route where a user forgets which context they are in and mixes regulated data. The voice-gated switch is anchored in the filed Adaptive Multi-Tenant OS patent.
Per-Tenant Partitioned Ledgers
Audit-record entries are partitioned per tenant, so each tenant has its own signed ledger and records from different contexts never commingle. This means an auditor for one tenant sees exactly that tenant's activity and nothing from another, which preserves confidentiality and keeps the evidence clean per context. Partitioned ledgers also make it straightforward to demonstrate isolation, because the separation is visible in the record itself. The per-tenant partitioning builds on the Adaptive Multi-Tenant OS and the Decision Lineage ledger design.
Row And Column Access Control
Access control in Mickai descends to the row and column of a data store and is gated per voiceprint rather than per username, so authorisation reflects who may see which specific record rather than a coarse, reusable login. When a voiceprint is revoked, for example when an employee departs or an account is compromised, previously authorised reads are retroactively flagged in the ledger and the actor is excluded from any future composition. This gives the fine-grained, person-tied access control regulated data needs. It is anchored in the filed Granular Row and Column ACL patent.
Clearance-Gated Skill Execution
Deployable agent capabilities are gated behind five clearance levels, and sessions stale after configurable intervals so that resuming any gated skill requires a fresh verbal re-authentication. A forgotten, unlocked terminal therefore cannot be used to invoke a sensitive skill, even by a legitimate but absent operator, which closes the walk-away exposure that ordinary session timeouts leave open. The clearance model maps cleanly to standard classification levels for defence and government use. It is anchored in the filed Per-Skill Clearance-Gated Execution patent.
The advantages hold across every control domain, and they are architectural, not promotional. The third-party cloud-exposure vector is removed; your own physical, insider and compliance controls remain yours.
The data never leaves your hardware, so no third party and no cloud-provider employee ever sees it. What happens in the server room stays in the server room.
You own the compute and the capability, so the system runs independent of the internet and of any cloud vendor's pricing, terms, or availability.
The data never crosses a geographical or digital border because it never leaves the building, which removes the cross-border-transfer and third-party-processing friction of UK GDPR, Schrems II, and the sector rules. You keep your own obligations.
Fine-tune and run retrieval on your deepest archives to build a hyper-customised co-pilot, with no risk of your proprietary edge training a public model or leaking.
After the hardware and licence, queries cost essentially electricity. A capital asset you own and depreciate, instead of volatile per-token cloud bills.
There is no third-party cloud path, so no competitor and no vendor insider can scrape, intercept, or subpoena your prompts or your fine-tuned weights from the internet. The trust vault is closed by architecture.
You own the software snapshot on your own hardware, so a change to a cloud vendor's terms, a model deprecation, or an outage cannot reach you. The system stays predictable and auditable on-premise as the rules evolve.
How does Mickai keep tenants isolated on one device?
The Adaptive Multi-Tenant OS lets a single device serve clinical, enterprise and individual tenants with cryptographic isolation between them, so data and decisions from one context cannot bleed into another. The isolation boundary sits inside your own perimeter where you can prove it, rather than inside a vendor's shared infrastructure where you cannot inspect it. This closes the cross-tenant leakage risk that is a direct GDPR and confidentiality breach for personal and clinical data, and it is anchored in the filed Adaptive Multi-Tenant OS patent.
How does tenant switching avoid leaking data across contexts?
Switching from one tenant to another is voice-gated and biometric-attested, so a clinician moving from a hospital tenant to a private tenant cannot accidentally carry data across the boundary. The switch requires a fresh, on-device voice match against a hardware-bound template, which makes the transition a deliberate, verified act rather than a silent context change. This closes the everyday leakage route where a user forgets which context they are in and mixes regulated data.
Are audit records kept separate per tenant?
Yes. Audit-record entries are partitioned per tenant, so each tenant has its own signed ledger and records from different contexts never commingle. An auditor for one tenant sees exactly that tenant's activity and nothing from another, which preserves confidentiality and keeps the evidence clean per context. Partitioned ledgers also make it straightforward to demonstrate isolation, because the separation is visible in the record itself.
How fine-grained is access control?
Access control descends to the row and column of a data store and is gated per voiceprint rather than per username, so authorisation reflects who may see which specific record rather than a coarse, reusable login. When a voiceprint is revoked, previously authorised reads are retroactively flagged in the ledger and the actor is excluded from any future composition. This gives the fine-grained, person-tied access control regulated data needs, and it is anchored in the filed Granular Row and Column ACL patent.
What stops a forgotten unlocked terminal being misused?
Deployable agent capabilities are gated behind five clearance levels, and sessions stale after configurable intervals so that resuming any gated skill requires a fresh verbal re-authentication. A forgotten, unlocked terminal therefore cannot be used to invoke a sensitive skill, even by a legitimate but absent operator, which closes the walk-away exposure that ordinary session timeouts leave open. The clearance model maps cleanly to standard classification levels and is anchored in the filed Per-Skill Clearance-Gated Execution patent.
Why is on-premise isolation stronger than cloud multi-tenancy?
Shared cloud multi-tenancy places the isolation boundary inside the vendor's infrastructure, where the customer cannot inspect it and where a misconfiguration or a shared-model side channel can expose one tenant to another, and access is usually gated per username. Mickai instead runs on hardware you own, with cryptographic tenant isolation you can prove, per-tenant ledgers, voice-gated switching and per-voiceprint access control, all sealed to the Open Audit Record. Isolation is therefore both enforced and demonstrable rather than taken on trust.
Review the multi-tenant isolation and access control controls with us.
Briefings are for organisations weighing a sovereign, on-premise deployment. Tell us about your estate and threat model and we will walk the controls, the attestation surface and the deployment that fits.