Safebox only loads code you can trust. The code operates on your data inside the box. The only way data leaves the box is if your policies allow it — which usually means multiple people from your community signed off. The cryptography ties the keys to those signatures.
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.
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.
Three independent mechanisms compose. Each is well-understood in isolation; the combination produces a guarantee strong enough to put real money behind.
On boot, AWS Nitro measures every layer — firmware, kernel, AMI image, application — into tamper-evident PCRs and signs a statement: "this exact code is running, on this exact machine." The signature is verifiable by anyone who knows the expected measurement.
From that signature, a 32-byte master HMAC key is derived via HKDF and bound to the PCR set. Same code, same hardware, same key. Different code or different hardware, different key. Per-container keys are HKDF-derived from the master with a per-container info string — cryptographically independent.
Inside the box, AI workflows run as small isolated tools — each one in a JavaScript sandbox with an enumerated API. The tool can read the streams it's been granted, propose actions, and call the model. It cannot reach the filesystem, the network outside its allowlist, or the credentials of any other tool.
Irreversible actions — sending an email, charging a card, modifying a shared document — go through a proposal step. The community decides whether to sign. M-of-N governance is enforced at the substrate, with each signer's public key tied to a session and a registered role.
Every request, every model call, every approval, every artifact has an entry in a tamper-evident log. Each entry references the cryptographic identity of the workflow that produced it and the signatures of the humans who approved it. The log is for you, not for the operator.
If something goes wrong, you can replay exactly what happened. If you ever need to prove what didn't happen — for an auditor, a regulator, a court — the log is the answer.
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.
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.
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 four 1.0 components — base (OS hardening, ZFS, hardened Docker, SSH-removal), system (the privileged-host HTTP API, ~4,200 lines of Node), dnsclient (attestation-signed IP announcement), autovhost (on-demand nginx + ACME). All on GitHub under Apache-2.0.
Anyone can rebuild from source and verify a running box against the published PCR measurements.
The Safebox plugin — workflow runtime, policy enforcement, governance logic, integration code, the two-box credential infrastructure — stays closed. No NDA program, no privileged researcher access, no source disclosure path.
Verification doesn't run through reading source. It runs through the open bounty program: anyone deploys a simulator instance, attacks it from the inside, and earns payment on demonstrated compromise.
The outer Safebox that judges red-team findings contains only infrastructure and attestation logic — no Safebox plugin inside, no Safebots application code. So it can be (and is) fully open-sourced on GitHub. Its judgment is reproducible from its audit log.
The bounty pool is funded structurally — a small percentage of every Safebux transaction flows in automatically. Payouts execute on-chain via OpenClaim. No human at Safebots authorizes payment; the architecture is the payer.
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.
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.
Patient records, legal discovery, financial transactions, source code under NDA, conversations that mention compensation. The data stays in the box; the model runs against it; the answers come out signed.
A workflow is a recipe — the steps, the prompts, the tools, the policies. The recipe travels. The data the recipe operates on stays in your kitchen. A community of doctors can share a "summarize this consultation" workflow with the clinic next door; both clinics use it on their own patients.
API keys, payment processors, third-party integrations — every credential is encrypted at rest with a key the box derives from its own measurements. Even with full disk access on either box, a third party can't decrypt them. They exist in usable form only when both Safeboxes participate, for the ~8 microseconds of one call.
The audit trail is cryptographic. You can show an auditor not just a log entry but a signed statement that this code ran, with this input, producing this output, approved by these people. The proof rests on the math, not on your records.
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 inside, no Safebots application code, nothing proprietary — so it can be (and is) fully open-sourced. Compromising the outer is in scope for the program (top-tier bounty), but the architecture's natural 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. No researcher accidentally points a probe at production; no production tenant accidentally receives simulator data.
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 architecture compensates the discovery, but doesn't release the discovery's contents.
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 has already received. Capability invocations: every external call from the inner goes through the outer (which acts as the 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. Reconstructing what the inner attempted is reading four logs the architecture produces anyway.
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. The exfiltration attempt — including any source bytes the package tried to ship — gets recorded inside the outer Safebox. The bytes never reach the researcher. 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. Streams.fetch materialization caches mean snapshotted data is indistinguishable from a live fetch — until you try to push the result out, at which point you discover the executor socket leads nowhere. 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. ZFS snapshots make per-experiment rollback effectively free. The pattern catches supply-chain attacks of nearly every kind — package binary substitution, malicious post-install scripts, opportunistic credential harvesting, transitive-dependency poisoning. 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.
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 themselves, and verifies that the bounty 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.
Don't take our word for it. Verify the math.