Operational Impact
- Regulated operators and technical reviewers can approve shared inference faster when tenant isolation is provable on-box.
- Security teams reduce cross-tenant exposure by binding access control to adapter cryptography.
- Compliance reviews become easier when provenance is attached to every inference receipt.
- ITAR and classified deployments can run without external IAM or network dependencies.
Multi-tenant inference is an economic necessity. Dedicated hardware per customer is wasteful in the same way dedicated mail servers per customer were wasteful in the 1990s—it works, it is simple to reason about, and it does not scale. Shared infrastructure is how you make inference affordable enough to deploy widely. But sharing introduces a problem that single-tenant systems never have to solve: proving that one tenant's data, models, and outputs cannot leak to another.
In cloud environments, this isolation is typically provided by the infrastructure layer—separate VMs, network segmentation, IAM policies, encrypted storage with per-tenant keys. The inference system itself does not enforce isolation; it trusts the platform to do so. This trust delegation is reasonable when the platform is a major cloud provider with a compliance program, and less reasonable when the deployment target is an air-gapped facility, an edge device, or a classified network where the "platform" is whatever the customer happened to install.
The Adapter as Isolation Unit
In an adapter-routed architecture, the natural isolation boundary is the adapter. Each tenant's specialized capability is encoded in an adapter—a relatively small set of weights that modifies the behavior of a shared base model. The base model is common infrastructure. The adapters are tenant-specific intellectual property.
This separation has a useful geometric property. The base model is large, expensive, and shared. The adapters are small, cheap, and private. Isolating adapters is a tractable problem in a way that isolating entire model deployments is not. You do not need separate GPU memory pools, separate inference processes, or separate hardware. You need to ensure that adapter A is never loaded during a request that belongs to tenant B, and that the weights, metadata, and outputs associated with each adapter are cryptographically bound to the tenant that owns them.
What "Sealed" Means
A sealed adapter is a binary container that includes the adapter weights, metadata (version, training provenance, supported input formats), and a cryptographic integrity hash computed over the entire contents. Before the system loads an adapter, it verifies the integrity hash. If the hash does not match—because the file was modified, corrupted, or tampered with—the adapter is rejected and the inference request fails rather than proceeding with compromised weights.
This integrity check is not novel in isolation. Software signing has existed for decades. What makes it consequential in this context is that the integrity hash is bound into the cryptographic receipt for every inference run that uses the adapter. The receipt does not just say "adapter X was used." It says "adapter X with integrity hash Y was used," and a verifier can confirm that the hash corresponds to a specific, unmodified set of weights.
If an adapter is updated—retrained, fine-tuned, quantized differently—the integrity hash changes. The receipts produced before and after the update are distinguishable. An auditor can verify that a specific inference result was produced with a specific version of a specific adapter, not merely with "some version" of it.
Per-Tenant Cryptographic Binding
Beyond integrity verification, multi-tenant isolation requires access control: tenant A's adapters must be inaccessible to tenant B's inference requests. In a system designed for air-gapped deployment, this access control cannot depend on a network identity provider or a cloud IAM service.
The approach is filesystem-level separation combined with cryptographic access controls. Each tenant's adapters and receipts are stored in a directory structure that is encrypted with tenant-specific keys. The inference system authenticates the tenant, derives the appropriate key, and decrypts only the adapters associated with that tenant's request. Adapters belonging to other tenants remain encrypted and inaccessible for the duration of the inference run.
The receipt for each inference run is encrypted with the same tenant-specific key, ensuring that inference outputs are as isolated as the adapters that produced them. Tenant A cannot decrypt tenant B's receipts, even if both tenants' data resides on the same physical storage.
What Regulated Organizations Need
ITAR-controlled facilities, classified networks, and healthcare environments share a common constraint: data must not leave its designated boundary, and the boundary must be enforceable without trusting external services. A multi-tenant inference system operating in these environments cannot call home to verify permissions, cannot rely on a cloud key management service, and cannot assume that network segmentation is correctly configured by someone else.
Sealed adapters with per-tenant cryptographic binding provide isolation guarantees that are intrinsic to the inference system rather than delegated to the infrastructure. The system enforces its own tenant boundaries using cryptographic primitives that work identically whether the hardware sits in a data center, an aircraft maintenance facility, or a disconnected field deployment.
This does not eliminate the need for operational security. Physical access control, key management procedures, and personnel security remain essential. What it eliminates is the assumption that the infrastructure layer is correctly configured and that nobody has misconfigured a network rule, left a storage bucket accessible, or accidentally shared a decryption key across tenant boundaries. The cryptographic enforcement operates at the application layer, independent of infrastructure configuration.
The Receipt as Isolation Evidence
When a compliance officer needs to verify that tenant data was properly isolated during an inference run, the receipt provides the evidence. The receipt identifies which adapter was loaded, confirms its integrity hash, and documents that the adapter was decrypted with the appropriate tenant key. If the receipt exists and validates, the adapter was loaded from a sealed container with the correct tenant binding. If it does not validate, something went wrong, and the receipt itself serves as the forensic artifact.
This is a stronger evidentiary standard than log analysis, which requires trusting that the logs were not modified, that the logging was comprehensive, and that the log entries accurately reflect what the system actually did. The receipt is a cryptographic commitment to the computation that was performed. It goes beyond describing what should have happened; it provides cryptographic proof of what did happen.