Your data never leaves the box.

In plain terms

Think of a bank vault that runs programs.

You put something valuable inside — your data, your passwords, your AI. The vault runs the work in there and hands you back only the result. Here's the part that's new: even the people who own and operate the vault can't open it and look inside. Not the cloud company. Not us. Nobody.

The rest of this page is the engineering — for people who want to see exactly how the vault is built and check the math. If that's not you, the three cards above are the whole idea: a sealed machine that runs your work, proves what it's running, and only lets results out with your permission.

The literal claim

Privacy as a property, not a posture.

Every cloud-AI vendor takes privacy seriously. Most have SOC 2 audits, NIST controls, lawyers who care. Safebox has those too. The stronger guarantee comes from how the system is built: privacy holds because of the architecture, not because of who's running it.

A Safebox is a sealed compute environment — a virtual machine on AWS Nitro–attested hardware — that runs your AI workloads, holds your credentials, and stores the artifacts your workflows produce. The phrase "your data never leaves the box" is meant the way a physicist means it: anything that comes out of the box was either signed by the keys held inside it, or it was data that wasn't yours to begin with. Nothing else. No backdoor for the operator. No exfiltration path through the cloud provider. No "trust us, we have policies."

The keys that decrypt your credentials are derived from a measurement of the running software, bound to specific hardware. Change the software, the keys change. Move the disk to another machine, the keys change. Try to read the disk from outside the box — the keys aren't there.

This is the only kind of privacy claim that survives the people running the system also being adversaries. At any sufficiently large company — including the cloud provider where the Safebox runs, including the team that built the Safebox itself — there is always somebody with prod access who could, in principle, look. Cryptographic binding closes the "in principle." The keys aren't there to use. For the full accounting of which attack vectors this stops, see how compromise is contained at the substrate.

A second of its kind

Two ways to trust running code.

The short version: blockchain proved you could trust a program without trusting whoever runs it — by making it public and slow. Safebox does the same thing the opposite way — private and fast. It's the second technology ever to pull this off.

Until 2009, the only way to trust software was to trust the company running it. Bitcoin changed that. Anyone could read a smart contract, anyone could verify it ran correctly, no operator could rewrite history. That was the first technology to make trust the code, not the operator a real property of the world. Safebox is the second.

Blockchain solves code-trust through replication. Many nodes run the same code, consensus decides which outputs are real, anyone can recompute and check. The trade-off is built into the design: it's slow (block times, gas), it's public (every byte of state is visible to everyone), and it can't hold private keys or call private APIs without giving them away.

Safebox solves the same problem through hardware attestation. One machine runs the code at native CPU speed; the hardware vouches that the running code matches the published source, and the keys that decrypt anything inside are derived from a measurement of that code. Different code, different keys. Anyone can ask the hardware for an attestation report and check it against the published source. The verifiability is just as crisp; the trade-offs are inverted. Single-machine instead of replicated. Fast instead of slow. Private instead of public.

The two are complementary, not competing. Blockchain holds immutable public records — contracts anyone can audit, transactions anyone can replay, history no one can edit. Safebox holds private compute that's nonetheless verifiable — AI running on data that can't leave its boundary, credentials that even the operator can't read, workflows that prove the inputs and approvals they claimed without exposing them.

What they share is the underlying shift. Until 2009, no software anywhere could be trusted independently of the people running it. Now there are two kinds that can — public state through blockchain, private compute through Safebox. The space of things software can do without forcing trust in the operator just doubled.

How it works

Three pieces of mechanism, fitted together.

Three independent mechanisms compose. Each is well-understood in isolation; the combination produces a guarantee strong enough to put real money behind.

Take any one of these three pieces out, and the guarantee collapses. Without attestation, the operator could swap the software and decrypt your credentials. Without the sandbox, a workflow could simply read the credentials directly. Without the audit, you'd have to trust the operator's word that the workflow ran the way you think it did. Together, they produce a substrate where the question "could anyone read this without your signature?" has a real, mechanical answer.

Two boxes, separated keys

Credentials live in two places at once.

The short version: your passwords are split across two sealed boxes, and neither one can unlock anything alone. Like a missile launch that needs two keys turned at once — except here it's automatic, takes 8 millionths of a second, and no human ever holds both.

A single Safebox doesn't hold the keys to your credentials. Two Safeboxes do — one holding a master secret, one holding wrapped credential blobs. Neither alone can decrypt anything. The cryptography requires both, communicating over an authenticated channel, for any single API key to be usable.

The Requester Safebox holds a 32-byte master secret on disk — the only persistent secret in the entire system. It derives a community-specific wrapping key via HKDF(masterSecret, communityId, "Safebox.RequestOrgKey") on each request and sends it over mTLS-authenticated HTTPS to the Executor. The wrapping key is zeroed from RAM as soon as the executor call returns.

The Executor Safebox holds only wrapped credential blobs in safebox_key_management — AES-GCM ciphertexts that mean nothing without a wrapping key. No master secret. No org key cache. No persistent decryptable state. On each capability call, the executor receives the wrapping key over mTLS, unwraps the org key ephemerally, decrypts the actual API key, uses it, and zeros everything. Steady-state per-call key material is roughly 8 microseconds of crypto — too cheap to be worth caching.

The infrastructure layer wraps this with three independent defenses on every cross-container call. The kernel layer: per-container Unix domain sockets, bind-mounted into exactly one container — container foo's socket doesn't exist in any other container's filesystem namespace. The crypto layer: each container's HMAC key is HKDF-derived from the master with a per-container info string, so the keys are cryptographically independent. The application layer: the System component reconciles the socket-derived identity against the request body; if a request on foo's socket claims to act on container bar, it's rejected with WRONG_SOCKET. A bug in any one defense doesn't reach plaintext credentials; you'd need all three to fail simultaneously.

This pattern matches the deployed Groups app, which uses HKDF-rooted symmetric hierarchies for E2EE messaging across 7M+ users in 100+ countries. Public-key cryptography appears only at trust-boundary crossings — one ECDH per browser-to-Safebox provisioning. Everything downstream is symmetric: HMAC-SHA-256, AES-256-GCM, HKDF. The steady-state key hierarchy is post-quantum by construction; the only quantum-exposed surface is that one initial handshake, which a hybrid KEM upgrade replaces without touching the rest of the architecture.

How you verify the mechanism

The infrastructure is open. The application is closed.

Trust in a sealed system has two pieces. The infrastructure itself — the deterministic build, the attestation chain, the cryptographic proof that the box is running the code it claims. And the application running inside it — the workflows, the policies, the integration logic, the actual program doing the work.

Safebox treats these as two problems with two answers. The Infrastructure repo is public, Apache-2.0 licensed, on GitHub at github.com/Safebots/Infrastructure. Anyone can read it, build it themselves, watch a Safebox attest, and confirm the running box matches the published code. The Safebox plugin stays closed — no NDA program, no privileged researcher access, no source disclosure path. The architecture is the public commitment; the open-source bounty program below is the verification path.

A lock is trustworthy if it still works when the burglar has the blueprints. We publish the blueprints of the infrastructure because the trust argument requires that we do.

Public infrastructure means the trust lives in the engineering rather than in the company. The application is closed for an honest reason: the cost asymmetry between defenders (finite audit hours) and attackers (unbounded time, unbounded compute, modern analysis tools) is brutal once source goes public. Keeping the application closed runs the asymmetry the other way, on top of an architecture that already holds without the application being closed. The verification path is the bounty program below — open to anyone, paid out automatically, refereed by code that is itself open source.

The shorthand: the infrastructure is open and verified by the public; the referee is open and runs the verification; the application is closed and bet against by a bounty pool the architecture itself funds. When a researcher wins, the bounty pays — and the exfiltrated material stays inside the outer Safebox. The architecture compensates discovery without releasing what was discovered.

Why forks can't fake it

The ecosystem enforces itself.

The short version: because the code is open, anyone can copy it — but a copy can't prove it's genuine, and the useful parts only unlock for boxes that can prove it. A knock-off runs, but it can't join the network or get the real capabilities. You can copy the lock; you can't copy the fact that nobody trusts your key.

The infrastructure is open — so what stops someone rebuilding it, stripping out the guarantees, and calling the result a Safebox? Nothing stops the rebuild. Everything stops the claim. A box that can't prove it's genuine can't obtain what makes it genuine.

The answer isn't a license clause buried in open code — anyone can fork that away. It's structural, and it runs on the same attestation the rest of this page describes. Trust in a Safebox is decided in two tiers, and only one of them is yours to change.

Immutable system prompt, open user prompt. The vendor guarantees the frame; you have total freedom inside it. A Safebox applies that shape to a whole compute environment.

This is why forcing ourselves into the base doesn't contradict user-chosen trust — it composes with it. The end user gets a guarantee about the frame ("these invariants hold, whatever else the operator does") while the operator keeps freedom within it. The two tiers don't compete; they stack.

The gate: a genuine box can prove itself. A fork can't.

Here is where the enforcement actually lives — not in code the operator holds, but in what we release, and only to a box that can prove it's real. Safebox injects proprietary plugins into the Qbix substrate: the Safebux economic layer, the governance machinery, the Grokers knowledge graph. A genuine Safebox attests itself to us — presents a measurement our M-of-N blessed — and only then do those plugins release to it. A fork runs the same open base, rebuilds perfectly, and still gets nothing: it cannot produce an attestation that chains to trusted auditors, so the plugins are withheld, so it cannot run the proprietary capabilities or join the economy at all.

Notice what this is not: it is not a license lock on open source (that forks away), and it is not us signing every one of your updates (that would negate the auditors you choose). It's a release gate on closed value, keyed to a proof only a genuine box can generate. We don't prevent the fork. We withhold the proprietary layer from anything that can't prove it's a real Safebox — and the lock is on our server, not in their code.

You can fork the lock. You can't fork the fact that no one trusts your key.

The economy is the plugin — and it compounds.

The proprietary layer isn't incidental DRM; it is the Safebux economic substrate. Every external fetch is cached, attributed, and priced at the Streams.fetch / Action.propose boundary. Costs fall as usage grows: cache hits cost less, early materializers earn commissions, the economics reward contributing to the commons. A fork that rips out Safebux isn't removing a license check — it's removing the priced, attributed, commissioned network itself, forking off at the exact moment being on the network is most valuable.

So the free-rider question answers itself along the seam that matters. An operator running boxes privately, for itself, needing none of the commons — forks freely, owes nothing, and was never the customer. An operator who wants to sell trusted, fully-capable compute to clients needs the plugins, which needs a genuine attesting box, which means Safebux flows. The enforcement is mechanical, not merely brand: to make money on the real product, you have to be real.

And the release channel is itself the proof of the whole thesis. Our own proprietary plugins are confidential; we hand them only to boxes that prove they're sealed; even the box's operator can't read them back out. That is the same guarantee we sell tenants — you trust the operator with uptime and resources, and nothing else — applied to our own crown-jewel code. If a Safebox couldn't protect our plugins from its operator, it couldn't protect your data either. We are our own first adversary, and we bet our IP on the same seal.

Verify even the closed parts

Ask a sealed box anything. It can only answer.

There's one honest gap in everything above: a few parts of the system are closed-source, checked by bounties instead of published code. So how do you verify something you're not allowed to read? You put an investigator inside a sealed box — one that can look at anything internally, but can only pass a short answer back out.

Concretely: an AI model sealed inside a Safebox can be asked any question and can deploy any auditing tools it needs internally — but an outer Safebox wraps its network interface and filters the output down to bounded-size answers and bounded-size code, at a controlled rate. Unlimited investigation inside; a deliberately narrow pipe out. The narrow pipe is the security boundary: the investigator can look at everything, but can't leak more than a verdict.

The output channel is the boundary. Inside, the auditor can inspect anything. Outside, only a bounded, signed verdict crosses — so "can investigate everything" never becomes "can exfiltrate everything."

One inspection, verified by many.

The narrow slot would be a bottleneck if every organization had to line up and ask the same questions. So they don't. An auditor asks once, and publishes the signed verdict for everyone. The expensive, carefully-metered interrogation happens a single time, by one accountable party; everyone else reads a signed result that costs the channel nothing to redistribute. It's how the world already works — you don't personally audit a company's books, you rely on the auditor who did — except here the audit itself is cryptographically proven, not taken on reputation.

And the "auditor" needn't be a person or a firm. It can be a market: organizations submit the questions they most want answered and bid — in Safebux — for the scarce slot. Price discovery decides which questions win the bottleneck; the winning question's verdict is published for all; the fees flow to the network. The scarcity you had to impose for safety becomes the mechanism that funds the whole thing.

Who audits the auditor? The path is public by construction.

There's a classic trap here, first named by Ken Thompson: what if the thing doing the checking is itself compromised, and quietly blesses its own poisoner? A checker that can't be trusted makes every verdict worthless. Safebox closes this by stamping every query with an attested record of the exact path it travelled.

An audit query is provably routed through only the open, published base machinery and publicly-available components pinned by hash — the proprietary parts are demonstrably not on the path, and the stamp proves it, per query. Because every ingredient on that path is public and hash-pinned, and the AI is near-deterministic, anyone can reassemble the identical investigator from public parts and replay the exact signed result. The closed parts of the system can't taint an audit they never touched — and the attestation shows, query by query, that they didn't.

You don't have to trust that the auditor is honest. You can read the auditor's exact recipe — every part of it public and pinned — rebuild it yourself, and get the same signed answer.

The honest floor, stated plainly: this shrinks what you must trust down to the open base and the hardware seal itself — the smallest possible kernel — rather than eliminating trust entirely. No system reaches zero. The point is to make the thing you must trust small enough for anyone to inspect, and everything above it checkable against that.

What it lets you do

Four things become available inside the box.

Security primitives are valued for what they unlock. Once data is bound to a box that nobody else can read into, four things become available that weren't before.

Red-team & bounties

A Safebox inside a Safebox — on purpose.

Anyone can claim their substrate is unexploitable. Safebox is structured so independent researchers can actually try — with cash on the line, against the real plugin code, on an environment we deliberately built to host an adversary. The setup is the title literally: two Safeboxes, one nested inside the other.

The outer Safebox is the referee, and is itself a Safebox — sealed by the same mechanisms this page describes, with the additional property that it doesn't even run the application being tested. It runs only the instrumentation: network-namespace observation, audit-log replication, capability-invocation logging, stream-write monitoring. It contains only the Infrastructure layer and attestation logic — no Safebox plugin, no Safebots application code, nothing proprietary — so it can be (and is) fully open-sourced. Compromising the outer is in scope (top-tier bounty), but the ceiling is what a researcher can extract through any single attack: not the source, not the data, only the bounty determination and the audit trail of what was attempted.

The inner Safebox is the jail. Same kernel, same hardened Docker, same plugin code as production, but with three changes: its egress allowlist is empty (no real network — the outer box mocks the internet), its Streams.fetch view is frozen against a snapshot rather than the live web, and its credential store is bait — wrapped under a bait master secret on a bait requester. The inner box is also attested as a simulator profile — a declared distinct attestation type. The Nitro signature includes the claim "this is a research simulator, the outer box is mocking the internet, the data inside is bait." A simulator box can't be confused with a production box because the attestation distinguishes them at the cryptographic level.

The win condition is simple: anything from inside the inner box that crosses the outer Safebox's boundary unsigned-by-the-referee triggers the bounty. What's subtle is that "crossing the outer boundary" doesn't mean reaching the researcher. When the inner attempts to exfiltrate — source code, bait credentials, snapshotted streams — the bytes leave the inner box and enter the outer box. They don't leave the outer box. The outer is sealed too. The researcher receives a signed finding attesting to what was attempted, the bounty payout, and a published advisory once the patch ships. The exfiltrated bytes themselves stay bottled inside the outer Safebox.

The outer's postmortem comes from four channels the architecture already produces. Network namespace: the outer owns the namespace the inner runs in; every outbound packet attempt is logged. Audit-log replication: the inner's tamper-evident audit log streams continuously out; the inner can't unsign or backdate entries the outer already received. Capability invocations: every external call from the inner goes through the outer (which acts as executor for the inner's wrapped credentials), so the outer logs every credential use, every model call, every external HTTP attempt. Stream writes: in the Safebox model every meaningful state change is a stream write, visible at the system-component boundary.

The M-of-N package compromise scenario — the worst case a security-minded reader rightly worries about — is exactly what the inner box hosts. A simulated compromised maintainer pushes a malicious npm or composer package. The inner box's M-of-N install gate (running with research-mode keys) admits it. The package executes as the app user, reads the source on disk, harvests the bait credentials, attempts to dial out. The dial-out hits the outer Safebox's egress boundary, where it's logged and stopped. Source remains inside an attested Safebox; only the bounty payout, the signed finding, and (after fix and coordinated-disclosure window) the published advisory leave. The researcher learns that the inner was compromised, what method worked, that the bait was extracted into the outer — and earns the payout. They don't get the source.

The reason this architecture is honest is that nothing in it is custom. The outer/inner nesting matches the shape the credential infrastructure already wants — the executor that holds wrapped credentials naturally sits outside the requester+app that holds the master secret, because the executor is also the natural egress point. ZFS clones make per-run resets cheap. Capability-scoped egress is what every Safebox tenant already uses; "empty allowlist" is just the tightest configuration of a knob that's there. Hosting an adversary inside the same architecture that hosts production isn't a separate stack; it's a configuration of the stack that's already there.

The same architecture has a production use beyond research. Before promoting a new build, a new npm or composer package, or a new dnf-installed dependency, the outer Safebox runs the candidate as its inner — proxying live traffic in trust-or-simulate mode. Trusted inner: the outer passes traffic through. Untrusted inner: the outer simulates the internet for it and watches whether the new code does anything anomalous against the four-channel postmortem above. The pattern catches supply-chain attacks of nearly every kind. The one honest exception is sleeper programs: code that behaves correctly until a specific date or input triggers the malicious branch. Catching sleepers requires running the inner across many conditions, which the architecture supports but doesn't solve by construction. Every other class of compromise — the ones that account for nearly all real supply-chain incidents — surfaces at the outer boundary the first time the inner runs.

Run a probe. Earn the bounty.

Open program. No NDA, no privileged-researcher tier, no application form. Spin up a simulator-attested Safebox preloaded with bait, write workflows that try to escalate privilege or exfiltrate data, watch what happens. The outer Safebox is the referee; if anything crosses its boundary, the bounty fires.

The bounty pool is funded structurally. A small percentage of every Safebux transaction — the gas of the broader Safebots economy — flows automatically into the pool. The pool grows with usage. Researchers don't need a corporate sponsor; the architecture funds its own adversaries, in perpetuity, denominated in the same token that pays for production compute.

Payouts execute on-chain. When the outer Safebox detects exfiltration, it signs a finding claim and submits it to the OpenClaim smart contract. The contract verifies the outer box's attestation, checks the claim against the simulator's declared bait, and releases the bounty automatically. No human at Safebots authorizes payment. The architecture is the payer.

Bounty scales by what was found. Privilege escalation inside the inner box (lowest tier). Bait data crossing into the outer Safebox (middle tier). Compromise of the outer Safebox itself, the referee (top tier). Findings are coordinated-window disclosed: reported, fixed, then publicly published with the researcher named. A public leaderboard tracks cumulative findings by researcher across all tiers. The referee is open source — anyone reads how it judges, runs the same instrumentation, and verifies the determination is reproducible from the audit log. There is no human in the loop on the decision; either the byte crossed or it didn't.

github.com/Safebots/redteam · the attacks we expect to stop