---
title: "What an attacker gets if they breach us"
description: "We run the exercise on ourselves and publish the answer. Ciphertext, file sizes and timestamps, and no path to the plaintext that does not run through your own machine."
url: "https://saved.sh/blog/what-we-would-lose-if-we-were-breached"
date: "2026-08-04"
author: "saved.sh"
tag: "Security"
---

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?

<Aside title="The short answer">
  Ciphertext, file sizes, checksums and timestamps. No plaintext, no keys, and no
  route to either that does not go through a machine we have never touched.
</Aside>

## Where the line is [#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.

<Figure caption="Everything to the right of the dashed line is what a breach of us yields.">
  <EncryptionBoundary />
</Figure>

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.

<Figure caption="No escrow. It has a cost, and the cost is on us to say out loud.">
  <KeyCustody />
</Figure>

## The cost of that, stated plainly [#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.

<Aside title="This is a real trade, not a feature" tone="accent">
  We could hold a copy of your key and offer recovery. It would be a better
  support experience and a worse product, because the thing that makes a breach of
  us uninteresting is precisely that there is nothing here worth stealing.
</Aside>

## What about credentials? [#what-about-credentials]

The other thing worth stealing is the credential to your database. On two of the
three paths we never have one.

<Figure caption="The only path where we hold a credential is the one where you explicitly ask us to connect.">
  <CredentialCustody />
</Figure>

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 [#what-we-cannot-do-including-on-purpose]

<Stats>
  <Stat value="0" unit="artifacts" label="we can read the contents of" />

  <Stat value="0" unit="keys" label="we could decrypt with if compelled" />

  <Stat value="0" unit="ways" label="to shorten a hold once it is set, for you or for us" />
</Stats>

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.

<Figure caption="The hold can be extended, never shortened. It stops the account holder and our own sweep, and not someone holding our storage credentials.">
  <RetentionLock />
</Figure>

## What we are not claiming [#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.