Fourth in our series on the stack we run Inside Intelligence on. We've covered the books, the tickets, and the wiki. Now: the thing that keeps all of it safe — the secrets.
We run a self-hosted secrets vault on our private infrastructure. Same posture as everything else in the stack.
Why a vault, and why it's the single source of truth
Every system has secrets: database passwords, API keys, app keys, tokens. The question is where they live. The bad answer is scattered across config files, `.env` files, and repos — where a single leak exposes everything. The good answer is one place, encrypted, that everything pulls from.
So we made a rule: the vault is the single source of truth for secrets. No plaintext secrets in config files. No secrets in repos. If a service needs a credential, it gets it from the vault — pulled once at startup, held in memory, never written to disk.
The part that matters: an agent fetches secrets safely
Here's where it becomes Operator. We didn't just install a password manager and call it done. We wired the whole stack so agents fetch secrets from the vault — the same way Operator would manage a client's credentials.
When a service starts, it pulls its secrets from the vault in one batch, holds them in memory, and never writes them to disk. There's no session cache, no temp file, no plaintext sitting around. The secrets exist only in the running process's memory.
Security isn't a policy you set. It's a property of where your secrets live. One encrypted vault, pulled into memory at startup, never on disk. That's the discipline we hold ourselves to — and the same discipline we'd bring to a client's.
Why this matters for a duty-of-care office
If you run a law, medical, financial, or licensed-trade office, you don't care about where our secrets live. You care about this: your credentials aren't scattered around. They're in one encrypted place, and the systems that need them pull them safely, without leaving a trail of plaintext behind.
That's what protecting client data looks like in practice. It's not a checkbox. It's an architecture.
We'll tie the whole stack together — how Operator uses all of it as one operations team in a box.
← Back to Field Notes