Safe Desktop AI: Why a 'Control Vault' Is Really Two Separate Jobs

There is no single product called a 'control vault'

Searching for a control vault for AI agents turns up nothing sold under that name, because it describes two separate categories of product stitched together by the search phrase, not one thing you buy or install.

That matters because the honest fix for 'safe desktop AI' is not finding the one tool that does everything. It is understanding that you need a secrets vault and an access boundary, that they solve different problems, and that most tools on the market only do one of the two.

• No vendor ships a single product literally called a control vault.
• The phrase blends a secrets vault and an access boundary, which are two different things.
• Treating them as one job is the most common reason a 'secure' desktop AI setup still leaks.

The two controls you actually need

A secrets vault answers one question: where does the key live when nothing is using it. The macOS Keychain, a self-hosted Bitwarden server, or HashiCorp Vault for a team all answer it the same way, by encrypting the value at rest and releasing it to a process only at the moment that process needs it, instead of sitting in a plain .env file any program can open.

An access boundary answers a different question: once an AI agent or desktop app is running, what can it actually read, write, or reach. A locked-down folder, a Seatbelt sandbox profile, or a container all answer that one, independent of whether the agent is holding any secrets at all.

The mistake is assuming one covers the other. A vault that perfectly protects your API key does nothing if the agent can still read every other file on your Mac and send the contents somewhere. A tight folder lock does nothing if the key the agent needs is sitting in a plain text file inside the one folder it is allowed to touch. You need both, and they are set up separately.

• Secrets vault: protects the key when nothing is using it.
• Access boundary: limits what the running agent can reach, regardless of which keys it holds.
• A strong vault plus no boundary, or a strong boundary plus no vault, both fail differently.

Setting up the secrets half, step by step

Start by finding what is already exposed: grep your project folders and shell profile for anything that looks like a key or token in plain text. Treat every match as already leaked, because an agent session may have already read it.

On a Mac, the built-in option is Keychain Services, used from the command line with the security tool: security add-generic-password -s myapp -a myaccount -w the-secret-value stores it, and security find-generic-password -s myapp -a myaccount -w reads it back for a script to use. For a cross-platform setup, or a secret that needs to work the same way on a teammate's machine, a CLI vault such as the 1Password CLI's op run loads a secret and runs your command in a subprocess with it available only as an environment variable, never written to a file.

Either way, rotate anything that was ever sitting in a plaintext file before you moved it, because moving a copy does not undo an earlier exposure. A full comparison of vault options for a team or a multi-agent setup is covered in the dedicated guides linked below rather than repeated here.

• Find what is already exposed in plaintext files and your shell profile.
• macOS Keychain via the security command for a solo setup on one Mac.
• A CLI vault's run command for a team or a cross-platform setup.
• Rotate any key that was ever exposed, even after you move it.

Setting up the access half, step by step

An access boundary needs three decisions, in order: what the agent can write, what it can read, and what it can connect to. Most setups only answer the first one, confining writes to a project folder, and skip the other two, which is how an agent ends up able to read ~/.ssh or send data anywhere it likes even while its writes look contained.

On a Mac, you can apply this yourself with a Seatbelt profile through sandbox-exec, run the agent inside a container or virtual machine for a harder wall, or use a dedicated desktop app that applies the boundary for you. Whichever mechanism you pick, test it before you trust it: have the agent try to write outside the folder you expect, or read a file you expect to be blocked, and confirm it actually fails.

This is a different, and in most cases more important, step than choosing a vault. A vault protects one specific kind of value. An access boundary limits everything the agent can do, keys or no keys.

• Decide what the agent can write, read, and connect to, as three separate choices.
• Options: a Seatbelt profile you write yourself, a container or VM, or a dedicated tool's lock.
• Test the boundary directly. Do not assume it works because you configured it.

Wiring the two together

Do the secrets half first. If there is nothing left in a plain file for an access boundary to accidentally expose, a gap in the boundary is a smaller problem. Then add the boundary, so that even a legitimate read inside an allowed folder cannot wander into somewhere you did not intend.

In practice that means: move every key into the Keychain or a vault and confirm no plaintext copies remain, then turn on whatever boundary mechanism you chose and test it against the same project. Repeat the test after any change to either half, because a new dependency or a new folder in the project can quietly widen what the agent can reach.

• Order: secrets first, so there is less left to expose if the boundary has a gap.
• Then the boundary, so even an allowed read cannot wander further than intended.
• Re-test both after any change to the project or the setup.

What this combination still does not cover

Even with both halves in place, a few things remain outside their reach. Neither a vault nor a folder lock restricts what a command does with data it was already allowed to read, so an agent that can legitimately read a folder can still send its contents to the network unless you separately control egress.

A key you deliberately handed to a command is readable by that command for as long as it runs, by design, whether or not it came from a vault. And on Windows or Linux, Forkbench itself is not an option yet: it is a macOS app today, with Windows and Linux support in development and no release date set, so the boundary half on those platforms currently means a Seatbelt-style tool native to that OS, a container, or a VM instead.

• Neither control restricts what an already-allowed command does with data it reads.
• A key handed to a running command is usable by that command for as long as it runs.
• Forkbench's own Vault and folder lock are macOS only today.

A setup order you can follow today

Work through this once per project, not once per session, so the setup holds without you thinking about it every time you open a terminal.

• Audit for plaintext keys in files and your shell profile.
• Move keys into the Keychain or a CLI vault, and rotate anything exposed.
• Decide what the agent may write, read, and connect to, as three separate answers.
• Apply an access boundary that matches those answers, and test it directly.
• Repeat the test whenever the project or the setup changes.