The isolation primitive for multi-tenant AI
Isolation
you can prove.
Confidential AI serving for sovereign, regulated, and multi-tenant deployments. Isolation you can prove, not just promise, on commodity hardware with no foreign hardware root of trust. Because tenants can safely share one model, serving runs faster and costs less.
Sharing model state across tenants leaks. That is why safe multi-tenant sharing has meant an enclave per tenant, or not sharing at all. isovert makes shared serving provably safe, in software.
1000 tenants · one model · commodity hardware.
What it unlocks
Three things safe sharing makes possible
Share one model across tenants, safely.
MHA · GQA · MLA + state-space (SSM) + trained hybrids
Provable per-tenant isolation, validated across every major model architecture: the transformer KV designs in production today, and across the class boundary into the state-space and hybrid models the field is adopting.
Scope: representative models per architecture class, single hardware configuration.
Lower serving cost.
Cold-start reduced up to ~80×
Because tenants safely share one warm model, transformer serving cold-start drops sharply. Measured up to ~80× on production GPU serving (vLLM, A100), scaling with prefix length. This is a consequence of safe sharing rather than a standalone product.
Scope: transformer serving, single node, eager execution path. Validating at fleet scale with design partners.
See the serving-cost storyCatch prompt-injection attacks.
~91% detection · AUC 0.978 (AgentDojo)
Activation-based monitoring flags real third-party injection attempts for review, adding an advisory line of defense to multi-tenant agents.
Scope: advisory, human-in-the-loop, single model. It detects. It does not prevent, and it does not stop an adaptive attacker.
All of it is provable. Machine-checked proofs (Lean 4 + Verus), data authenticated at rest by construction (AES-GCM, bound to tenant, slot, and context), and 16 filed inventions behind it.
Positioning
Between policy and hardware
Isolating tenants has meant choosing between two imperfect options.
Software policy
Namespaces, RBAC, tenant-id filters. Cheap and portable, but enforcement-based. One missed check and tenants leak into each other, silently.
isovert
Tenant isolation as a structural property with a machine-checked proof behind it. Runs on commodity hardware and composes with the TEEs you already run. The assurance of a structural boundary without an enclave per tenant.
Hardware
Trusted execution environments. Strong host-level isolation, but a certified-hardware dependency, and in practice one enclave per tenant. A cost wall that doesn’t scale.
isovert doesn't replace the host boundary. It adds the per-tenant layer that policy can't reliably enforce and hardware has made expensive.
Architecture breadth
Validated across
every major architecture
Validation crosses the architecture-class boundary into hybrid and state-space models. Isolation that already works on what comes next.
Transformer attention
Validated across the major KV-cache designs in production today: MHA, MQA, and GQA.
State-space / SSM
Carried across the architecture-class boundary into state-space models, a class outside transformer attention entirely.
Hybrid models
Demonstrated on a trained hybrid that mixes attention and state-space blocks, the direction frontier models are heading.
Scope: tested on representative models per architecture class, on a single hardware configuration.
Properties
Structural
per-tenant isolation
Software-defined
No foreign hardware root of trust required. Isolation is enforced in software and composes with hardware where you have it.
Commodity hardware
Runs on the machines you already have. No special hardware required.
Provable on demand
Isolation you can audit at any moment during operation, not only at startup.
Key-drop delete
Drop the key that encrypts a tenant’s data and it becomes unrecoverable. Deletion you can demonstrate.
Authenticated at rest
Every stored vector is encrypted and authenticated with AES-GCM, bound to its tenant, slot, and context. A wrong-tenant or wrong-slot read fails the authentication tag and is rejected by construction, before any data is returned.
Composes with your stack
Sits inside the TEEs you run, and is designed to compose with a post-quantum (ML-KEM) key layer. It complements those boundaries rather than replacing them.
Attacker-tested
Evaluated under adversarial conditions across 1000 tenants sharing one model. Scope: correctness on a single hardware configuration.
The surface
Four calls
Key binding lives at the session layer — never an argument a model can supply. The isolation boundary sits below the application, where it can't be reasoned around.
01ctx = isovert.TrustContext(key=tenant_key)02ctx.bind(data)03ctx.run(query) # operates inside the isolated context04ctx.delete() # key-drop delete: drop the keyThe stack
One substrate.
Products on top.
NablaDB
in developmentConfidential multi-tenant retrieval
Llamesh
earlyIsolated multi-agent platform
From Cittela, a deep-tech research entity.
Proofs & verification
Don't trust. Verify.
Reviewed prior to publication by independent practitioners. Reproducible. Open.
Who it's for
Regulated multi-tenant AI platforms
Demonstrate tenant segregation to auditors and customers without one enclave per tenant.
Sovereign / national cloud
Provable isolation without depending on a foreign hardware root of trust.
Confidential-computing teams
The per-tenant layer of confidential computing, in software. Isolate tenants inside the trusted boundary you already run — composing with your TEEs and key management, and adding the tenant-level isolation that one-enclave-per-tenant makes expensive.