# A secret your agent never sees.

How MCPBytes Vault lets an agent create keys and tokens that stay on your computer, and why the randomness behind them matters.

September 24, 2026 · MCPBytes · https://mcpbytes.com/blog/secrets-your-agent-never-sees

Agents are good at setup work. Wire up a webhook, configure a service, connect two of your apps. Sooner or later, that work needs a secret: a signing key, a session secret, a token.

The easy way is for the agent to make one up and paste it where it's needed. But everything an agent writes lands in the conversation, and a conversation is kept. It sits in your history and in logs, and sometimes it gets shared or pasted into a ticket. A key that has been through a chat is hard to call secret.

MCPBytes Vault takes a different route. Your agent asks for a secret and gets back a name for it. The secret itself goes straight to your computer's own vault.

## Out of the conversation

Vault is a small helper that runs on your computer, next to your agent. It gives your agent one tool for making secrets, `get_random_bytes`. The agent chooses three things:

- a **label**, like `agent-webhook-signing`, starting with a prefix you set;
- a **size**, from 1 to 64 bytes;
- an **operation ID**, so a retry never makes a second secret by accident.


1. **Your agent asks for a secret.** It sends the label, the size and the operation ID. Nothing secret yet.
2. **Vault makes it on your computer.** It draws fresh randomness from your operating system and, if you choose, adds a contribution of hardware randomness from MCPBytes.
3. **The secret is saved where you chose.** The macOS Keychain, Windows Credential Manager, the Linux Secret Service, or a private file only you can read.
4. **Your agent gets a reference.** A name to hand to the app that needs the secret. Never the secret itself.


This is everything your agent receives back:

```json
{
  "reference": "vault:mcpbytes-vault/agent-webhook-signing#1",
  "label": "agent-webhook-signing",
  "version": 1,
  "bytes": 32,
  "backend": "macos_keychain",
  "entropy_mode": "mixed",
  "format": "raw"
}
```

The agent passes that reference along to your app's configuration, a deploy script or another tool. With the private-file option, the reference is simply the path of the file. A second tool, `list_secrets`, shows your agent which labels and versions exist, so it can reuse one instead of making a duplicate. It never shows values.

## Where the randomness comes from

A secret is only as strong as it is unpredictable. Every modern operating system has a good random generator, and Vault always uses yours.

The MCPBytes release of Vault can also add randomness generated by hardware at MCPBytes, from a physical process rather than a program. That's a real difference. A software generator is a formula: start it from the same seed and it gives the same numbers every time. A physical source has no seed to find or repeat.

When you turn that on, Vault combines the two, so a secret never rests on a single source. And because part of it is drawn on your computer and never leaves, MCPBytes never has what it would take to rebuild your secret.

For how we test randomness in the open, see our [NIST test report for Random Numbers](https://mcpbytes.com/verification/random-numbers).

## Sealed for your computer

The hardware contribution never travels as something anyone can read. For each request, Vault creates a new one-time key. MCPBytes returns the contribution encrypted to that key, and Vault checks that it's authentic against a public key you keep in your own configuration. Anything that doesn't check out is refused, never quietly replaced.

The encrypted response itself expires five minutes after the request, and our service then removes it.

## Your rules

You set the policy in Vault's configuration file. Your agent can't change it.

| Mode | What happens |
| --- | --- |
| `remote_required` | Every secret includes a verified hardware contribution, or it isn't made. |
| `remote_preferred` | If MCPBytes is slow or unavailable, Vault may make a secret from your computer's randomness alone, clearly marked in its receipt. |
| `local_only` | Your computer's randomness only, with no network call at all. The receipt says so. The only mode of the open-source build. |

Storage works the same way: you choose the Keychain, Credential Manager, Secret Service or a private file, and if that place is unavailable, Vault stops rather than saving somewhere else.

## Safe to retry, easy to rotate

Networks fail at the worst moment. If your agent doesn't hear back, it simply asks again with the same operation ID. It gets the same receipt, with no second secret and no second charge.

A new operation ID makes a new version under the same label. Earlier versions stay until you delete them, so an app can move to the new key on its own schedule.

## You hold the keys

Revealing, deleting and enrolling secrets is yours alone, from your own terminal:

```bash
mcpbytes-vault list
mcpbytes-vault reveal agent-webhook-signing
mcpbytes-vault delete agent-webhook-signing --version 1
mcpbytes-vault totp-qr agent-2fa
```

Those commands refuse to run without an interactive terminal, so an agent that tries them through a shell tool gets an error instead of your secret. For two-factor codes, have your agent make a 20-byte secret, then run `totp-qr` and scan the code with your authenticator app.


Any program running as you can read what you can read. If your agent has unrestricted access to your shell, give it its own user account or a sandbox so your secrets stay separate.


## What it's for

Vault makes raw random bytes. That's what you want for:

- keys that sign webhooks and API requests;
- session secrets for web apps;
- symmetric encryption keys;
- tokens between your own services;
- two-factor (TOTP) seeds.

It doesn't make key pairs or passwords in a particular format. Your app's own crypto library turns bytes into those.

Each secret made with a hardware contribution is one small job, at 1 credit per job. Secrets made locally make no API call and cost nothing.

## Open source

Vault is open source, under the AGPL-3.0, at [github.com/MCPBytes/mcpbytes-vault](https://github.com/MCPBytes/mcpbytes-vault). You can read exactly how it makes, stores and hands off a secret, build it yourself, and open issues or pull requests. It hasn't had an independent security audit yet; the code is there for anyone to review.

The open-source build is local-only: it uses your operating system's generator and contains no network code at all. The hardware contribution from MCPBytes is an optional, paid addition, in the release you install from mcpbytes.com.

## Set it up

Vault runs on macOS with Apple silicon, and on Windows and Linux on x64. Each installer checks its download, creates a private configuration and prints the commands that connect Vault to your agent.

For the open-source, local-only build, from GitHub:

```bash
curl -fsSL https://github.com/MCPBytes/mcpbytes-vault/releases/latest/download/install.sh | sh
```

```powershell
irm https://github.com/MCPBytes/mcpbytes-vault/releases/latest/download/install.ps1 | iex
```

For the MCPBytes release, with the optional hardware contribution:

```bash
curl --proto '=https' --tlsv1.2 -fsSL https://mcpbytes.com/install/vault.sh | bash
```

```powershell
irm https://mcpbytes.com/install/vault.ps1 | iex
```

Then [connect it to your agent](https://mcpbytes.com/docs/random-bytes#connect). For the hardware contribution, give Vault your MCPBytes API key through your agent's private settings, never in the chat. The [setup guide](https://mcpbytes.com/docs/random-bytes) has everything else.

## Try it

- [Create a secret](https://mcpbytes.com/tools/random-bytes): Let your agent create secret keys and tokens it never sees. They are saved on your computer; your agent only gets a name to pass along.