Secret Manager

Your Secrets Live in the OS Keychain,
Not in a Prompt and Not in Your Repo

AgentsRoom stores API keys, tokens and database passwords in a machine-local vault encrypted through your operating system keychain. You reference them by name, and the app resolves them when a command or an agent starts.

Stop pasting a token into a prompt because it was the quickest way to unblock an agent. Name the secret once, use {{secret:NAME}} everywhere else, and let the value stay where it belongs.

Download AgentsRoomFreeSee how it works

Secret vault

Encrypted by the OS keychain

AI agent

STRIPE_SECRET_KEY

SENTRY_AUTH_TOKEN

NPM_TOKEN

Reads the names

Never receives a value

Machine-local vault

STRIPE_SECRET_KEY

0600, owner only

Dev server command

Resolved at launch : Main process only

Reference by name, resolve at launchNever leaves your machine

How AgentsRoom keeps a secret usable by your commands and unreadable by the agent that asks for it.

Every project ends up with a handful of values that must not be shared : a payment key, a database password, a deploy token, an API key for the staging environment. The moment AI coding agents enter the picture, those values start moving in the worst possible way. They get pasted into a prompt to unblock an agent, hardcoded into a script the agent wrote, or dropped into a file that gets committed three commits later.

The AgentsRoom secret manager gives them one place to live. A secret is a name and a value : you add it once, and AgentsRoom encrypts it through your operating system keychain before it ever touches the disk. The whole vault is a single file in your home folder, written with owner-only permissions, and it never leaves the machine it was created on.

From then on you never handle the value again. You write {{secret:NAME}} in a dev command or in an agent environment, and AgentsRoom substitutes the real value when that command or that agent starts. Your agents can list the names and ask for one to be injected, which is enough to do their job, and they never get the value itself.

A Vault Built for a Machine Full of AI Agents

Encrypted by the operating system, referenced by name, resolved at the last possible moment.

Encrypted by Your OS Keychain

Every value is encrypted through Electron safeStorage, which means the encryption key is held by your operating system keychain and not by AgentsRoom. The app stores ciphertext and asks the system to decrypt it, exactly like the other applications you already trust with credentials.

One Vault File, Owner Only

All your secrets live in a single vault at ~/.agentsroom/secrets.json, written with owner-only permissions (0600) and replaced atomically on every change. No half-written file after a crash, and no other user account on the machine can open it.

Reference by Name, Never by Value

A saved secret is used as {{secret:NAME}} : in the command line of a dev terminal, in the environment given to an agent, anywhere you would otherwise have typed the credential. What you read on screen, and what you could show a teammate, is the name.

Resolved at Launch, in the Main Process

The substitution happens when the process starts, inside the Electron main process. The resolved value goes into the environment of the command being launched and nowhere else : not into a log, not into the interface, not into a file on disk.

Agents See Names, Not Values

An AI agent can list the names of your secrets and ask for one to be injected into something it is about to run. There is no code path that hands a value back to an agent, to the interface layer or over MCP. The agent works with the reference, the app works with the secret.

No Keychain, No Storage

If the machine cannot offer a working OS keychain, AgentsRoom refuses to save the secret instead of falling back to clear text. A vault that silently degrades into a plain file is worse than no vault, so that fallback simply does not exist.

Machine-Local by Design, Not by Default Setting

Your secrets are never sent to AgentsRoom servers. There is no sync toggle to check, no cloud vault to opt out of, and no backup of your keys anywhere but your own disk. The vault is created on the machine, encrypted with a key that the operating system keychain holds for that machine, and it stays there. A copy of the file on its own is not something another machine can open.

The separation between using a secret and reading a secret is enforced in code, not by an instruction written in a prompt. The interface layer, the MCP tools and every agent talk about secrets by name. Only the Electron main process turns a reference into a value: while it is building the environment of a process you asked it to start, or, if you turned on live data for HTML views in a project, when it adds a header to a request to an endpoint you allowed, which the page never sees. Telling an agent to be careful with credentials is a hope. Not having a function that returns the credential is a guarantee.

That is what makes it reasonable to let an agent work against a paid API or a real database. The agent knows a secret named STRIPE_SECRET_KEY exists and can ask for it to be injected into the command it wants to run. It cannot print it, cannot copy it into a file it is writing, and cannot leak it into a conversation stored somewhere else.

From a Pasted Token to a Named Secret

Three steps, and the value never appears again.

Add the secret once

Give it a name and paste the value one last time. AgentsRoom encrypts it through the OS keychain and writes it into the vault at ~/.agentsroom/secrets.json, owner-only and atomically. If the machine has no usable keychain, the app says so and refuses rather than writing clear text.

Reference it as {{secret:NAME}}

Use the reference wherever the value used to go : the command that starts your dev server, or the environment of an agent that needs an API token. What is stored in your settings is the reference, and it is safe to look at.

Let AgentsRoom resolve it at launch

When the command or the agent starts, the main process swaps the reference for the real value in the environment of that process. Your tooling gets what it needs, and the agent driving it still only ever knew the name.

When a Secret Manager Stops Being Optional

The situations where a pasted credential turns into a real incident.

Dev servers that need real keys

Your dev server will not boot without a payment key and a database password. Put {{secret:NAME}} in the launch command instead of the credential, and the command becomes something you can leave on screen during a call without a moment of panic.

Agents that call a paid API

An agent needs a token to reach a third-party API while it works. Add the secret to its environment by name : the agent gets a working environment, and the token is not in the prompt, not in the conversation and not in whatever the agent writes next.

Keys that stop landing in the repo

The usual accident is a credential written into a config file that a later commit sweeps up. Referencing secrets by name means the file tracked in the repository holds a name, so there is nothing to leak when the branch is pushed.

One machine, many projects

A single vault, protected by your OS keychain and readable only by your user account, serves every project you open. Each project references the names it needs, and none of them keeps its own scattered copy of a credential.

AI agents + secrets

How can an agent use a secret it cannot read?

secrets_list

Because using a credential and reading a credential are two different operations, and AgentsRoom only implements the first one for agents. The vault is exposed over MCP by exactly one tool, secrets_list, and it returns names. From there the agent writes {{secret:NAME}} in the command or the environment it needs, and the substitution is carried out by the app, not by the agent.

What is deliberately missing is the other direction. No MCP tool returns a secret value, the interface layer never receives one, and nothing renders it back into a conversation. Turning a reference into an actual value happens inside the Electron main process, at the moment a process is launched, and the result goes into that process environment and nowhere else. The one exception is opt-in and per project: a request header for an endpoint you allowed for your HTML views, added by the main process and never shown to the page.

The practical effect is that an agent can run your test suite against a real database, call a paid API or deploy to staging without a single credential entering its context. Nothing to redact afterwards, because nothing was ever exposed.

Discover AgentsRoom MCP

FAQ

Ask us something else

Where are my secrets stored?

In a single vault file at ~/.agentsroom/secrets.json in your home folder. Each value is encrypted through Electron safeStorage, so the encryption key is held by your operating system keychain. The file is written with owner-only permissions (0600) and replaced atomically, so a crash never leaves it half-written.

Can my AI agent read my secrets?

No. An agent can list the names of your secrets and ask for one to be injected into a command or an environment, which is all it needs to get work done. There is no code path that returns a value to an agent, to the interface layer or over MCP. The resolution happens in the Electron main process only.

Are my secrets synced to AgentsRoom servers?

Never. The vault is machine-local by design. Secrets are not sent to AgentsRoom servers, not backed up in a cloud and not relayed to the mobile app. They are created on your machine, encrypted for your machine, and they stay there.

How do I use a secret in a command?

Write {{secret:NAME}} where the value would have gone : in a dev terminal command, or in the environment of an agent. AgentsRoom substitutes the real value when that process is launched, and the reference is what stays in your settings.

What happens if my machine has no OS keychain?

AgentsRoom refuses to store the secret. There is deliberately no fallback that writes the value in clear text on disk, because a vault that silently degrades into a plain file gives you the confidence of encryption without the encryption.

Does this replace the environment files in my project?

It solves the part of the problem that hurts once AI agents are involved : keeping the credential out of the files, the prompts and the conversations. Your project keeps whatever it needs at runtime, and the value itself lives in the vault and is injected at launch instead of sitting in a file an agent can read and a commit can sweep up.

If someone copies the vault file, can they read it?

Not on another machine. The values are encrypted with a key that your operating system keychain holds, so the file taken on its own is ciphertext. On top of that, the vault is written with owner-only permissions, so another user account on the same machine cannot open it either.

Which MCP tool do my agents use for secrets?

secrets_list, and it is the only one. It returns the names of the secrets stored on this machine, so an agent can discover what exists and then reference one as {{secret:NAME}} in a dev command or in the environment of a process it starts. No tool returns a value, so there is nothing for an agent to print, copy into a file it is writing or leak into a conversation. When a secret it needs is missing, it asks you to add it in the app rather than asking you to paste it into the chat.