Per-account key isolation, hardware-backed: the privacy architecture that closes the shared-key threat
Most encrypted platforms protect your data. Fewer isolate it. The distinction matters more than the marketing copy suggests, and it sits at the center of a privacy threat model that many buyers overlook when evaluating AI assistants. This post explains exactly how we built per-account key isolation with hardware-backed key wrapping, what class of attacks it closes, and where the boundaries of the protection lie.
Key Takeaways
- Every Selina account's data is encrypted under its own isolated key. A compromise of one account's key material exposes zero bytes of another account's data.
- Each per-account key is wrapped by a hardware-backed key service, meaning the wrapping key never exists in software memory in an unwrapped state on any general-purpose host.
- Vault files carry the same per-account isolation and use strong symmetric encryption. Files and transfers via SelinaSEND are end-to-end encrypted.
- Memory is encrypted at rest but is NOT end-to-end encrypted: a slice of each request reaches a frontier provider at inference time. We state this plainly because it bounds the threat model.
- This architecture does not prevent every attack. It closes the lateral-movement and shared-key-compromise classes. We describe what it does not close below.
What problem does shared-key encryption create?
A single encryption key protecting multiple tenants creates a blast radius equal to the entire tenant population. If an attacker recovers that key (via a memory dump, a misconfigured backup, a compromised operator), every account's data decrypts at once. This is the shared-key threat model, and it is not theoretical. It is the default architecture of most SaaS platforms, including most AI assistants, because it is simpler to operate.
The cost of that simplicity lands on you. Your data's confidentiality depends not just on the strength of the cipher but on the operational hygiene of every other tenant's key path. One weak link, one insider with access to the shared key, one unpatched key-management host, and the entire corpus is exposed.
Per-account key isolation eliminates lateral movement across accounts at the cryptographic layer. A compromised key yields exactly one account's data. The blast radius collapses from "everyone" to "one."
How does per-account key isolation work in Selina?
Each Selina account's data is encrypted under its own isolated key. That key is generated at account creation and is never shared with, derived from, or related to any other account's key. The keys are not stored raw. Each per-account key is wrapped (encrypted) by a hardware-backed key service before it touches persistent storage.
The wrapping works like this at a high level. A hardware security module (or equivalent hardware-backed key service) holds a wrapping key that never leaves the hardware boundary in plaintext. When Selina needs to encrypt or decrypt data for your account, the system sends your wrapped per-account key to the hardware service, which unwraps it inside the hardware boundary and returns the plaintext key to a short-lived, scoped process. That process performs the data-plane operation and discards the unwrapped key. The unwrapped key does not persist on disk, does not enter long-term memory on a general-purpose host, and is not logged.
We are deliberately not publishing the specific cipher suite, key lengths, or rotation schedule here. That is an operational-security decision, not an evasion. The design follows well-understood envelope-encryption patterns: a data-encryption key (DEK) per account, wrapped by a key-encryption key (KEK) held in hardware.
What about vault files?
Vault files use strong symmetric encryption with the same per-account isolation. The file DEK is wrapped under the same hardware-backed KEK path. If you upload a document to your Selina vault, it is encrypted under a key that belongs to your account alone. No other account's key can decrypt it, and no operator with access to the storage layer can read it without first unwrapping your specific DEK through the hardware service.
Files and transfers sent via SelinaSEND are end-to-end encrypted. The recipient's client performs decryption. We cannot read the payload in transit or at rest.
Why does hardware-backed key wrapping matter?
Software-only key management stores wrapping keys in memory or on disk on a general-purpose server. That server runs an operating system, a hypervisor, firmware. Each layer is an attack surface. A kernel exploit, a cold-boot attack, a rogue admin with SSH access: any of these can extract a software-stored wrapping key.
Hardware-backed key services change the trust boundary. The wrapping key lives inside a dedicated hardware module with a constrained interface. The module performs cryptographic operations internally and returns results. The key itself does not leave the module in plaintext. An attacker who compromises the host operating system, the hypervisor, or even the physical disk still cannot extract the wrapping key without defeating the hardware boundary, which is a fundamentally different (and harder) class of attack.
This does not make the system invulnerable. Hardware modules have had vulnerabilities (side-channel attacks, firmware bugs). But the attack surface is orders of magnitude smaller than a general-purpose OS, and the skill required is correspondingly higher. We are raising the cost of compromise, not claiming we have eliminated it.
What threat model does this architecture close?
Per-account hardware-backed key isolation closes three specific threat classes:
- Lateral key compromise. An attacker who recovers one account's DEK cannot use it to decrypt any other account's data. The blast radius is one account.
- Bulk extraction via shared-key theft. There is no single key whose compromise unlocks the entire data store. An attacker must compromise the hardware-backed KEK (defeating the hardware boundary) or individually compromise each account's DEK. Bulk extraction becomes a per-account operation, not a single theft.
- Insider access at the storage layer. An operator who can read raw ciphertext on disk sees data encrypted under per-account DEKs, each of which is wrapped by a hardware-held KEK. Reading the disk gives you nothing without the hardware service, and the hardware service enforces access policy independently of the storage system.
These are the classes we claim to close. We are specific about them because vague "military-grade encryption" claims are useless to you during a security review.
What does this architecture NOT protect against?
Honesty about limits is more useful to you than reassurance. Here is what per-account key isolation does not close:
Inference-time exposure. Memory is NOT end-to-end encrypted. When you interact with Selina, a slice of your request (including relevant memory context) is sent to a frontier provider for inference. That provider processes the plaintext of that slice during the inference window. We encrypt memory at rest, and we scope what is sent to what is needed for the current task, but we cannot claim that memory never leaves our encryption boundary. It does, at inference time. If your threat model requires that no third party ever sees any plaintext, our memory system does not satisfy that requirement. Files and SelinaSEND transfers are a different story (end-to-end encrypted, zero-knowledge), but memory is not.
Account-level compromise. If an attacker obtains your account credentials (phishing, credential stuffing, session hijacking), per-account key isolation does not help. The attacker authenticates as you, and the system correctly unwraps your DEK to serve "you." This is an authentication-layer problem, not a key-isolation problem. Strong passwords, two-factor authentication, and session hygiene are your defenses here.
Compromise of the hardware key service itself. If an attacker defeats the hardware boundary (a sophisticated, targeted attack), they can unwrap any account's DEK. We treat this as the highest-severity scenario and apply defense-in-depth around the hardware service, but we do not claim it is impossible. No hardware is.
Non-content operational metadata. Operational metadata (timestamps, request sizes, routing decisions) is retained for a short retention window for reliability and abuse-prevention purposes. This metadata is not encrypted under per-account DEKs because it is used by operational systems that must function across accounts. We minimize what is collected and bound how long it is retained, but it exists.
How is this different from full-disk encryption or database-level encryption?
Full-disk encryption (FDE) protects data against physical theft of the storage medium. Once the system is running and the disk is mounted, FDE is transparent: the operating system, applications, and any authenticated user can read all data on the disk in plaintext. FDE does not isolate tenants from each other or from operators.
Database-level encryption (transparent data encryption, or TDE) is similar. It protects the database files at rest, but the database engine itself operates on plaintext. Any query that the database authorizes returns plaintext results. If the database credentials are compromised, TDE offers no additional protection.
Per-account key isolation operates above both of these layers. Even if the disk is mounted and the database is running, each account's data remains encrypted under a key that only the hardware-backed key service can unwrap, and only for authorized operations scoped to that account. An operator with database-admin credentials sees ciphertext, not plaintext, unless they also have access to the hardware key service and the authorization to unwrap that specific account's DEK.
This is the practical difference: FDE and TDE protect against "someone stole the hard drive." Per-account key isolation protects against "someone compromised the running system but not the hardware key boundary."
Why not just use client-side encryption for everything?
Client-side encryption (where the key never leaves your device) is the gold standard for confidentiality. We use it for files and SelinaSEND transfers. For memory, it is not compatible with the product's core function.
Selina's memory exists so the assistant can recall context across conversations. That requires the system to read memory at inference time, retrieve relevant fragments, and include them in prompts sent to frontier models. If memory were encrypted with a key only your client held, the server could not read it, could not retrieve relevant fragments, and could not include them in inference. The assistant would have no memory.
You could imagine a scheme where the client decrypts memory locally, selects relevant fragments, and sends only those fragments to the server. This shifts the retrieval computation to the client, requires the client to be online and powerful enough to run retrieval over a potentially large memory corpus, and still results in plaintext fragments reaching the inference provider. It does not eliminate the inference-time exposure; it just moves where the decryption happens. We evaluated this architecture and concluded it added complexity without materially improving the threat model for memory. The inference-time exposure remains in both designs.
So we encrypt memory at rest under per-account keys, we scope inference payloads to what is needed, and we state plainly that memory is NOT zero-knowledge encrypted. That is the honest position.
How does key rotation work?
Key rotation is handled at the KEK layer. When a wrapping key is rotated in the hardware service, existing DEKs are re-wrapped under the new KEK. The data on disk does not need to be re-encrypted because the DEKs themselves do not change; only their wrapping changes. This makes rotation fast and non-disruptive.
DEK rotation (replacing the per-account data-encryption key itself) requires re-encrypting all of that account's data under the new DEK. We support this but do not perform it on a continuous schedule because the computational cost scales with data volume. It is triggered by specific events (which we do not enumerate here for operational-security reasons).
What does "protected account" mean versus "encrypted content"?
We draw a deliberate line in our terminology. Your account is protected. Your content is encrypted. The distinction is not cosmetic.
"Protected" means the account benefits from authentication controls, access policies, rate limiting, abuse detection, and the per-account key isolation described in this post. "Encrypted" means specific data (content in memory, files in the vault, transfers via SelinaSEND) is cryptographically encrypted at rest using per-account keys.
We do not say "your account is encrypted" because an account is more than its stored data. It includes authentication state, session tokens, metadata. Some of those elements are encrypted; others are protected by access controls rather than cryptographic encryption. Collapsing both into "encrypted" would be imprecise, and imprecision in security claims erodes trust.
How should you evaluate this during a security review?
If you are evaluating Selina for your organization, here are the questions this architecture answers and the ones it does not:
- Is tenant data cryptographically isolated? Yes. Per-account DEKs, hardware-wrapped.
- Can an operator read my data from the storage layer? Not without access to the hardware key service and authorization to unwrap your specific DEK.
- Is my data exposed to third parties? At inference time, yes. Memory context reaches a frontier provider during inference. Files and SelinaSEND transfers do not.
- Is metadata retained? Non-content operational metadata is retained for a short retention window.
- Does deletion mean deletion? Delete means gone. Actually gone. When you delete content, the ciphertext is removed from storage. Without the ciphertext, the DEK is useless. Without the DEK, the ciphertext is useless. Both conditions are satisfied on deletion.
If your threat model requires that no plaintext ever reaches any third party under any circumstances, including during inference, our memory system does not satisfy that requirement and we will not claim otherwise. If your threat model requires tenant isolation at the cryptographic layer with hardware-backed key protection, that is exactly what this architecture provides.
Why we built it this way
The simpler path is a shared key. One KEK, one key-management configuration, lower operational overhead. Most platforms take that path and describe themselves as "encrypted" without qualification. Technically accurate, practically incomplete.
We built per-account isolation because the shared-key blast radius is unacceptable for the kind of data an AI assistant holds. Your assistant knows your communication patterns, your file contents, your task history. A breach that exposes one account is bad. A breach that exposes every account because they share a key is catastrophic in a way that cannot be remediated after the fact. You cannot un-expose data.
Hardware-backed wrapping exists because software key storage is a known weak point in real-world breaches. Not theoretical ones. The ones that show up in post-incident reports. We wanted the wrapping key outside the software trust boundary, full stop.
The result is an architecture that is more expensive to operate and more complex to maintain than the alternatives. We consider that an acceptable trade. You probably do too, or you would not have read this far.
If you want to see it in practice: start a free 7-day trial, no card required.
