---
title: "Security design"
description: "Why the backup survives the incident that takes production down."
url: "https://saved.sh/docs/security"
---

A copy is only external if it is under **different keys**, in **different storage**, on a
**different trust boundary**, and the compromised system has no route to it and no
permission to delete it. Every design decision in this section is that sentence applied
somewhere.

## The three claims, and where each is proven [#the-three-claims-and-where-each-is-proven]

| Claim                                                 | Proven by                                                                                                      |
| ----------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- |
| We cannot read your local backups                     | [Encryption](/docs/security/encryption): the key is applied on your machine and we never hold the private half |
| A stolen credential of yours cannot reach the archive | [Permissions](/docs/security/permissions): the enforcement atom is the permission, and worker keys carry two   |
| You can tell what happened                            | [Audit log](/docs/security/audit-log): append-only, with the actor on every row                                |

## The parts [#the-parts]

<Cards>
  <Card href="/docs/security/threat-model" title="Threat model" description="The attacker this design assumes: whoever holds your production access." />

  <Card href="/docs/security/encryption" title="Encryption" description="Client-side on the local path, with a key we never hold." />

  <Card href="/docs/security/key-management" title="Key management" description="You keep the private half. Loss is unrecoverable, deliberately." />

  <Card href="/docs/security/data-flow" title="Data flow" description="Bulk data moves directly to object storage. Only metadata passes through us." />

  <Card href="/docs/security/authentication" title="Authentication" description="How people and machines prove who they are." />

  <Card href="/docs/security/api-keys" title="API keys" description="Machine credentials, what they may hold, and what they may not." />

  <Card href="/docs/security/permissions" title="Permissions" description="The permission, not the role, is what the backend enforces." />

  <Card href="/docs/security/audit-log" title="Audit log" description="Every mutation recorded, with the actor that performed it." />

  <Card href="/docs/security/compliance" title="Compliance" description="What we do, and what we do not claim." />

  <Card href="/docs/security/disclosure" title="Disclosure" description="Reporting a vulnerability." />
</Cards>

## What this section is not [#what-this-section-is-not]

It is a description of how the system works, not a marketing page and not a certification.
Where a control is weaker than it sounds, the page says so in the same paragraph as the
control. The two places that matters most today:

* **Artifact locks are enforced by us, not by the storage layer.** See
  [retention](/docs/backups/retention#protection-lockfor).
* **Encryption is optional, and nothing refuses to run without it.** See
  [encryption](/docs/security/encryption#what-happens-without-a-key).

If you are evaluating us against a requirement, read
[the threat model](/docs/security/threat-model) first. It is the page that says what we do
not defend against.