Security & Trust
Nimbula is sovereign by architecture and sealed by your key. Not a US company’s "Canada region"; a cloud with no US owner, no US investor, and no US infrastructure in the path, where the data you seal stays ciphertext to us. Even to a subpoena.
In private preview, opening region by region.
1
Your data stays in your jurisdiction, and there is no US door into it.
You select your region. Everything that follows is pinned to it: prompts, files, outputs, metadata, and the compute that runs over them. Nothing crosses that border, and nothing runs on US infrastructure to do it.
This is structural, not a setting. The data plane is isolated by jurisdiction at the architecture level, so one region’s bytes cannot land on another region’s disk; not by configuration, not transiently, not by accident.
// the CLOUD Act, specifically
Nimbula has no US corporate parent, no US investors, and no US infrastructure in its data path. The US CLOUD Act compels US-person providers. With none of those predicates true of us, it has nothing here to reach.
2
Two tiers, and we are precise about which is which.
Most clouds say "encrypted in transit and at rest" and stop there. That model protects the journey and the disk, but the provider still holds the keys and can read your data. We split the problem honestly.
client-side · zero-knowledge
You encrypt on your own machine, with a key we never receive. We store ciphertext. We cannot read it; not for support, not under compulsion, not at all. There is no key on our side to surrender.
search · drafting · inference
Some work has to read your data to do its job. We don’t pretend otherwise. Here your data is readable only inside your region, on non-US infrastructure, and every access is written to a tamper-evident log.
We will not claim zero-knowledge on data we have to read. The vault is sealed; the workspace is sovereign. You choose what goes where, and the line between them is the product, not the fine print.
3
We name our subprocessor. That is a feature, not a footnote.
Vague "audited sovereign partners" language hides the one fact a regulated buyer most needs. We disclose it plainly.
4
Built to support the frameworks your auditors hold you to.
// the honest limit
We can’t make your organization compliant; that is your whole security posture, not one vendor. What we remove is sovereign infrastructure as the gap in it.
5
Authorization and a tamper-evident record, by default.
6
Your data never trains a model, ours or anyone’s.
Prompts, files, outputs, and workspace contents are never used for training, fine-tuning, or model improvement. Customer data and any model pipeline are separated at the architecture level, a hard boundary, not a policy you have to take on trust.
And in the sealed vault there is simply nothing to train on: we hold ciphertext. The strongest privacy guarantee is the one we couldn’t break if we wanted to.
Ask us anything a procurement team asks.
Architecture diagrams, the data-processing agreement, the full subprocessor list, the security questionnaire. We’d rather you audit us than trust us; the design holds up to reading. That is the point of it.
Nimbula is in private preview. This page describes the architecture we are building to and the commitments we hold ourselves to. It is not a claim of completed third-party audits or of capabilities that are not yet live. As each piece ships, we mark it live, and we will tell you plainly what is operational today versus what is on the roadmap. A sovereignty product that overstates itself is not one.