Unique data keys
Every protected record receives its own random symmetric key.
Designed so one compromised store is not enough.
Data Convoy treats object paths, destructive actions, and worker credentials as load-bearing security concerns. The result is a layered model built from explicit mechanisms—not a security adjective.
Metadata protection
Per-record envelope encryption
Path-bearing metadata is encrypted at rest with a unique XChaCha20-Poly1305 data key for each record. That data key is sealed to the team’s public key. Key-pair rotation can therefore re-seal small data keys without exposing or rewriting the underlying metadata plaintext.
Team key boundary
Data keys are sealed to a per-team public key; the private key is stored only in wrapped form.
Deliberate plaintext windows
The application handles paths transiently when users browse or explicitly view records, but does not persist path-bearing fields in cleartext.
Trust-domain split
The lock and the box live in different places.
The key-encryption key lives in AWS Secrets Manager, while KEK-wrapped team private keys live in the application database. A database dump alone cannot decrypt metadata; access to the KEK alone has no wrapped keys to open.
Operator noteThis is a defense against single-store compromise, not a claim that two-store compromise is impossible.
AWS access
Your workers assume your IAM role.
Workers use AWS STS role assumption in the customer environment to reach S3. Data Convoy does not require standing AWS access keys to customer data in its application tier. Worker bearer tokens are stored as SHA-256 hashes and shown in plaintext only when issued.
Authorization
Permissions map to blast radius.
Dry-run and copy-only operations are separated from production deletion and restore retrieval. Bucket repointing is separated from ordinary team editing. The server recomputes the needed permission from what a job actually does, so hiding a UI control is never the enforcement boundary.
Auditability
Append-only action history, archived before retention cleanup.
Privileged mutations, denied attempts, worker claims and completion, sign-in, and selected sensitive reads are written to an append-only audit table. Retention jobs export old records as NDJSON to the team’s own log bucket before deleting the database copy.
Your buckets. Your workers. Your control.