sealkeep

sealkeep

sealkeep lets an AI agent use your secrets without seeing them.

You keep each secret one time, under a name such as shared/stripe/test/SECRET_KEY. The agent finds the name with sealkeep list, and runs a command with it. It never reads the value, and it never has to ask you for one.

The agent asks for a secret by its name. sealkeep puts the value into the environment of one command, runs the command, and replaces the value with [sealkeep:NAME] in all the output. The value does not go into the context, the transcript or a file.

agent ──► sealkeep run OPENROUTER_API_KEY -- sh -c 'curl -H "Authorization: Bearer $OPENROUTER_API_KEY" …'

│ ├─ reads the value from a store ──► OS keyring (macOS Keychain, Secret Service, Windows Credential Manager) │ └─► Vault KV v2 (a replica) ├─ starts the command with the value in its environment └─ redacts the value from stdout and stderr ──► agent sees [sealkeep:OPENROUTER_API_KEY]

It has four parts:

1. A CLI (sealkeep): set, list, run, import, scan, sync, aliases and the store commands.
2. An MCP server (sealkeep mcp): the tools list_secrets, run_with_secrets and store_status. No tool returns a value.
3. A guard hook (sealkeep guard): it refuses the tool calls that would print a secret, for example cat .env, sealkeep get, kubectl get secret or vault kv get.
4. A skill that tells the agent when and how to use the CLI.

Install

As an MCP server only (any client), the command is npx -y @munhq/sealkeep:

{ "mcpServers": { "sealkeep": { "command": "npx", "args": ["-y", "@munhq/sealkeep"] } } }

In Claude Code, the plugin adds the MCP server, the skill and the guard hook in one step:

/plugin marketplace add munhq/sealkeep

/plugin install sealkeep@sealkeep

The full install below does the same for Claude Code, Codex and Cursor.

Linux and macOS:

curl -fsSL https://raw.githubusercontent.com/munhq/sealkeep/main/install.sh | sh

The script downloads the binary of the newest release, checks it against SHA256SUMS, copies it to ~/.local/bin, and runs sealkeep install.

With Rust:

cargo install --locked --git https://github.com/munhq/sealkeep

sealkeep install

sealkeep install finds the AI clients on the machine. It adds the skill, the MCP server and the guard hook to each client:

Options: --client claude,codex installs into the named clients only. --dry-run shows the plan. --no-skills, --no-mcp and --no-hooks leave out a part. Before sealkeep changes a JSON file, it writes a backup ( .bak- ). sealkeep uninstall removes what install added.

Run sealkeep doctor to check the stores and the clients.

Names

A name is / / / :

Folders are lower case (a-z, 0-9, ., _, -). The key is upper case (A-Z, 0-9, _) and is the variable that run sets.

personal/example-app/prod/DATABASE_URL

personal/example-app/dev/DATABASE_URL personal/example-app/dev/STRIPE_SECRET_KEY -> shared/stripe/test/SECRET_KEY (alias) acme/ovh/ovh-eu/APPLICATION_KEY acme/cloudflare/API_TOKEN shared/stripe/test/SECRET_KEY shared/openrouter/API_KEY

One value, one name. When two projects use the same account, store the value one time under shared/…, and make an alias in each project folder. The project folder then has every variable that the project needs, and a rotation changes one value.

Store a secret

sealkeep set shared/openrouter/API_KEY -d "OpenRouter, the main account"   # writes to every store

sealkeep asks for the value two times, with no echo. To pipe a value in, use --stdin:

some-password-tool show openrouter | sealkeep set shared/openrouter/API_KEY --stdin

To find the secrets on a machine, run scan. It prints the path of each .env file, its key names, a class for each key (secret, config or empty), and a group number for each value that is in more than one place. It never prints a value. It also lists other files that often hold a credential, by path only:

sealkeep scan ~/code --max-depth 4

To copy a file into a folder:

sealkeep import ../example-app/.env --to personal/example-app/dev \

--map STRIPE_SECRET_KEY=shared/stripe/test/SECRET_KEY sealkeep import ~/.ovh.conf --to acme/ovh # INI: one folder for each section sealkeep set personal/github/PAT --from-file ~/.github-token

import reads dotenv files, and INI files (.ini, .conf, AWS credentials). It prints the names only. --map KEY=NAME stores the value at NAME and makes the project key an alias of it. If NAME already has a different value, import stops and says so. After the import, delete the source file, or keep it out of the reach of the agent.

Let the agent use it

Tell the agent what to do. The skill tells it to run sealkeep list for the names, and sealkeep run for the command:

sealkeep run shared/openrouter/API_KEY -- sh -c 'curl -sS -H "Authorization: Bearer $API_KEY" https://openrouter.ai/api/v1/key'

sealkeep run --all personal/example-app/dev -- npm run dev sealkeep run -e GITHUB_TOKEN=personal/github/PAT -- gh api user

A name sets the variable named by its key. --all FOLDER sets one variable for each secret in the folder, the same as a .env file. --recursive also takes the subfolders; two secrets with the same key are then an error. -e VAR=NAME sets a variable with a different name. STORE:NAME reads from one store only.

For a tool that reads its secrets from a file, --dotenv writes a temporary file that only you can read. The file is in $XDG_RUNTIME_DIR/sealkeep when it exists. sealkeep puts the path where the command has {dotenv}, and it removes the file when the command ends. This example gives Playwright MCP the login of a test account. The agent types the name ADMIN_PASSWORD, and Playwright puts in the value:

sealkeep run --dotenv personal/example-app/dev/ADMIN_EMAIL --dotenv personal/example-app/dev/ADMIN_PASSWORD \

-- npx @playwright/mcp@latest --secrets {dotenv}

--secrets is an option of @playwright/mcp (see its README).

See a value yourself

sealkeep get shared/openrouter/API_KEY

get works only when stdin and stdout are a terminal. An agent runs commands without a terminal, so get refuses, and the guard hook also refuses it.

Stores

sealkeep looks up a bare name in the stores in the order of the config file. The first store that has the name gives the value.

The config file is ~/.config/sealkeep/config.toml on Linux and ~/Library/Application Support/sealkeep/config.toml on macOS. $SEALKEEP_CONFIG sets another path. With no file, sealkeep has one keyring store named local.

[[store]]

name = "local" kind = "keyring"

[[store]] name = "vault" kind = "vault" address = "http://127.0.0.1:{port}" mount = "agent" auth = "kubernetes" role = "sealkeep" jwt_command = ["kubectl", "-n", "vault", "create", "token", "sealkeep", "--duration", "10m"] port_forward = ["kubectl", "-n", "vault", "port-forward", "svc/vault", "{port}:8200"]

[aliases] "personal/example-app/dev/STRIPE_SECRET_KEY" = "shared/stripe/test/SECRET_KEY"

[guard] block_dotenv = true deny = ["example-secret-cli"]

The OS keyring

Each secret is one entry with the service sealkeep and the secret name as the account. An index entry (__index__) keeps the names and the descriptions.

On Linux, the keyring must be unlocked. A desktop session unlocks it when you log in. A session with no desktop (SSH, a login with no keyring password) has a locked keyring, and no unlock prompt can show. Run this one time after each boot:

sealkeep unlock

It asks for the password of the login keyring and gives it to gnome-keyring-daemon --unlock. Each keyring call waits at most 30 seconds (SEALKEEP_KEYRING_TIMEOUT), so an agent gets an error, and the call does not hang.

Vault as a replica

A Vault (or OpenBao) KV v2 mount can hold a copy of the keyring, for a second machine or a backup. Each folder is one KV secret, and each key is one field of it: shared/stripe/test/SECRET_KEY is the field SECRET_KEY of agent/shared/stripe/test. The custom_metadata of each secret lists its keys and their descriptions, so list reads no value.

For a Vault inside Kubernetes, sealkeep can reach it through the Kubernetes API with a port forward, and log in with a short-lived ServiceAccount token. The machine then keeps no Vault token:

sealkeep store add-vault vault \

--address 'http://127.0.0.1:{port}' --mount agent --auth kubernetes --role sealkeep \ --jwt-command 'kubectl -n vault create token sealkeep --duration 10m' \ --port-forward 'kubectl -n vault port-forward svc/vault {port}:8200' sealkeep sync --from local --to vault # one time, for the secrets that are already in the keyring

set, import and mv write to every store (a Vault store takes only names with a folder), so the stores stay the same. --store NAME writes to one store. The Vault side needs a KV v2 mount, a policy with create, read and update on agent/data/* and read, list and update on agent/metadata/*, and a Kubernetes auth role bound to the ServiceAccount. With --auth token, sealkeep reads $VAULT_TOKEN, or the token that `sealkeep store token va