Every vendor tells you they take security seriously. It is the least falsifiable sentence in the industry, and it says nothing about what happens when the sentence turns out to be untrue.
So here is a more useful exercise, run on ourselves and published rather than kept in a slide: assume we are fully breached. Someone has our database, our object storage, and our credentials. What did they just get?
Where the line is
Encryption happens on the machine that produced the data, before anything crosses the network. Not on arrival, not at rest on our side. That single placement is what makes the rest of this post short.
We hold the public half of your key and its fingerprint. That is enough to encrypt something to you. It is not enough to read anything back, and there is no second copy of the private half anywhere in our system, because we never received one.
The cost of that, stated plainly
No escrow means no recovery. If you lose your private key, the artifacts encrypted to it are gone, for you and for us, permanently. There is no support ticket that fixes it and no internal tool we are declining to use.
What about credentials?
The other thing worth stealing is the credential to your database. On two of the three paths we never have one.
If you push from your own automation, you connect to your own source and we receive a file. If you run a worker, the source payload lives in that worker's config, and our API rejects it if you try to send it to us. Only on the fully managed path do we hold anything, and there it sits in a secrets manager and is released to a single run.
What we cannot do, including on purpose
0artifacts
we can read the contents of
0keys
we could decrypt with if compelled
0ways
to shorten a hold once it is set, for you or for us
That last one deserves its own note, and it needs a limit stated with it. A hold is stamped onto an artifact when it is written, and it can be lengthened but never shortened or removed, through any API, by you or by us. So the attack it exists for, loosen the policy and then delete, does not work.
What it does not do is stop someone holding our storage credentials. The hold is enforced in our code, not at the storage layer, so a full compromise of us is still a path to deletion. That is a real gap, it is deliberate rather than forgotten, and closing it means a storage-layer lock we have not turned on yet.
What we are not claiming
We have no SOC 2 report and no compliance audit of any kind, and none is in progress. If your procurement process requires one, we are not yet a vendor you can approve, and you should find that out here rather than three calls in.
We also publish no uptime SLA. What we will commit to is narrower and more useful: getting your data out is designed to work in every account state, including one that has run out of credit.
We would rather be the vendor whose security page is short and true.