Trust and security
This page is for a security review of SafeGrd. Each section links to the document that carries the detail.
Where encryption happens
Backups are encrypted on your host before anything is uploaded. The CLI compresses each backup with zstandard and encrypts it with Age (X25519 and ChaCha20-Poly1305). The host needs only the public key to write a backup. The manifest of tables, files and messages is sealed inside the encrypted archive. Security and key custody has the details.
What SafeGrd never receives
- Your backup data. It goes from your host to the bucket, already encrypted, and never passes through SafeGrd’s control plane. This holds on SafeGrd-hosted storage too. A drill you set to run on SafeGrd restores the snapshot on a machine started for that drill alone and destroyed when it ends. The sub-processor list names where.
- Filenames, table contents or email subjects.
- Your private key, when you hold it yourself.
- Database, mailbox and storage passwords, unless you choose to have SafeGrd hold them.
Who holds the key
Each organization chooses who holds its key, and the console shows which mode it is in. Who holds your database and storage credentials is a separate choice.
In DEK and KEK terms, each backup is encrypted under its own data key, which is wrapped by your age key pair. That key pair is the KEK, and the choice below is who holds its private half (details).
| Mode | What it gives you |
|---|---|
| SafeGrd-managed key (the default) | SafeGrd keeps your key sealed and releases it only to your enrolled hosts, so you can restore even after losing a host. Each release is written to the audit log before it happens. A console session, a personal access token or an administrator cannot retrieve it. |
| Customer-managed key | Only you can decrypt these backups. SafeGrd holds the public key. Keep a copy of the key file somewhere safe. |
| Credentials held by SafeGrd | Database, mailbox and storage credentials are sealed per organization and sent only to your enrolled hosts when a surface backs up. They cannot be read back through the console or the API. |
Backups that cannot be deleted
Backups are written under S3 Object Lock in compliance mode, so no account can delete one before its retention ends, including your bucket’s root credentials and SafeGrd. A token given to an AI agent can list, back up and test backups, and has no delete permission. Threat Shield and AI agents (MCP) have the details.
If SafeGrd is unavailable
Your hosts keep their own schedule and keep backing up to your bucket. The CLI lists,
verifies and restores backups from that bucket with or without a SafeGrd account.
safegrd restore --to-sql writes a PostgreSQL snapshot as SQL and COPY
files that plain psql loads, so a database comes back without SafeGrd’s
restore code, and a plain-text RECOVERY.md beside every snapshot says where
it is and how to restore it (what it holds). Its source
is public at github.com/safegrd/cli under the
Business Source License 1.1, so every claim on this page about what leaves your host can be
checked in the code.
Licence and continuity
The CLI and daemon are published under the Business Source License 1.1 (licence). Three of its terms matter to a buyer planning for the long term:
- Listing, verifying, restoring and exporting your backups is allowed at any time, with or without a SafeGrd account or server.
- If SafeGrd stops running its service, the licence allows all production use of the CLI and daemon.
- Each version becomes available under the GPL v3 four years after it is published.
Sign-in
- Passwords are stored as bcrypt hashes.
- Every new account is sent a 6-digit code to confirm its email address.
- The console session cookie is
HttpOnly,SecureandSameSite=Strict, and pages are served with a Content Security Policy. - Two-factor sign-in with an authenticator app (TOTP), with ten single-use recovery codes. The code is asked at sign-in and again before deleting anything, handing over an organization or cancelling its subscription. A member can have a browser remembered for 30 days, and an organization can turn that off. A password reset does not turn two-factor off.
- An organization can require two-factor of every member. Until a member turns it on, their console session can only set it up.
- The TOTP secret is stored encrypted under SafeGrd's root key, and recovery codes only as keyed hashes.
Data protection
- Data Processing Agreement under Article 28 of the GDPR.
- Sub-processors, with what each one can see.
- Privacy Notice.
Reporting a vulnerability
Send reports to security@safegrd.dev. Do not test against other customers’ data. We do not take legal action against researchers who report in good faith and keep the issue private until it is fixed. The machine-readable contact is at /.well-known/security.txt.