The Safebox is the part that makes the rest safe.

What businesses actually pay for today.

Before Safebox, an organization that wants to deploy AI responsibly ends up paying for trust in pieces. Each piece is its own line item, its own audit, its own renewal cycle, its own team to maintain. The total cost is large and grows linearly with the number of environments, vendors, and jurisdictions the business operates in.

A mid-sized company running AI services for healthcare, finance, or anything regulated typically pays for some combination of:

A regulated mid-market company easily spends $300K to $1.5M per year on this stack, plus internal engineering time that runs 5–15% of total engineering payroll. Bigger companies spend orders of magnitude more. And every one of these certifications expires, has to be renewed, and only attests to a moment in time — what your systems looked like during the audit window, not what they did yesterday or what they're doing right now.

None of this is bad. Auditors do useful work. The problem is the architecture. Trust is being purchased from many vendors, attested by many different parties, in many different formats, with many different scopes, on overlapping schedules. The same engineering team has to satisfy all of them. Most of the cost is reconciliation — making sure the controls that satisfied auditor A also satisfy auditor B, then putting that together into something the board and the regulators can both read.

One environment. Open source. Bring your own auditors.

Safebox replaces this patchwork with a single environment that's the same wherever it runs. Same cryptographic guarantees in your data center, in AWS, in Azure, on-prem, or air-gapped. Same audit trail format. Same governance model. Same code, same hashes, same signatures.

You don't pay an auditor to certify Safebox itself — the design is verifiable from the source. You pay your auditors to verify that your deployment is configured correctly for your requirements. That's a much smaller, much cheaper question.

The other change: your auditors are your auditors. They sign with their own keys, on their own devices. There is no Safebots-controlled audit committee. There is no third party that has to bless your configuration before you can deploy. You bring whoever you trust — your existing SOC 2 firm, your in-house compliance team, your board's audit committee, an outside legal advisor — and they each get a key. M of N of them must agree before anything privileged happens.

Cryptographic attestation, all the way to the user.

This is the part that most people don't realize is possible until they see it work. A Safebox publishes a verifiable claim about what it is and what it just did. The claim is signed with a key whose ancestry traces back to the hardware attestation produced by the underlying Infrastructure. A web browser — without any plugin, any extension, any special setup — can verify that signature chain and confirm:

1. The Safebox is running the code its operators claim it is running.
2. The code hasn't been modified since the last M-of-N-signed update.
3. The specific action being attested actually happened, was approved by the right policy, and was executed by the running code.
4. The attestation was generated by hardware that the user (or their auditor) can independently verify exists in a known cloud or data-center environment.

The verification uses OpenClaim signatures — an open standard for ES256 (P-256 with SHA-256) JSON claims. Browsers have implemented this since 2017. The standard is widely deployed for FIDO2 hardware tokens, signed JWTs, and decentralized identity systems. There is no proprietary cryptography in this path. There is no need to install anything. There is no certificate authority to trust.

What this enables: a customer interacting with a Safebox-hosted application can be shown, in their own browser, a verifiable receipt that proves the AI processed their data inside a specific sealed environment, that the data was never exfiltrated, that the result was produced by a specific approved version of the code, and that the entire interaction is logged in a signed, append-only record. The customer doesn't have to trust the platform operator. They can verify it themselves.

For regulated industries, this changes the compliance conversation. Instead of saying "we promise we follow HIPAA," the platform says "here is the cryptographic record of every action we took with this protected data. Verify it yourself, or hand it to your auditor."

Every state change goes through approval.

Inside a Safebox, code does not have free rein to change state. The architecture has a strict separation between Tools (which run code and observe the world) and Actions (which actually modify it). Tools can propose actions. Actions don't execute themselves. Each action type has a policy. The policy decides whether the action runs automatically, requires a single human approval, requires a quorum of approvals, or is rejected outright.

This is the same governance pattern used by every serious decentralized finance protocol — except instead of protecting cryptocurrency, it's protecting your AI workflows. Any 3 of 5 signers must agree before privileged actions execute. The 5 could be your CTO, your compliance officer, your existing audit firm, a board member, and an outside legal advisor. You choose. The system enforces.

Policies that come pre-defined

Safebox ships with a small library of policy primitives that cover most regulated workflows:

Policies are themselves streams managed by the same governance system. Changing a policy is itself an action that requires the appropriate approval. There is no special back door for changing the rules.

Code that can't reach out and touch the world.

When a tool executes inside Safebox, it runs in a sandboxed JavaScript context with no filesystem access, no network access, and no access to the host's environment variables. The only way for the tool to do anything that touches the outside world is to call methods on the Protocol object, which is the audited interface the platform provides.

Safebox uses three sandbox backends, picked at runtime based on what's available:

Every execution produces an execution hash: a SHA-256 of the tool's source code, its input, its random seed, every RPC call it made into the host, and the final result. This hash is signed and recorded. If anyone disputes what the tool did, the execution can be replayed deterministically against the same hash and verified bit-for-bit.

API keys, OAuth tokens, secrets, and credentials never appear in tool source code. Tool authors write placeholder tokens like {{keychain:openai-key}}, and the platform substitutes the real values inside the sandbox at execution time — from an encrypted keychain that's wrapped with a per-community HKDF-derived key. The substitution happens after the tool's source has been hashed, so the cryptographic record never contains the secrets, but the running code has what it needs.

How Safebox talks to AI — including your local models.

The Protocol object is the auditable interface between sandboxed tools and the outside world. Every external call any tool makes goes through it. The surface is small enough to enumerate:

Local models — connecting to your Safebox Infrastructure

The interesting wiring is between Protocol.LLM and the model runners on your Safebox Infrastructure. The same tool code that talks to Anthropic in development can route to Gemma 4 12B running locally on your infrastructure in production — without code changes. The Protocol layer detects the model name and dispatches to the appropriate adapter.

This matters for two reasons. First, it means tools written against the platform are portable across deployments: same code, different inference backend, same governance and audit trail. Second, it lets organizations adopt local AI gradually — start with hosted models for prototyping, swap in self-hosted models for production, without rewriting the application.

KV cache awareness for prefix-heavy workloads

The Anthropic adapter implements full prompt-caching support — system blocks marked with cache_control are cached on the provider side, and the platform tracks cache_read_input_tokens and cache_creation_input_tokens in usage metrics. When tools route to local llama.cpp runners via the Infrastructure layer, the same prefix gets pinned to a per-conversation cache slot that persists across container restarts.

For agentic workloads — where many requests share a long stable system prompt of tools, persona instructions, and RAG context — this is the difference between a 50ms response and a 5-second response. Safebox makes the cache-friendly path easy to take and impossible to mismeasure.

The detailed story on which inference runtime to use for what — vLLM, llama.cpp, Ollama, SGLang — is on the runners page.

Infrastructure → Safebox → Safebots.

Safebox is one layer of a three-layer architecture. Each layer adds a safety property the next layer builds on. The investor deck describes this as "what blockchain did to banking, applied to AI" — and the three layers map directly onto Bitcoin, Ethereum, and the consumer-app ecosystem that grew on top.

The pattern is the same as it has been in every wave of computing: each layer pushes safety down, so the layer above can be built freely. Bitcoin did the math; Ethereum built the programming model; consumer apps grew on top. Safebox Infrastructure does the hardware attestation; Safebox does the governance and execution; Safebots and the apps that follow grow on top.

Other open-source pieces that fit on this stack

The same architecture supports a growing family of components, each handling a different concern but sharing the same governance and audit primitives:

• Safebots — AI agents that compose tools, chat, and respond inside the Safebox runtime.
• Grokers — open-source code analysis tools that operate on entire repositories deterministically.
• Code — workflow-driven code generation with deterministic streaming.

Each of these is open-source, each operates under the same M-of-N governance, and each can be deployed independently or alongside the others depending on what an organization needs.

What this is worth to a business.

For a CFO or general counsel evaluating this, the relevant comparison is to the cost of the audit treadmill described in section one. Safebox doesn't eliminate compliance work — there are still regulators with checklists, auditors with opinions, and contracts that need signing. What it eliminates is the engineering cost of producing evidence that satisfies those checklists, because the evidence already exists in cryptographically verifiable form.

What changes for the customer

The customer of a Safebox-deployed service gets a verifiable receipt for their interaction with the AI. They don't have to take anyone's word for what was done with their data. They can show the receipt to their own auditor, their own regulator, their own lawyer, and the receipt verifies independently. This is closer to how the financial industry treats trade execution than how the AI industry currently treats inference.

What changes for the regulator

A regulator who asks "show me every AI interaction involving protected information for the period in question" gets a cryptographically signed log, not a Jira export. The log is consistent across vendors, formats, and jurisdictions because Safebox is one standard. There is less to argue about because there is less ambiguity to argue from.

What changes for the investor

An investor looking at AI infrastructure is currently looking at companies that bolt safety onto products that were not designed with it. Safebox is one of a small number of efforts going the other direction — designing safety into the substrate and letting products grow on top. The premise is that the safety substrate is itself a market: as regulators tighten and as customers demand verifiability, the demand for a standard that delivers both compounds.

This is the bet of the investor deck — that the AI industry is now where the financial industry was when Bitcoin published its whitepaper. The infrastructure layer is being rewritten. The companies that build the rewrite will define the standard for what comes after.