A Simple Secret Vault for CLI Agents

What I built and where the security boundary lies

By September 2026, I had built a basic secret vault for my own CLI agents. In my Medium article about creating a secret manager, I described the project and the reason it emerged. It is not an attempt to replace mature secret stores, but a practical answer to an uncomfortable question: what exactly does an agent receive when it is given access to a token?

The core principle is simple: a secret must never appear in a prompt, instruction, or repository. If an agent sees an API key as ordinary text, prompt injection or a failed tool call can turn local automation into a data-exfiltration channel. It is safer to store an opaque reference and inject the real value only while a command is running.

For a local CLI, the operating system's secure credential store is a sensible foundation. Keeper Secrets Manager CLI documentation describes storing configuration through macOS Keychain, Windows Credential Manager, and Linux Secret Service. Python's keyring library offers a unified interface to these system mechanisms, so a home-built vault does not need to invent its own key storage.

For production, it makes more sense to separate the CLI from persistent secrets entirely. Google Secret Manager and AWS Secrets Manager document storage and retrieval of API keys, passwords, and other sensitive values, while AWS also documents rotation. In this model, the CLI becomes an intermediary rather than the safe itself.

But a vault only solves storage. The next layer must issue short-lived credentials for a single task or session, restrict the agent's file and network access, and log tool-level requests. Otherwise, we have simply hidden an overly powerful key more neatly.

Why a vault alone is not enough

The main benefit is not a new storage format, but separating the model from the secret. The agent can retain the right to request an operation without seeing the value that signs or authorizes it.

For local experiments, even a primitive vault is better than a token in a file beside the project. For autonomous agents, it is not enough: least privilege, sandboxing, access revocation, rotation, and action logs are all needed. The weakest pattern remains a long-lived universal key in every process's environment variables.

I would first inspect not the encryption of the store, but the secret's path after retrieval. Command-line arguments, logs, error dumps, and model context are particularly dangerous. Without last-mile controls, even a strong backend becomes an expensive way to send a secret to the wrong place.

That is why my primitive vault is more interesting as a starting point for the right architecture. The real security boundary is not around a file of keys, but around every operation an agent can perform on the user's behalf.

We previously examined how Secret Storage in Obsidian affects the security of plugins and AI automation. These principles are also useful when designing a secret vault accessed by agents.