A secret reference that quietly stopped pointing anywhere real
An External Secret had been serving the same value for weeks — because the Vault path behind it had been renamed during a migration, and nothing was checking whether the reference still resolved.
What happened
SreNix never touches secrets or Vault paths on its own. Here is why.
- Detect: a check available on paid plans reads every External Secret's Vault path and confirms, against Vault itself, that the path still exists.
- Cause: the path had been renamed three weeks earlier during a Vault reorganisation. The External Secret was never updated, so it kept serving its last cached value instead of failing loudly.
- Decision: changing what a secret reference points at is exactly the kind of action SreNix is built to never take by itself.
- Escalate: a signed link went to the secret's owner, naming the exact reference and the path it could no longer reach.
- Verify: once the reference was corrected, SreNix confirmed the path resolved and the secret was syncing current values again.
Why this one waits for a person
Secrets are the one thing every part of SreNix is built to leave alone. Detecting that a reference is broken is exactly the deep, unglamorous checking this catalog exists for — deciding where it should point instead is always a human call.
This is the same boundary described on the security page: no long-lived keys, and nothing that touches a secret's contents or its reference without a named person approving it. Read the safety envelope.
On-call should be quieter every week
Helm install in 5 minutes. No telemetry exfiltration. No per-investigation surprises.