.png){kind=logo}
Operator exclusion: remove the access paths instead of watching them
Every conventional control assumes someone privileged can ultimately read the workload. enclaive removes that access structurally: workloads also stay encrypted while they run, and keys release only against proof of integrity.
Enforced in hardware, verified by attestation — not promised by policy.
Ask who can technically read your crown-jewel workloads and the honest inventory is longer than anyone likes: cluster admins, cloud operators, hypervisor layers, backup operations, on-call engineers, database administrators — each one a legitimate function, and each one a path a breach can travel.
Too many admin pathways
Privileged access accumulates: every platform, every managed service, every operational role adds paths to workload data. Each is individually justified. Together they form the attack surface that decides whether an intrusion becomes a material event.
Monitoring watches; it doesn't prevent
PAM governs who may use privilege, SIEM records that it was used, EDR flags how. None of them makes workload data unreadable to legitimate access — and stolen credentials are, by definition, legitimate access.
The blast-radius problem
When a privileged account falls, everything it can read falls with it. That multiplication — one credential, all the data — is what separates an incident report from a breach notification, a board escalation and a regulator's file.
The mechanism is simple to state: make workload data unreadable to every path except one, and make that one path conditional on proof. Likelihood drops because credentials stop being enough; blast radius drops because what a compromised path can read approaches zero.
Sensitive systems execute inside hardware-sealed environments with memory encrypted during processing. Admins, hypervisors and provider staff see ciphertext — the third leg of encryption that at-rest and in-transit never covered.
Decryption keys live in a customer-held virtual HSM and are handed over only to workloads that cryptographically prove they're genuine and unmodified. A stolen credential can't fake a valid runtime — no attest, no key.
Access binds to attested workload identities with least-privilege scopes and time-bound credentials — not to humans and long-lived secrets. The credentials worth stealing stop existing.
For managed Kubernetes, pods run encapsulated as confidential VMs and control-plane access paths are reduced — the cluster admin's reach ends at the pod boundary instead of inside it.
The entries below sit on most registers for years, treated with monitoring and process because nothing structural existed. This is how the residual-risk line changes when readable access is removed.
Framing is illustrative for risk-owner discussion, not a quantified guarantee — your likelihood and impact scales are yours. The assessment worksheet below turns this into your own before/after inventory.
Framing is illustrative for risk-owner discussion, not a quantified guarantee — your likelihood and impact scales are yours. The assessment worksheet below turns this into your own before/after inventory.
This does not replace your security program. Phishing still lands, endpoints still need defending, application vulnerabilities are still yours to patch, and an operator who can't read your data can still disrupt service or delete infrastructure — confidentiality is removed from their reach; availability remains an operational concern.
What it does is remove one entire class of paths completely, rather than every class partially: the privileged-read paths that turn intrusions into material breaches. Your PAM still governs who may act, your SIEM still records what happened — and what any of it can read is now bounded by hardware.
What security owners ask
Does this replace our PAM, SIEM or EDR?
No — it composes with them. Those tools govern and observe the use of privilege; operator exclusion bounds what privilege can read. Keep the governance layer; add the structural one underneath it. What changes is that your monitoring stack stops being the last line of defense for confidentiality.
What can a privileged admin still do?
Operate — and disrupt. An admin can still stop, delete or misconfigure infrastructure; availability and integrity of operations remain concerns your existing controls address. What they can no longer do is read workload data or extract keys. The honest framing: confidentiality is removed from their reach, not their job.
What about side channels and TEE vulnerabilities?
They're real, published, and part of any honest evaluation — hardware vendors patch, attestation policies enforce current firmware, and defense-in-depth still applies. The comparison that matters isn't “sealed vs. perfect”; it's “sealed with a researched, patchable attack surface vs. plaintext memory readable by design.” Bring your threat model to the call; we'll go through the CVE history with you.
Does physical access to the server defeat this?
Physical extraction yields encrypted memory and no keys — keys are bound to attestation state and released only to verified runtimes, so a pulled disk or seized machine produces nothing readable without them. Sufficiently resourced physical attacks on hardware are a research field, which is why attestation policy and key custody design matter; we'll cover the specifics against your scenario.
How do we measure the risk reduction?
Two artifacts: the privileged access-path inventory (paths before vs. after, per workload) and coverage metrics — share of crown-jewel data processed encrypted-in-use, workloads under attestation-gated keys. Both slot directly into a risk-register review and give the board a number that moves. The assessment worksheet above is the starting template.
Where do compliance frameworks fit into this?
The same mechanism carries the evidence load: NIS2's access-control and supply-chain measures, DORA's third-party and encryption expectations, Grundschutz at elevated protection need. One enforcement layer, several mappings — see the compliance pages for the framework-by-framework view, and sovereign cloud for the jurisdiction angle of the same architecture.
Operator exclusion is not one product — it is what these four enforce together.
Existing virtual machines run with memory encrypted during execution; the hypervisor sees ciphertext.
Kubernetes workloads isolated at pod level, with the control plane no longer a master key to the data.
Keys held by you, released only to a workload that proves its integrity.
Workload identity and attestation — the mechanism that makes exclusion checkable, not claimed.
Bring your register's oldest “accepted” entry_
Tell us the risk you've been carrying because nothing structural existed — the insider scenario, the provider-access entry, the crown-jewel system that can't move. We'll show you which paths disappear and what the residual line looks like.
