Guide
How to Safeguard a Desktop AI Agent With a Local Vault
A desktop AI agent reads with your permissions, so a plain text secret in your project folder is a secret it can read too. A local vault is how you fix that.
The reliable way to safeguard a desktop AI software agent is to take every secret out of the project folder and put it in your operating system's keychain or a secrets manager, then hand the value to a command only at the moment it runs. Tools like the macOS Keychain, the 1Password CLI, or HashiCorp Vault all do this: the agent can still run the command that needs a password or API key, but it never has a file containing that password to read. This does not make the agent harmless on its own. Once a command has the secret, what that command does with it is still up to the command, which is why scoping each key narrowly still matters.
Why a desktop agent needs more than good behavior
A coding agent that runs on your desktop operates with your own user permissions. It reads configuration files, lists directories and runs shell commands to understand a codebase, and none of that requires special access beyond what you already have. That is what makes it useful, and it is also why a secret left in the open is not a hypothetical risk.
A .env file in the project root, AWS credentials sitting in your home directory, or a key hardcoded in a test script will be read the moment the agent needs context to do its job. The agent is not looking for secrets specifically. It reads broadly because reading is how it works, and a list of environment variables is exactly the kind of thing it reads to understand how a service is configured.
Once a value like that is read, it is part of the agent's working context, and depending on the tool, that context can be sent to a model provider or printed to the terminal during debugging. Telling the agent not to read certain files is a request, and a request made in a prompt can be forgotten over a long session or ignored by a later instruction.
- An agent reads with the same permissions as the person who started it.
- A value it reads becomes part of its context, which may be sent to a model provider.
- An instruction not to read a file is a request, not a technical control.
'AI software agent vs safeguard' is not a real matchup
People search variations of ai software agent vs safeguard expecting to find two competing products. There is no single tool called Safeguard. What the phrase usually points to is a set of practices: restricting what an agent can reach, watching what it does at runtime, and keeping the credentials it needs somewhere the agent cannot read directly.
A runtime guardrail toolkit like NVIDIA's open source NeMo Guardrails is one piece of that practice. It sits between an application and the model, applying configurable rules across five rail types, including input, dialog and output, that can catch a jailbreak attempt or a prompt injection and stop a conversation before it goes somewhere it should not. It does not replace a vault. It is a different layer, aimed at the conversation, not the credentials.
An agent and a safeguard are not opponents. The agent is built to act on your behalf. The safeguard is the boundary you put around what it can act on, and around what it can see while it works. Both pieces matter, and neither one substitutes for the other.
- There is no single product named Safeguard; it refers to a set of access and runtime practices.
- NeMo Guardrails filters conversation flow, including jailbreak and prompt injection attempts; it is not a vault.
- A guardrail and a vault solve different problems and are normally used together.
Moving secrets out of the project folder
The first concrete step is deleting every plain text secret from the project and putting the replacements in a secrets manager. If your team already uses 1Password, the CLI command op read op://app-prod/db/password prints that one value, and a line like export DB_PASS=$(op read op://app-prod/db/password) puts it into an environment variable for the current shell session only, never onto disk.
If you would rather stay inside the operating system, the macOS Keychain works the same way from the command line. A command such as security find-generic-password -a account_name -s service_name -w retrieves a stored password. The first time a new command line tool tries to read a Keychain item, macOS prompts you for permission, so nothing is pulled silently the first time.
Either approach gets you the same result: the secret exists in memory for as long as the one command needs it, and there is no file in the project for the agent, or anyone else with access to that folder, to find later.
- Use op read with a secret reference like op://vault/item/field to fetch one value at a time.
- Use security find-generic-password on macOS to pull a password straight from the Keychain.
- Both methods keep the secret in memory for one command instead of in a file on disk.
Wrapping deployment commands instead of storing the token
A desktop app that manages coding agents has to give the agent enough to do its job, like compiling code or deploying a build, without handing over broad access to every credential on the machine. The practical way to do that is to wrap the sensitive command in a small script.
Instead of letting the agent read a Vercel or AWS token from a file, the script fetches that token from your secrets manager at the moment the deploy command runs, and the agent only ever calls the script. It never sees, and does not need to see, the token the script used underneath.
This also keeps the blast radius small if something does go wrong. The agent can trigger a deploy, but it cannot casually dump every credential on the machine, because there is no file or environment variable sitting around with all of them in it.
- Wrap sensitive commands in a script that fetches credentials at the moment it runs.
- The agent calls the script by name; it never sees the token the script uses.
- This limits exposure to the one credential the script needed, not everything on the machine.
Short-lived credentials with HashiCorp Vault
For a more demanding setup, HashiCorp Vault issues short-lived credentials instead of a static key that works forever. On a current Vault install, the recommended way to read one is a command like vault kv get -mount=secret -field=password my-app, which uses the newer mount flag syntax instead of the older path style that can be confusing on the KV version 2 secrets engine.
Vault can also generate a credential, for a database connection for example, that is only valid for a fixed window and expires automatically after that. If an agent's session ends or a key leaks into a log, the damage is limited to whatever that credential could do during the time it was still valid.
This is more infrastructure than most individual developers need, and it is the right call for a team running many agents against production systems, where one leaked static key would otherwise be a much bigger incident.
- vault kv get -mount=secret -field=password my-app is the current recommended read syntax.
- Vault can issue credentials that expire automatically instead of one key that never changes.
- This trades setup effort for a much smaller blast radius if a credential ever leaks.
What a vault does not fix
Keeping a secret out of a file stops the agent from reading it by accident. It does not stop the agent from using a secret you deliberately handed it through a command. If an agent can run a command that deletes a cloud resource, that command can still do that whether or not the agent ever saw the underlying token.
So a vault has to be paired with scope. Give each key only the access it actually needs, use separate keys for separate jobs, and keep production credentials out of sessions where an agent is still experimenting with an approach. A narrow key that leaks is an inconvenience. A key that can do anything is an incident.
The same logic applies to anything a program prints. If a script run by the agent logs its full environment for debugging, a secret you kept out of a file can still end up in the terminal output. A vault protects where the secret rests, not what happens after a process uses it.
- A vault stops accidental reading, not deliberate use of a key the agent was handed.
- Scope keys narrowly so a leak is an inconvenience rather than a full incident.
- A command that prints its own environment can still expose a secret the vault protected.
How Forkbench fits into a desktop vault setup
Forkbench is a desktop app that runs coding agents in a terminal on your Mac. Its Vault stores secrets in your macOS Keychain, and an agent uses one by referring to it by name. Forkbench applies the actual value when the command starts, and the agent's conversation history never contains the value itself.
The same limit applies here as anywhere else: an unpinned Vault key can still be read by the program that ran, if that program chooses to print it or write it to a file. Forkbench keeps the value out of the agent's view, but it does not inspect what the command does with the value once it has it.
Forkbench also does not change what is readable in the project folder. A plain text .env file left there is still something the agent can open, exactly as before. The Vault protects what you put in it, which is why moving existing secrets there, and deleting the plain copies, is still the first step.
- Forkbench's Vault keeps secrets in the macOS Keychain and releases them by name, not by value.
- An unpinned Vault key can still be read by the program that ran if that program prints it.
- Files left in the project folder stay readable; the Vault only protects what you move into it.
Related: Stop coding agents reading your .env file, An agent read my API keys, what now, Give an agent deploy access without the credential, How Forkbench handles your data
Frequently asked
Is there a single product called Safeguard for AI agents?
No. It is shorthand for a set of practices: restricting file access, adding runtime guardrails, and storing credentials in a vault instead of a plain file.
How do I pass a password to a local agent without a .env file?
Fetch it from a secrets manager at the moment the command runs, for example with 1Password's op read or the macOS security command, so it lands in an environment variable for one command instead of a file.
Can an AI agent read my macOS Keychain without asking?
No. macOS prompts for explicit permission the first time any new command line tool requests a stored password, so nothing is pulled silently.
Does Forkbench stop an agent from reading every file in my project?
No. Forkbench's Vault protects secrets you store in it by keeping the value out of the agent's view. It does not stop the agent from reading a plain text file you left in the project folder.