sealkeep

[sealkeep: your agent uses the key, it never sees it]

[npm] [MCP registry] [CI] [Smithery] [MIT]

[Install in Cursor] [Install in VS Code]

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/sealkeepsealkeep 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 (<file>.bak-<unix time>). sealkeep uninstall removes what install added.

Run sealkeep doctor to check the stores and the clients.

Names

A name is <scope>/<project>/<env>/<KEY>:

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_URLpersonal/example-app/dev/DATABASE_URLpersonal/example-app/dev/STRIPE_SECRET_KEY   -> shared/stripe/test/SECRET_KEY   (alias)acme/ovh/ovh-eu/APPLICATION_KEYacme/cloudflare/API_TOKENshared/stripe/test/SECRET_KEYshared/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_KEYsealkeep import ~/.ovh.conf --to acme/ovh            # INI: one folder for each sectionsealkeep 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 devsealkeep 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 <path> 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 = truedeny = ["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.

A locked keyring does not stop a command. When one store does not answer, run and list use the values of the other stores, and they print one warning for that store. A name that only the locked store has fails on its own name, with the error of that store. A store that you name with -s must answer.

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 vault keeps in the keyring.

Other secret managers

Each of these is a store kind. It runs the official CLI of the vendor, so the vendor's own sign-in (SSO, a service account, biometrics) applies, and sealkeep keeps no vendor token. A value goes to the CLI through stdin or through a file that only you can read, never as a command argument, which ps would show.

Google and Azure allow only some characters in a secret ID, so the ID is the name with / as -- and a short hash, and the real name is in an annotation or a tag. Azure keeps a removed secret in its soft-delete state, and a later set of the same name recovers it. For Bitwarden, unlock first: export BW_SESSION=$(bw unlock --raw). The Bitwarden Secrets Manager CLI (bws) takes a value only as a command argument, so sealkeep uses the password manager CLI (bw).

SSH keys

An SSH agent holds a key with a passphrase only in memory. After a reboot it is empty, and an agent's git push fails with Permission denied (publickey). sealkeep keeps the passphrase and loads the key:

sealkeep set personal/ssh/ID_ED25519_PASSPHRASEsealkeep ssh-add ~/.ssh/id_ed25519 --passphrase personal/ssh/ID_ED25519_PASSPHRASEsealkeep ssh-load      # unlock runs it too

ssh-load runs ssh-add with sealkeep as the SSH_ASKPASS program. The askpass step answers only when its parent process is ssh-add and a one-use token matches, and it reads the passphrase from the store, so the passphrase never goes to a file or the output. --agent picks the agent socket; the default is $SSH_AUTH_SOCK.

MCP

sealkeep mcp serves these tools on stdio:

The guard hook

The hook refuses these tool calls, and it tells the agent to use sealkeep run:

1. sealkeep get, also inside $(…), backticks and bash -c.
2. A read of the sealkeep keyring entries: secret-tool lookup service sealkeep …, security find-generic-password -s sealkeep … -w, keyring get sealkeep ….
3. A read of a .env file by a shell command or by the Read and Grep tools, when block_dotenv is on. .env.example, .env.sample, .env.template and .env.dist stay readable.
4. A Kubernetes Secret: kubectl get secret(s), kubectl get sec, kubectl get pods,secrets, kubectl edit secret, kubectl view-secret, kubectl get --raw …/secrets/…, kubectl config view --raw and kubectl create token. Flags before the verb do not help. kubectl get pods, kubectl describe secret and kubectl exec … -- ls stay allowed. The kubectl create token rule does not affect sealkeep's own Vault login: that command runs inside sealkeep, not through the hook.
5. An environment dump: bare env, printenv, set, export -p, declare -p, ps e/ps auxe, and /proc/*/environ or /proc/*/cmdline. env FOO=bar <command> and set -e stay allowed.
6. A keyring read that is not sealkeep: secret-tool lookup|search for any service, security find-generic-password|find-internet-password -w, security dump-keychain, security export, keyring get, and a gdbus, busctl or dbus-send call to org.freedesktop.secrets.
7. A printed token: gcloud auth print-access-token|print-identity-token, aws configure get aws_secret_access_key|aws_session_token, aws sts get-session-token|assume-role, aws sso get-role-credentials, az account get-access-token, gh auth token, git credential fill and a package-manager token read.
8. A tool that resolves a secret and prints it: terraform state pull|show, terraform output -json|-raw, terraform show -json, helm get values|manifest|all, helm secrets view|dec, docker compose config, docker inspect, docker history, pulumi stack output --show-secrets and ansible-inventory (--list, --host, --yaml or no argument).
9. A read of another secret store: vault kv get, vault kv export, vault read (and bao), ansible-vault view and ansible-vault decrypt, sops -d, sops exec-env, aws secretsmanager get-secret-value, gcloud secrets versions access, az keyvault secret show, op read, op item get --reveal, bw get password, bws secret get, pass show, rbw get and the other password managers. The write commands and the metadata-only list commands stay allowed.
10. A credential file: any kubeconfig in ~/.kube (also one with a name of its own), the files in ~/.aws (both credentials and config can hold keys), the Google Cloud and Azure token and config files, ~/.docker/config.json, ~/.netrc, ~/.npmrc, ~/.yarnrc.yml, ~/.condarc, ~/.git-credentials, ~/.vault-token, ~/.envrc, ~/.pgpass, ~/.my.cnf, ~/.config/sops/age/keys.txt, ~/.password-store, ~/.gnupg, *.kdbx, the Terraform, Helm, Pulumi, rclone, Argo CD, glab, Maven, Gradle, NuGet and gem credential files, the browser password and cookie stores, the shell history files, an SSH private key, a Terraform state file (.tfstate), and the cluster admin files under /etc/kubernetes, /etc/rancher/k3s and /var/lib/kubelet. Public files such as id_ed25519.pub, ~/.ssh/config, ~/.bashrc and ~/.config/git/config stay readable.
11. The command after -- in sealkeep run, so sealkeep run KEY -- kubectl get secret x is refused too.
12. Each command prefix in guard.deny.

The remedy is the one the guard prints: the person stores the value in sealkeep one time (sealkeep set personal/cloudflare/CF_API_TOKEN), then the agent uses sealkeep run personal/cloudflare/CF_API_TOKEN -- …. The value never goes into the context, and kubectl or vault is not needed for it.

If the only copy is in Kubernetes or Vault, the person moves it across at a terminal, where the guard does not apply:

kubectl -n cert-manager get secret cloudflare-api-token -o jsonpath='{.data.api-token}' \  | base64 -d | sealkeep set personal/cloudflare/CF_API_TOKEN --stdinvault kv get -field=CF_API_TOKEN agent/personal/cloudflare \  | sealkeep set personal/cloudflare/CF_API_TOKEN --stdin

Rotate the source token afterwards if an agent has already seen it. The agent only ever gets the sealkeep name.

sealkeep guard --check runs the built-in rules against a set of commands and exits non-zero when one is not refused. sealkeep doctor runs the same check with the store and client status.

Three more layers work for Claude Code:

1. The output guard (sealkeep guard --after, a PostToolUse hook for Bash, Read and Grep). After the tool call, it compares the result with the values of the stored secrets, in the same forms as run redaction. When a value is in the result, the hook replaces it with [sealkeep:NAME] before the agent reads the result, and it names the secret in a note. This also covers env > out.txt followed by a read of out.txt, and a glob or a variable in the path. The resident agent (sealkeep agent) reads the stores one time and answers the hook in milliseconds; the hook starts it on the first tool result. Until the agent answers, the hook uses the in-process path, which loads the stores in parallel with a limit of 4 seconds. See docs/agent.md. Claude Code records the original output in its own telemetry.
2. Deny rules (permissions.deny in settings.json). sealkeep install adds Read(**) rules for the .env and credential files and Bash(…) rules for kubectl get secret, vault kv get and the other commands above. Claude Code checks the path rules on the path, so the Read tool and the file commands that it recognizes cannot reach the file by a shell trick. The install adds the .env rules when block_dotenv is on, and sealkeep uninstall removes all of them.
3. The MCP server runs run_with_secrets through the same check, so a command without a shell cannot go around the hook.

What sealkeep protects, and what it does not

sealkeep keeps secrets out of the context of the agent, out of the transcript and out of the files of the project. Each use goes into the audit log (~/.local/share/sealkeep/audit.jsonl on Linux, or $SEALKEEP_AUDIT_LOG), with the names and the command and never a value.

Redaction matches the value, its JSON-escaped form, its percent-encoded form and its base64 forms. A value is redacted when its key looks like a secret (KEY, TOKEN, SECRET, PASS, AUTH and similar words), when it is a URL with a password, or when it has 16 characters or more. A config value such as PORT=3000 stays readable. A value that is shorter than 4 characters is not redacted. A command that transforms a value in another way (for example, a hash or a part of the value) can print it in a form that sealkeep does not match.

An agent that can run any shell command as your user can read what your user can read. sealkeep does not change that. It makes the safe path the easy one, it refuses the common paths to a value, and it records each use. Give an agent keys with a small scope: a restricted Stripe key, an OpenRouter key with a spend limit, a test account for a web login.

The guard blocks the standard commands, but it is a guard rail, not a sandbox: an agent that writes its own HTTP client against the Kubernetes API, renames the kubectl binary or runs an alias can still reach a value that your account can reach. For a hard boundary, remove the permission as well: give the kubeconfig an RBAC role without get on Secrets, and give the agent's Vault token a policy without read on the paths that only sealkeep should use. Then the guard is the second line, not the only one.

Build and test

cargo build --releasecargo test --features test-store

The test-store feature replaces the OS keyring with a file, for the tests only. The release binaries are built without it.

Licence

MIT