A Slack webhook URL is a secret — the token is in the path — and a config document is versioned, GET-able, and copied into an audit chain that can never be edited. So a channel document never holds the value; it holds a reference, and secret:<name> is the default worth understanding.
Every stored secret is sealed to one recipient — the single service that will use it: notifier for webhook URLs and SMTP passwords, keysvc for HSM PINs and cloud-KMS credentials. There is no shared secrets key. Each consuming service holds an X25519 private key in a file and registers its public key at startup; the management API seals on write and can never read a value back. Only the addressed service opens it. A database dump therefore never contains a usable plaintext secret — the at-rest property, applied to your backups too.
The operational catch: the key files must live on a persistent volume. An ephemeral filesystem regenerates a fresh key every restart, orphaning every secret sealed to the old one — the boot log says so loudly. Escrow the key files alongside the master secret; losing one loses only re-enterable values, but re-entering them all is a bad afternoon.
Now I can store a webhook secret the management API itself cannot read.