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.
Scope inference, extraction, retrieval and storage on infrastructure you control. Document and test any external connector, support channel or transfer before describing a workflow as zero-egress.
Workflows with local models, data and supporting services can continue offline. Live external email, calendars and other services need an approved connection or controlled import, with clear unavailable and pending states.
Map prompts, documents, indexes, logs and backups to their processing and storage locations. Local hosting supports control of location; access, retention and any transfers still need review.
Prepare and classify source records, preserve permissions and evaluate answers against the originals. Retrieval and model training are separate choices; agree data use and licences for each.
Compare hardware and licences alongside integration, power, administration, support, updates, evaluation and recovery. Measure cost at the required workload and quality before claiming savings.
Define who holds keys, who can administer the system and which actions need approval. Test denied requests, revoked access and audit records. Physical security, insider risk and incident response remain operational responsibilities.
Agree version selection, signed update procedures, rollback, data export and licence rights. Reassess requirements as software and obligations change; owning hardware does not remove maintenance or compliance work.
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.