Secrets Belong in Vaults: How We Handle Keys in an Agentic World

Give an AI agent access to a codebase so it can actually help you build, and you've also given it access to every file in that codebase — including, if you're not careful, the .env file sitting quietly in the root with a real API key or database password in it. Most of the time nothing bad happens with that. "Most of the time" is a bet, not a guarantee, and the more autonomy an agent has, the worse a wrong outcome on that bet gets. An agent that can read a file can, in principle, echo it back, log it, or act on it in a way nobody intended.

The fix isn't "trust the agent more carefully." It's removing the plaintext secret from anywhere an agent could ever see it in the first place.

The design: the agent never sees the real value

Secrets get pasted into a dedicated, visibly-secure surface — not the same chat box or file editor everything else goes through. Selecting it changes what that input actually is: a secure entry field, distinct enough in its own presentation that it's obvious you're in a different mode, not just typing into the same box as everything else.

From there, whatever gets dropped in — a single key, or a whole messy page copied straight from a provider's dashboard — goes through a deterministic parser that runs locally and never touches an AI model or a network call. It's pattern-matching, not an AI reading your secrets: recognizing the actual shape of a real credential (the prefix patterns real API keys and tokens follow, the structure of a database connection string, a long high-entropy token) and pulling those values out specifically, while ignoring the surrounding metadata that looks similar but isn't the secret itself. The values it finds get encrypted and stored. What comes back into the conversation is a reference — a name standing in for the secret — never the value itself.

That's the actual architecture, stated plainly: the AI operates on named references it can use functionally, without the raw value ever entering its context at any point. It can be told "use the payment key" and act on that instruction. It's never shown what the payment key actually is.

What's underneath the reference

The encryption isn't cosmetic. Values are encrypted at rest with a modern authenticated-encryption standard, protected by a key derivation process designed specifically to resist brute-force attempts, and unlocked through the same trust mechanisms a person already uses for everything else sensitive on their own machine — a fingerprint or face unlock where the hardware supports it, a device passphrase as a fallback, with a recovery phrase as the option that's guaranteed to work even if every other unlock method is unavailable. A second layer — a one-time code from an authenticator app — can sit in front of any of those as an added gate, the same pattern a bank or a major platform already uses, without becoming the thing that unlocks the secret on its own.

The system is built to detect what a given device is actually capable of and lead with the strongest option it has, falling back gracefully rather than forcing everyone through the weakest common option by default. That's a deliberate amount of engineering for something that, on paper, "just stores a password." The reason for the extra investment is straightforward: people need to actually feel confident handing something sensitive to a system before they'll do it, and a vault that's merely secure but doesn't visibly earn that trust doesn't get used the way it needs to be.

The parsing problem, stated honestly

An earlier version of the deterministic parser had a real, specific failure worth naming rather than glossing over: given a pasted API-key object, it correctly saved the surrounding metadata — creation date, status, a partial key hint — and missed the actual secret value sitting right next to it. The fix wasn't a patch on top of a broken approach; it was re-ranking what counts as a candidate in the first place, prioritizing values that are actually shaped like real credentials over field names that merely sound like they might be one. Every extracted value gets shown as a masked preview before it's saved, with an explicit confirmation step, so a parsing mistake gets caught by a human glance before it's committed rather than after.

That failure is worth including here for the same reason the truth gate governs the rest of this launch: a security feature that's described as flawless when it once had a real, documented gap isn't actually more trustworthy for skipping that detail. It's less trustworthy, because the gap gets found by someone else eventually, and "we knew and fixed it" is a much better position than "we didn't mention it."

Why this matters more, not less, as agents get more capable

The instinct might be that more capable AI agents need less hand-holding around something as basic as secrets. It's closer to the opposite. A more capable agent takes more autonomous actions, touches more of a codebase in a single session, and is trusted with more consequential tasks — which means the cost of it ever seeing a raw credential, even by accident, goes up as its capability does, not down. Building the vault as a first-class, dedicated surface — rather than "be careful what you paste into the chat" as a policy nobody consistently follows — is what makes it possible to keep extending an agent's autonomy without that autonomy ever being the thing that leaks a key. The agent gets more capable. The secret never gets more exposed. Those two things are only both true if the vault is real infrastructure, not a habit.