Trust boundary
What walwarden holds and what stays customer-side — the load-bearing invariant of the product.
The trust boundary is the load-bearing invariant of walwarden. It is what makes the backups independent rather than just another copy held by a vendor you would have to trust.
The short version
- Walwarden never holds your target-DB write credentials.
- Walwarden never proxies or stores the dump bytes. The CLI pulls directly from your S3 bucket via a short-lived presigned URL.
- Backup bytes land in a bucket under your IAM role. Walwarden holds the schedule, the signed manifest, and the audit chain — not your data.
- Every restore state transition (token issued, claimed, downloading, verifying, restoring, completed or failed) is recorded in the audit chain. The payloads carry state labels and timestamps, never data content.
Why this matters
If walwarden held your write credentials and proxied your dump bytes, a compromise of walwarden would be a compromise of your data and your recovery path. The boundary is enforced by architecture — presigned URLs, customer-owned roles, CLI-local restore — not by policy.
Canonical reference
The full architectural description of the trust boundary, including the AssumeRole path and per-provider credential handling, lives in the reference:
- Trust boundary reference
- Destinations overview — how each provider's auth model affects the boundary
Agent-native workflow
How a coding agent discovers walwarden's machine-readable surface, runs a backup → restore-drill → evidence-bundle loop against test data, and reports it under scoped credentials with an auditable action history.
The audit chain
What the append-only audit chain records, what the dashboard surfaces, and how to verify an artifact offline.