Keeping secrets write-only (and why you should)

To check an authenticated API, Vigil needs a token. To probe a basic-auth staging site, it needs a password. Multiply that across a portfolio and your monitoring tool quietly becomes a vault of every credential you were trusted with — and a single readable copy is all an attacker needs.

Write-only by construction

So Vigil never lets a secret be read back. You write it once; from then on it exists only as a reference — ${secret:NAME} — inside a runbook. The database stores the reference, never the value. There is no API, no screen, and no log line that will ever return it to you.

Authorization: Bearer ${secret:API_TOKEN}

# resolved in memory for one rule run,
# then dropped. Never persisted, never logged.

At run time the worker resolves the reference from the vault in memory, uses it for exactly one check, and drops it. Every resolution is recorded in an access audit — which rule, which secret, when — with the value itself absent from the record.

The safest credential store is one that can’t show you the credential.— golden rule #1

It costs a little convenience: lose a secret and you re-enter it rather than copy it out. We think that’s the right trade for a service that, by design, holds the keys to everything you watch.