Designated-verifier audit

Let a third party confirm your backups exist and are intact, without ever seeing your encryption key or your code. Built for SOC 2 auditors, compliance teams, and cross-team trust.

Overview

When you run devsafe audit, DevSafe generates a cryptographic proof that your backups are complete and untampered. The verifier (an auditor, a teammate, a compliance bot) can check this proof using only their own verifier key. They never receive your encryption key, your plaintext data, or access to your user-owned storage.

This is called a designated-verifier proof. It answers one question: "Do the backups exist, and are they intact?" It does not reveal what is inside them.

How it works

The audit system uses a two-layer approach:

• Layer 1: Merkle tree. DevSafe builds a hash tree over every git bundle in your backup chain. Each leaf is the hash of one encrypted bundle. The root hash represents the entire chain.
• Layer 2: AEAD tag verification. Each bundle was encrypted with nonce-unique AEAD (AES-256-GCM). The authentication tags prove the data has not been modified since encryption.

The verifier receives the Merkle root, the list of authentication tags, and a signed timestamp. They can confirm that every bundle exists and that no bundle has been altered. They cannot decrypt anything.

Setting up a verifier

Before anyone can verify your backups, you need to create a verifier identity. This is a one-time setup per verifier.

Step 1: Initialize the verifier system

$ devsafe setup-verifier
→ generating verifier keypair...
✓ verifier system initialized
✓ public verification key saved to ~/.devsafe/verifier-pub.pem

# share verifier-pub.pem with anyone who needs to verify your backups

This generates a keypair used to sign audit proofs. The public key is what you share with verifiers. The private key stays on your machine and is used to sign proofs.

Step 2: Add a verifier

Register a named verifier. This is the person or system that will check your proofs.

$ devsafe add-verifier --name "acme-auditor" --email "auditor@acme.com"
✓ verifier "acme-auditor" added
✓ verification token generated (expires in 90 days)
  token: dvs_vrf_8a3f...c291

# send this token to your auditor through a secure channel

The token is what the verifier uses to authenticate when checking proofs. You can set a custom expiry with --expires 30d or --expires 2026-12-31.

Running an audit

Once you have at least one verifier set up, run the audit.

$ devsafe audit
→ building Merkle tree over 847 bundles...
→ verifying AEAD authentication tags...
→ signing proof for 2 registered verifiers...
✓ audit proof generated
  merkle root: a4f8c1...e39b
  bundles verified: 847 / 847
  chain integrity: intact
  timestamp: 2026-07-01T14:22:08Z
✓ proof saved to ~/.devsafe/proofs/audit-2026-07-01.json

The proof file contains everything the verifier needs. Send it to them directly, or use the --send flag to deliver it automatically.

$ devsafe audit --send "acme-auditor"
✓ audit proof generated and sent to acme-auditor

Flags

• --send <verifier-name> sends the proof to a specific verifier after generation.
• --repo <name> limits the audit to a single repository instead of all repos.
• --since <date> only includes bundles created after the given date.
• --format json|text controls the output format. Defaults to text.
• --quiet suppresses progress output. Only prints the Merkle root on success.

Managing verifiers

List all verifiers

$ devsafe list-verifiers
name             email                  status    expires
────────────────────────────────────────────────────────────
acme-auditor     auditor@acme.com       active    2026-09-29
internal-ci      ci-bot@mycompany.com   active    2027-01-01
old-contractor   jane@contractor.io     expired   2026-05-15

Revoke a verifier

When someone no longer needs access to your audit proofs, revoke their token.

$ devsafe revoke-verifier --name "old-contractor"
✓ verifier "old-contractor" revoked
  future proofs will not be signed for this verifier

Revoking a verifier does not invalidate proofs they already received. It only prevents new proofs from being generated for them.

Compliance use cases

SOC 2 audits. Your auditor needs evidence that source code is backed up and that backups are tested. Run devsafe audit before each audit window. The proof file serves as machine-verifiable evidence that every repository has a complete, untampered backup chain.

Team trust. In organizations where multiple developers maintain independent backups, the audit system lets a team lead confirm that everyone's backups are current without accessing anyone's code or keys.

Automated verification. Pipe devsafe audit --format json --quiet into your CI pipeline. If the exit code is non-zero, the backup chain has a gap or a tampered bundle. You can alert on this like any other health check.

# run a weekly audit and alert if anything is wrong
$ devsafe audit --format json --quiet || notify-team "Backup audit failed"

Security model

The verifier learns exactly three things from an audit proof:

• How many git bundles exist in the backup chain.
• Whether every bundle passes its AEAD authentication tag check (meaning it has not been modified).
• The timestamp when the proof was generated.

The verifier does not learn:

• The contents of any repository.
• File names, branch names, commit messages, or any other metadata.
• Your encryption key or any key material.
• The location of your user-owned storage.