Vendor Sandboxes | Elacity Labs
Every OS since Multics has organised security around one axis: the user. The agent era needs a second axis: the vendor. When a proprietary model runs on your laptop, two parties need protection — from each other. The dual-axis sandbox is the missing primitive, and it is what unlocks the agent economy.
Vendor Sandboxes: The Missing Address Space Between User and Cloud
Every operating system since Multics has answered one question about every running process: who owns it? The answer has always been the same. The user. Everything from Linux UIDs to Apple sandbox identifiers to container namespaces is organised around a single axis — the human who launched the process.
The agent era needs a second axis: the vendor.
When a proprietary model runs on your laptop. When a streaming service plays a film through your CPU. When an agent uses an engine you do not own. There are now two parties whose interests have to be enforced — and only one of them is you.
The Two Asymmetries
The vendor needs protection from you. They have invested billions training a model, encoding a film, encrypting a dataset. If their bits land in raw form on your machine, they are gone. Any DRM scheme they ship is one motivated reverse-engineer away from being broken.
You need protection from the vendor. Their engine is running on your hardware, with access to your camera, your microphone, your files, your network. If it phones home with anything you did not authorise, you are exposed.
Both protections must hold at once. This is the dual-axis problem, and it is genuinely hard. Solve it, and the agent economy unlocks. Skip it, and you get the surveillance internet we already have — with extra steps.
How Half of It Got Solved
Apple's Private Cloud Compute solved one half. PCC nodes are stateless, attested cloud machines whose memory is wiped after every request. Even Apple cannot read what passes through them. It is the cleanest example yet of a vendor protecting the user inside the vendor's own infrastructure.
AMD SEV-SNP and Intel TDX push the same idea down to silicon. They let a workload run inside a cryptographically isolated VM that the host OS, the hypervisor, and the cloud operator cannot inspect. The Confidential Computing Consortium has been advancing this work for years.
Academic projects like Tyche, built at EPFL and Cornell, generalise the same pattern as a formally verified software monitor on commodity hardware. The technology is mature. What is missing is the OS-level abstraction that knits all of it into a single user-facing primitive.
The Missing Half
None of these technologies alone solves the other axis — the vendor's interest. Apple PCC protects you from Apple, but it does not let a third-party vendor ship their proprietary engine into your enclave with the same guarantees. SEV-SNP and TDX protect a workload, but they do not bind it to a specific licence, a specific user, or a specific runtime.
The Vendor Sandbox is the missing primitive. It is a hardware-attested address space on the user's hardware that runs the vendor's code, holds the vendor's licence, settles the vendor's payment, and never exposes the vendor's weights to the user — while simultaneously refusing to leak the user's data back to the vendor.
That is the architecture every viable agent economy needs. It does not exist yet at consumer scale. It is what we have been building.
How Elacity Closes the Loop
1. Run the Engine Sealed
The Elacity Capsule wraps an engine — a model, a film, a dataset — in encrypted form. On the user's Personal Cloud Compute node, the Capsule unwraps inside an attested runtime. The vendor's bits never sit in cleartext on disk.
2. Enforce the Licence In-Chain
Every Capsule binds an Elacity dDRM smart contract that codifies the terms. The runtime checks the contract before unsealing. Payment, expiry, scope of use — all enforced in the same address space that holds the engine.
3. Settle Without Trusting Either Side
When the Capsule is used, settlement happens atomically on-chain. The vendor cannot deny use. The user cannot deny payment. Neither has to trust the other. The protocol stands in for the courtroom.
Why This Kills Two Problems at Once
Pirate the model and you cannot run it — the runtime will not unseal without a valid licence. Leak the user's data and you violate an attested seal — provable, slashable, on-chain.
The whole reason DRM has been a running joke for thirty years is that it was enforced by the platform, not the protocol. The platform is the part the user can attack. The protocol, when it is sealed inside an attested runtime, is the part neither side can attack.
Two Address Spaces, One Internet
The internet has always assumed there was only one party that mattered on a user's machine. The vendor side was abstracted into a server somewhere else. That fiction held while bandwidth was cheap and compute was centralised.
It does not hold in the agent era. The vendor's engine has to run where the data is — on the user's hardware, in the user's home, on the user's NPU. Two parties, one device, one address space. That is the future, and it needs the second axis. The Sovereign OS is the place it gets built.
Capsule your engine on Elacity.