Zero standing keys: a migration playbook
Getting to no long-lived secrets is a project, not a switch. This is the order we recommend, and the traps in each phase.
Inventory before you move anything
You cannot remove what you cannot see. The first phase is discovery: every static key, service account and shared secret, mapped to what uses it and what it can reach. This is uncomfortable. It is supposed to be.
Expect the count to be larger than anyone believes. The teams most confident that they have 'a handful' of keys are usually the ones sitting on hundreds. Publish the number. Confidence follows visibility.
Cut over by blast radius, not by team
Do not migrate alphabetically or by whoever volunteers. Migrate by blast radius: the credentials that can move money or read sensitive data go first, because those are the ones a leak actually hurts you on.
For each, replace the standing key with on-demand scoped issuance. The agent asks, gets a minutes-long credential, and the static key is deleted, not just rotated. Deleting is the part people skip. Do not skip it.
Prove the zero
The goal state is zero standing keys, and you should be able to show it. When issuance is centralised, 'how many long-lived credentials exist' becomes a query with a number, not a survey with a shrug.
That number belongs on a dashboard your auditors can see. A migration that ends with a claim is a migration that quietly regresses. One that ends with a live count stays honest.
- #migration
- #secrets
- #rollout
More field notes
Short-lived credentials, in practice
Everyone agrees keys should expire. Then someone sets the TTL to a year so nothing breaks. Here is how we make minutes-long credentials survive contact with real workloads.
Priya Nandakumar · Head of Platform
7 min read
Writing policy at execution time, not deploy time
Access decisions baked in at deploy are stale by the time they matter. We evaluate the policy graph the moment an agent acts. Here is what that buys you.
Priya Nandakumar · Head of Platform
6 min read