Your AI, your data, your documents, your meetings, your code, your customers — all in one governed system. Not stitched together from seven services. One platform where everything can see everything else, controlled by who's allowed to see what.
Here's what that makes possible.
The capability that Safebox gives you is narrow and worth naming precisely: a party can prove a property of data or computation to someone who is not allowed to see it. Everything below is a case where that was previously impossible.
Regulators, insurers, enterprise buyers, and acquirers need answers about code they'll never receive. "Does your system store credit card numbers in plaintext?" "Does your algorithm discriminate by zip code?" "Is your training data properly licensed?"
Today the answer is "trust us" or "here's a report from our auditor who we hired." With Safebox, the computation runs inside the attested box, produces a verifiable result, and the auditor checks the attestation chain from a browser. The code stays closed. The proof is open.
Every closed vendor eventually meets a buyer who demands source they can't have. This is that meeting's answer.
→ Sell assurance without surrendering IP.
Several data owners load their datasets into one box, get joint analysis out, and none of them — nor the box operator — sees another's data.
Hospitals pooling patient outcomes to find patterns no single hospital's data would reveal. Banks pooling fraud signals without exposing customer accounts. Competitors benchmarking against each other without disclosing revenue numbers. Law firms running conflict checks across client lists neither side can share.
This previously required a trusted intermediary — which is why it mostly didn't happen. The intermediary is expensive, slow, and the weakest link. Safebox replaces the intermediary with a box that provably can't see what it's processing.
→ Joint intelligence from private data, without a trusted middleman.
HIPAA imaging. FERPA student records. Attorney-client privileged materials. ITAR-controlled specifications. Data that cannot leave its environment, by law.
The data stays in the box. Reports come out, with attestation proving they came from the real data rather than being fabricated. A radiologist gets AI-assisted reads without the images leaving the hospital's infrastructure. A school district gets student performance analysis without student records touching a cloud API.
→ AI for data that was previously too sensitive for AI.
After METR's evaluations, anyone running autonomous agents needs isolation that survives shared-resource coordination. One door in, immutable base image, instant rollback, declared capabilities that are compiled into the binary — not checked at runtime.
This market segment didn't exist six months ago. Now every enterprise deploying agents needs containment they can prove to their board, their insurer, and their regulator. Safebox is that containment.
→ Deploy agents that your insurer will actually underwrite.
A platform proves its recommender doesn't amplify a category — without disclosing the recommendation algorithm. A lender proves no disparate impact — without revealing its credit model. A hiring platform proves no demographic bias — without exposing its ranking formula.
Contested decisions get replayed rather than argued. The computation is re-run inside the attested box, the result is verified, and the model stays private. No more "we investigated ourselves and found no wrongdoing."
→ Prove fairness without disclosing the algorithm.
The analysis pipeline is committed to the box before data access. The researcher writes the query, it's sealed, then the data is loaded. P-hacking is structurally impossible rather than policed by peer review after the fact.
Same mechanism for adaptive clinical trials: the decision rules are committed before each interim analysis. The box proves the rules weren't changed after seeing the data.
→ Research integrity enforced by architecture, not honor systems.
The original stays sealed in the box. Tiered derivatives go out — watermarked per recipient, resolution-limited per license tier, provenance-stamped per distribution. A photographer's full-resolution master never leaves the box. Clients get the resolution they paid for, watermarked with their license ID.
If a watermarked copy leaks, the watermark traces it to the recipient. The master is untouched.
→ Distribute creative work without losing control of the original.
Someone says it on the call. The bot is listening.
The meeting recording is a stream. The transcript is a stream. The codebase is a stream. The symbol graph (every function, every caller, every contract) is already computed.
The bot detects the decision. Looks up every file that references /users. Generates the rename across 47 files. Verifies the contracts still hold. Submits the change for team approval.
No Jira ticket. No "can someone pick this up." No forgetting about it.
→ The meeting produced a governed code change, not just meeting notes.
This is only possible because the meeting, the transcript, the code, and the approval system are all in the same substrate. In a normal setup, the meeting is in Zoom, the transcript is in Otter, the code is in GitHub, the approval is in Slack. Four services, zero connection between them.
A customer on your free plan asks your support bot: "How much is the enterprise plan?"
The bot can see the public pricing page (public stream). It can see the customer's account tier (their profile stream). It cannot see the internal pricing strategy doc (internal-only stream) or the discount matrix (sales-only stream).
It answers from what it can see: the published pricing, the customer's current plan, the upgrade path. Nothing more.
A sales rep asks the same bot the same question. The bot now sees the discount matrix, the customer's usage patterns, and the internal pricing strategy. Same bot. Same model. Different answer — because different person, different access rows.
→ No separate permission layer to build. The data's access control IS the bot's access control.
Every piece of data in the system has access rows: who can read it, who can write it, who can administer it. When the AI queries the graph, it sees exactly what the person it's helping is allowed to see. You don't build a RAG pipeline with a permission filter on top. The permission IS the retrieval.
An employee is on the phone with a customer. The audio stream is being transcribed in real time.
The bot hears "the issue from last week." It matches the customer's name against the customer stream. Finds the open ticket from last week. Pulls the knowledge base article about that error. Surfaces it on the employee's screen — before the employee has to look anything up.
The bot can read the customer's history and the knowledge base. It cannot write to the customer's record during the call. After the call, the bot proposes a ticket update — reviewed by the employee before it saves.
→ Real-time AI assistance that can read but can't act without approval.
The reason this works without a separate integration: the audio, the customer data, the knowledge base, and the ticket system are all streams in the same graph. The bot doesn't need an API connection to your CRM, another to your knowledge base, another to your ticketing system. It's all one system.
A manager records a 12-minute training video showing the setup process. Uploads it.
The bot processes the video: extracts the transcript, identifies the procedures shown (links them to existing procedure streams), generates a step-by-step guide with timestamps, and shares it with the warehouse team (access rows from the team stream).
Six months later, the scanner software updates. The code change is detected by Grokers. The bot flags the training video as potentially outdated and drafts an updated guide — proposed for the manager's review.
→ Documentation that stays in sync with reality.
The video, the transcript, the procedure docs, and the code are all streams that reference each other. When one changes, the connections mean the others can be checked and updated. No one has to remember "oh, we should probably update that training video."
The engineer gets: "The auth migration is 80% done. The remaining work is the session token rotation in auth/rotate.php. Here's the function signature and the two failing tests."
The sales rep gets: "Project Atlas is on track for the October launch. The security upgrade is nearly complete, which means we can start the SOC 2 conversation with enterprise prospects."
The CEO gets: "Atlas is green. Engineering is finishing the security work this sprint. Sales can start positioning the compliance story for Q4 pipeline."
Same question. Same project stream. Same model. Different answers — because each person's role stream determines how much technical detail to surface, which related streams are relevant, and what tone to use.
→ One AI that speaks engineer to engineers, business to business, executive to executives.
Each role has a tiny "soft prompt" (~1KB) stored in the role's stream. The engineer's soft prompt tells the model to be technical. The sales rep's tells it to emphasize customer impact. The CEO's tells it to be brief and strategic. The base model is the same. The adaption is instant and costs nothing.
A prospective customer arrives at your site. They see product features, pricing, testimonials, and a "Start free trial" button.
An existing customer logs in. The same URL shows their dashboard, their usage stats, their open tickets, and "Talk to your account manager."
A partner developer logs in. They see the API reference, their integration status, webhook logs, and "Submit a marketplace listing."
The page isn't three different pages. It's one view of the stream graph, filtered by who's looking. The AI can personalize the copy, the onboarding flow, the examples — all from the same data that powers the bots and the internal tools.
→ Your website isn't a separate thing from your product. It's a view of the same graph.
In a normal setup, you call a meeting, gather logs from six services, and hope nothing fell through the cracks.
With Safebox, the auditor opens a browser. They verify:
The model binary has a .u.meta section proving it has no network access — it structurally cannot send data anywhere.
The model weights have M-of-N auditor signatures proving which model was used and who approved it.
Every AI action is a stream with a timestamp, the input, the output, who approved it, and the governance decision.
The ZFS pool is encrypted with a key sealed to the hardware's TPM — the data physically cannot be read on different hardware.
→ The compliance proof isn't a report someone wrote. It's the system itself, verifiable from a browser.
Hospital A has trained a LoRA adapter on its patient records — the model is better at reading radiology reports. Hospital B wants that expertise but can't receive Hospital A's patient data. HIPAA, ethics, common sense.
The solution: Hospital A shares the LoRA adapter (10MB, no patient data in it — just learned patterns). Hospital B loads it into its own Safebox, on its own hardware, applied to its own model, running on its own patients' data.
Hospital A's patient data never left Hospital A's box. Hospital B's patients benefit from Hospital A's expertise. The adapter is signed by the supply chain — both hospitals can verify who trained it and what approved it.
→ Federated learning without the federation protocol. Just a signed 10MB file.
This works for any domain where expertise is valuable but data is sensitive: law firms sharing contract analysis patterns, banks sharing fraud detection adapters, manufacturers sharing quality control models. The intelligence travels. The data stays home.
None of the scenarios above are technically impossible with separate services. You could connect Zoom to Otter to GitHub to Slack to Jira to Salesforce to your CRM to your website CMS to your compliance tool and wire AI into all of them.
People try. It takes months. Every integration is a potential failure point, a security boundary to manage, a permission model to map, an API that could change, a credential that could leak. The more connections you add, the more fragile the system gets.
Safebox eliminates the connections by eliminating the separation. Everything is a stream. Every stream has access control. Every action goes through governance. Every tool declares its capabilities. The AI sees the graph — filtered by who's asking — and acts within its declared boundaries.
o { Streams.read("meetings/*"), Code.modify, Action.propose }, that's simultaneously the permission system, the audit scope, the attack surface, and the capability proof. There's nothing else to configure. No gap between what the bot says it can do and what it actually can do.The comparison isn't Safebox versus any one tool. It's Safebox versus the assumption that AI has to work the way it works today — trusting someone else with your data, paying for untold teraflops of compute, and hoping models don't suggest bad things to your agents. Instead we can have the model come to the data, generate programs that run locally and be up to 20x cheaper, while making sure bad side effects are caught before they happen, not afterwards.— Gregory Magarshak