sops-mcp
MCP server for creating and managing SOPS-encrypted secret files using age encryption.
Designed for Claude Code (or any MCP client) to produce encrypted secrets.enc.yaml files without the model ever seeing plaintext values. All file content is passed as text parameters and returned as text โ the server has no filesystem access to the client.
Why
Two goals drive the design:
1. Keep secrets in your source tree without leaking them. For a small project, running a full secrets manager (Vault, AWS Secrets Manager, etc.) is overkill for a handful of credentials. Encrypting secrets at rest in git and decrypting them in your CI/CD pipeline at deploy time is much cheaper:
- Create
secrets.enc.yaml via this server โ age-encrypted against your public key, safe to commit.
- Commit it alongside your code.
- Your CI/CD pipeline holds the age private key, decrypts at deploy time, and injects plaintext as environment variables into your container orchestrator.
The age private key lives in exactly one place: your CI/CD secrets store. Everywhere else โ your laptop, your git remote, your container images โ sees only ciphertext. See the worked example below.
2. Let an AI coding agent generate secrets it can never read. Claude (or any MCP client) can create passwords, rotate them, derive hashes, rename and delete them โ but plaintext values never cross the MCP boundary back to the model.
The server holds the encryption key; the client only submits requests and receives metadata.
There is deliberately no "decrypt this one secret" tool.
This prevents a prompt injection or a misbehaving agent from exfiltrating a secret.
The simplest setup uses a single age recipient (the one CI private key). If you need several โ a CI key plus an operator's key, or separate key sets for separate parties โ see Key domains.
Secret sources
Every secret is one of three sources, recorded in _meta_unencrypted:
generated โ Cryptographically random values (Python secrets / OS CSPRNG). You specify length and charset; the server stores both so it can regenerate on rotation.
external โ User-provided values encrypted as-is (SMTP credentials, third-party API keys, etc.). Preserved across rotation. Updated via sops_update_external.
derived โ Computed from another key in the same file via a named transform. When the source is rotated (or an external source is updated), the derived value is automatically recomputed in topological order. Useful for things like Authelia's PBKDF2 hashes of OIDC client secrets.
Design
Three ideas shape the tool surface:
- No plaintext crosses the MCP boundary. Generated secret values are never returned to the client. There is deliberately no "decrypt this one key" tool. If you need plaintext, run
sops decrypt yourself with the age private key.
- Metadata in plaintext. A
_meta_unencrypted block sits alongside the encrypted values (using SOPS's unencrypted_suffix feature) and records each secret's source, how it was generated, when it was last rotated, and which key domain it belongs to. This lets the server list and rotate secrets without decrypting. SOPS's MAC covers these values by default, so a tampered block fails to decrypt. Files that switch that off with mac_only_encrypted are refused. Tools that read the block without a key still cannot check the MAC, which is why recipients are verified separately.
- No in-place value update for
generated or derived secrets. Those change only via rotation, where neither the server nor the caller has access to the plaintext. External secrets (e.g. an upstream API key the user controls) can be updated with sops_update_external.
| Transform | Purpose | Deterministic |
|---|
pbkdf2_sha512_authelia | PBKDF2-SHA512 hash in Authelia's configuration.yml format ($pbkdf2-sha512$310000$...) | No โ random salt per call |
sha256_hex | Hex-encoded SHA-256 digest | Yes |
Creation and listing
| Tool | What it does |
|---|
sops_create_secrets | Create a new encrypted file with one or more secrets (any mix of sources). |
sops_list_secrets | List keys, sources, and descriptions from a file without decrypting. |
sops_create_oidc_secret | Convenience: create an Authelia OIDC client secret as a generated + derived (pbkdf2_sha512_authelia) pair in one call. The hash is returned in the response for pasting into configuration.yml. |
sops_list_domains | List the configured key domains, their age recipients, and whether each can decrypt or only encrypt. Never returns private key material. |
Mutation (require a private key for the target domain)
| Tool | What it does |
|---|
sops_rotate_generated | Regenerate all generated secrets. Derived secrets whose source was rotated are recomputed; others are preserved. External secrets are preserved. |
sops_add_secrets | Add new secrets to an existing file. Supports all three sources. Rejects collisions with existing keys. |
sops_update_external | Replace the value of an external secret. Cascades to any derived secrets that reference it. Rejects attempts to update generated or derived. |
sops_rename_secret | Rename a key, preserving its value and metadata. Updates from: references in any derived secrets. |
sops_delete_secrets | Remove one or more keys. Rejects deleting a secret that another derived secret still references (unless the dependent is deleted in the same call). |
sops_add_metadata | Retrofit _meta_unencrypted onto a legacy SOPS file that lacks it. Supports generated, external, and derived entries. |
sops_rekey | Re-encrypt a file onto its domain's current recipient list. Run this after a domain's recipients change, or to clear a "recipients do not match" refusal. Requires an explicit domain. Leaves a legacy file without a metadata block untouched in that respect, so sops_add_metadata still works on it. |
Every tool takes a domain argument except sops_list_domains, which needs none. It is optional everywhere but sops_rekey, where it is required because the call changes who can read the file. See Key domains.
Setup
Prerequisites
- Python 3.11+
- sops CLI binary
- An age keypair (see below)
Generating an age keypair
If you don't already have one, install age and run:
age-keygen -o age-key.txt
The file looks like:
# created: 2026-04-22T12:34:56Z
# public key: age1abc...xyz
AGE-SECRET-KEY-1HH...
- Public key (
age1...) โ pass to this server as SOPS_MCP_AGE_PUBLIC_KEY. Safe to share anywhere.
- Private key (
AGE-SECRET-KEY-...) โ store as a CI/CD secret (commonly named SOPS_AGE_KEY). Never commit to source control. Anyone with this key can decrypt every secrets.enc.yaml encrypted to the matching public key.
Back up the private key somewhere safe (password manager, hardware token). Losing it means losing access to every secret you've encrypted.
Installation
git clone <repo-url>
cd sops-mcp
python3 -m venv .venv
.venv/bin/pip install -e .
Claude Code configuration
Add to your project's .mcp.json:
{
"mcpServers": {
"sops-mcp": {
"command": "/path/to/sops-mcp/.venv/bin/python",
"args": ["-m", "sops_mcp"],
"env": {
"SOPS_MCP_SOPS_BINARY": "/path/to/sops",
"SOPS_MCP_AGE_PUBLIC_KEY": "<your-age-public-key>"
}
}
}
}
Environment variables
| Variable | Required | Purpose |
|---|
SOPS_MCP_AGE_PUBLIC_KEY | Yes* | Age public key for encryption |
SOPS_AGE_RECIPIENTS | Yes* | Alternative to SOPS_MCP_AGE_PUBLIC_KEY |
SOPS_MCP_SOPS_BINARY | No | Path to sops binary (default: sops) |
SOPS_MCP_LOG_LEVEL | No | Log level (default: WARNING) |
SOPS_AGE_KEY | Sometimes | Age private key for the default domain โ required to mutate a file belonging to it. Named domains take their keys from the domains file instead. |
SOPS_MCP_DOMAINS_FILE | No | Path to a YAML file defining named key domains. Use when one server needs more than one recipient set. |
SOPS_MCP_DOMAINS | No | The same domains document inline, as YAML or compact JSON. Public recipient sets only โ a domain here may not carry keys or key_file. Merged with SOPS_MCP_DOMAINS_FILE. |
SOPS_MCP_REQUIRE_DOMAIN | No | Set to 1 to require every tool call to name its domain. The file's recorded domain and the default fallback are both disabled. |
SOPS_MCP_TRANSPORT | No | stdio (default) or sse |
SOPS_MCP_HOST / SOPS_MCP_PORT | No | Bind host/port for SSE transport (default: 127.0.0.1:55090). Binding to 0.0.0.0 requires SOPS_MCP_API_TOKEN โ the server refuses to start otherwise. |
SOPS_MCP_ALLOWED_HOSTS | No | Comma-separated allowlist for the SSE Host header (DNS rebinding protection). Default: 127.0.0.1,127.0.0.1:*,localhost,localhost:*. Set explicitly when binding to a non-loopback address โ e.g. mcp.example.com,mcp.example.com:*. |
SOPS_MCP_API_TOKEN | Sometimes | Required when SSE transport binds to 0.0.0.0; otherwise optional. When set, SSE requires Authorization: Bearer <token>. |
* One of SOPS_MCP_AGE_PUBLIC_KEY or SOPS_AGE_RECIPIENTS must be set, unless SOPS_MCP_DOMAINS_FILE or SOPS_MCP_DOMAINS supplies at least one domain. The server refuses to start with no domains at all.
Both recipient variables accept a comma-separated list, and SOPS_AGE_KEY accepts several newline-separated keys. Together they form the default domain.
Key domains
A domain is a named set of age recipients plus, optionally, the private keys the server holds for them. It is the unit the server encrypts to and decrypts with.
You do not need to configure one. The environment variables above become a domain called default, and a single-recipient setup never has to mention domains again.
Why they exist
Every mutation tool decrypts, changes, and re-encrypts. Re-encryption uses the server's configured recipients โ so if a file was encrypted to a CI key and an operator key, but the server only knows about CI, the operator used to be dropped from the file silently. Domains fix that by making the recipient set a named, checked thing:
- A mutation compares the file's actual recipients against the domain's. If they differ it refuses, rather than quietly changing who can read the file.
- One server process can hold several independent key sets.
sops_rekey performs a deliberate recipient change, which is the sops updatekeys workflow.
Several recipients, one domain
The common case needs no domains file. List every recipient in the usual variable:
SOPS_MCP_AGE_PUBLIC_KEY="age1ci...,age1operator..."
SOPS_AGE_KEY="AGE-SECRET-KEY-1CI..."
Files are now encrypted to both, and mutations keep both. The server only needs whichever private key it will actually decrypt with.
Several domains
Point SOPS_MCP_DOMAINS_FILE at a YAML file:
version: 1
domains:
homelab:
recipients:
- age1ci...
- age1operator...
keys:
- AGE-SECRET-KEY-1CI...
client-acme:
recipients:
- age1acme...
key_file: /run/secrets/acme.agekey
archive:
recipients:
- age1archive...
What version: means
version: is the schema version of this configuration document โ which
fields a domain may carry and how they are laid out. It is not a version of
the keys, the recipients, or anything you rotate. Rotating a domain's
recipients does not change it. It stays 1 until a release changes the
document format itself.
It is optional; omit it and 1 is assumed. If present it must match exactly,
so a version: 2 document is refused by a server that only understands 1
rather than being half-read. That is the point of the field: a domain with an
unrecognised field is rejected, so without a version check an older server
would blame one field name when the real problem is that the whole document
is newer than it is.
Note that the version inside a secrets file's _meta_unencrypted block is
a different number, versioning the metadata schema in that file. The two
are unrelated and both happen to be 1.
The domains file must not be writable by group or other, and must be owned by the user the server runs as or by root. That check applies whether or not it holds key material, because the file decides which recipients everything is encrypted to.
A file holding private keys โ the domains file with inline keys:, or any key_file โ must additionally not be world-readable. Group-readable is allowed with a warning, so a container secret mounted root-owned and readable by the runtime group works. In the published image the server runs as uid 65532, so a Docker or compose secret needs a uid:/gid:/mode: that lets that user read it; mode: 0640 with a matching group is the usual answer.
Startup checks that every private key parses, and warns about any whose public half is not in its domain's recipient list. That is a warning rather than an error because it is the normal state mid recipient-rotation: the old key still opens files encrypted before the change, and sops_rekey is how those get migrated.
Defining domains without a file
A domains file is the only place private keys may live, because it is the
only one that can be permission-checked. That is a poor fit for a domain
that has no private key at all โ a recipient set you encrypt to, where
someone else holds the key. Deployments where writing a file is awkward
(a distroless image with no shell, an orchestrator with no inline-file
primitive) then have to mount a volume to deliver two lines of public
key material.
SOPS_MCP_DOMAINS takes the same document inline:
SOPS_MCP_DOMAINS='{"version":1,"domains":{"archive":{"recipients":["age1archive..."]}}}'
YAML works too; JSON is simply the form that survives environments where
a multi-line value is inconvenient, and it parses because YAML is a
superset of JSON.
version here is the document schema version, not a key version โ the same field as in the file form.
A domain defined here may not set keys or key_file and the server
refuses to start if one does. An environment variable is visible to
docker inspect and /proc/<pid>/environ, and carries none of the
ownership and mode checks a file gets, so it is the wrong place for a
private key.
The two sources are merged, so a deployment can keep its
key-holding domains in a file and its public ones inline. A domain name
defined by more than one source is fatal rather than silently resolved โ
the same rule that already applies when a file defines default
alongside the v1 environment variables.
Which domain does a tool use?
In order: the domain argument, then the domain recorded in the file's _meta_unencrypted block, then default. Set SOPS_MCP_REQUIRE_DOMAIN=1 to remove the last step and force every call to be explicit.
The recorded name is a hint. The check is the recipient list in the file's own SOPS envelope, which is why a mislabelled file is refused rather than re-keyed.
Recipient rotation
Adding or removing a recipient is a two-step operation:
- Edit the domain's recipient list and restart the server.
- Run
sops_rekey on each affected file, naming the domain.
Until a file is rekeyed, mutations on it are refused with a message pointing here. sops_list_secrets reports the mismatch too, and needs no private key to do it.
sops_rekey will not move a file between domains. A file that records a domain can only be rekeyed onto that same domain's current recipient list; naming a different one is refused. This matters when two domains share a private key, where decryption would otherwise succeed and quietly drop the recipients the other domain does not have. Moving secrets between domains is deliberately manual: decrypt with the sops CLI, then sops_create_secrets into the new domain.
Files this server will not touch
SOPS can protect a file in ways this server cannot reproduce, because it always re-encrypts to a flat age recipient list:
- Another master key alongside age (
pgp, kms, gcp_kms, azure_kv, hc_vault). Re-encrypting would drop that holder.
- Shamir key groups (
key_groups with a shamir_threshold). Re-encrypting would flatten an n-of-m threshold into a list any single holder could open.
mac_only_encrypted. It leaves the plaintext metadata block unauthenticated, so a file's recorded domain and each secret's source could be rewritten by anyone who can edit the file.
Both are silent downgrades, so every mutation refuses these files and sops_list_secrets flags them. Manage them with the sops CLI.
Running mixed versions
A file this version writes stays readable and writable by sops-mcp 0.10.1 and earlier. The older version does not know about the domain field, so it drops it the next time it mutates the file, leaving a file with no recorded domain. That resolves to default here, and the recipient check still protects it either way. Re-record the domain by passing domain explicitly on any later call, or with sops_rekey.
What domains are not
Domains separate key sets, not callers. On the SSE transport a single API token reaches every domain the server holds. If you need two parties that must not read each other's secrets, run a server process each.
Security
- No filesystem access โ The server never reads from or writes to the client filesystem. All content is passed as text parameters and returned as text.
- No private key for normal use โ Encryption uses only the public key. The private key is needed only for mutation tools.
- No plaintext in responses โ Generated secret values are never returned. Derived values are returned because they're meant to be pasted into config files (e.g. an Authelia PBKDF2 hash) โ don't derive values you don't intend to publish.
- Secure temp files โ Used only for sops CLI invocation. Created with 0600 permissions, overwritten with zeros before deletion, cleanup guaranteed by
finally block.
- OS-level entropy โ Secret generation uses Python's
secrets module (backed by /dev/urandom).
- stdio transport by default โ No network exposure; runs as a client child process.
- Input validation โ Key names must match
^[A-Z][A-Z0-9_]*$.
DB_PASSWORD: ENC[AES256_GCM,data:...,tag:...,type:str]
SMTP_USER: ENC[AES256_GCM,data:...,tag:...,type:str]
DB_PASSWORD_HASH: ENC[AES256_GCM,data:...,tag:...,type:str]
_meta_unencrypted:
version: 1
domain: default
secrets:
DB_PASSWORD:
source: generated
description: Database password
generation:
length: 32
charset: alphanumeric
last_rotated: "2026-04-21T15:30:00Z"
SMTP_USER:
source: external
description: SMTP username
DB_PASSWORD_HASH:
source: derived
derivation:
transform: sha256_hex
from: DB_PASSWORD
last_rotated: "2026-04-21T15:30:00Z"
sops:
age:
- recipient: age1...
enc: |
-----BEGIN AGE ENCRYPTED FILE-----
...
unencrypted_suffix: _unencrypted
Secret values are AES-256-GCM encrypted. The _meta_unencrypted block is stored in plaintext (using SOPS's unencrypted_suffix feature) so metadata is readable without decryption.
Every sops call this server makes is pinned to an empty --config, so a .sops.yaml in the directory the server was started from cannot change how files are encrypted. Recipients come from the domain, and nothing else.
The sops: block above is abridged. A real file also carries lastmodified, a mac, a version, and empty lists for the master-key types this server does not use (pgp, kms, gcp_kms, azure_kv, hc_vault). The MAC covers unencrypted values too, so an edited _meta_unencrypted block fails to decrypt. If any of those other key lists is non-empty, this server refuses to mutate the file โ it encrypts to age alone and would otherwise drop that key holder silently.
Do not reshape the output
The encrypted content this server returns must be committed exactly as it comes back. SOPS binds each value's AES-GCM tag to that value's path in the document, so moving a value to a different key โ nesting a root-level DB_PASSWORD under stringData: to build a Kubernetes Secret manifest, say โ invalidates the tag even though the ENC[...] string itself is untouched:
$ sops decrypt secrets.enc.yaml
Error decrypting tree: Error walking tree: Could not decrypt value: Could not decrypt with AES_GCM: cipher: message authentication failed
The value is unrecoverable at that point. Editing the plaintext parts by hand fails the same way, for a different reason: the MAC covers unencrypted values, so an edited _meta_unencrypted block gives MAC mismatch. Reindenting, reordering keys or reflowing the YAML is safe โ SOPS parses the document, so only key paths and values matter.
If you need secrets in some other document shape, build that shape from the flat file at deploy time (Kustomize's secretGenerator, helm-secrets, sops-secrets-operator) rather than reshaping the encrypted file.
Per-key read (decrypt-one-secret): intentionally absent. Returning plaintext over the MCP boundary would give the model access to secret material during tool calls โ an accidental exfiltration vector. If you need a plaintext value, run sops decrypt yourself with the age private key.
Per-key in-place update for generated/derived secrets: intentionally absent. sops_rotate_generated is the one path that changes those values, so rotations leave an audit trail (last_rotated timestamp) and cascade cleanly to derived secrets.
.sops.yaml creation rules: out of scope. The server has no view of your filesystem, so path-based creation rules cannot apply. Recipients come from key domains instead, and sops_rekey covers the updatekeys workflow.
Tenant isolation on the SSE transport: not yet. Domains separate key sets, not callers. A single SOPS_MCP_API_TOKEN grants every domain the server holds, so do not put two mutually distrusting parties behind one SSE server. Run one process each.
Other source types (imported, templated): out of scope. Those are orchestration concerns โ fetch values from Vault or compose URLs in your deployment templating layer, then pass the result here as an external secret.
Supply chain integrity
The Docker build is hardened with three layers of verification, enforced by a CI gate.
Base image digest pinning
The Dockerfile builds on cgr.dev/chainguard/python (Wolfi), pinned by SHA-256 digest (@sha256:...) so Docker always pulls the exact image that was audited rather than whatever the tag currently points to. Two stages are pinned separately: :latest-dev for the build stage, which has apk, a shell and a build toolchain, and :latest for the runtime stage, which is distroless โ no shell, no package manager. Both digests and their cosign signature status are tracked in base-images.lock.json.
Update the base image (when upstream publishes security patches):
pip install requests
python3 lib/pin_base_images.py
Signed binaries from Wolfi
The sops and age binaries are installed with apk from Wolfi's package repository, whose index is signed by Chainguard. They are pinned transitively through the base image digest, so re-pinning the base image also re-pins these binaries.
Python dependency hash pinning
Runtime dependencies are installed from requirements.lock.txt with pip install --require-hashes, which rejects any package whose content doesn't match the recorded SHA-256 hashes. This prevents dependency hijacking and typosquatting.
Update dependencies after editing requirements.in:
pip install pip-tools
lib/compile_requirements.sh
CI verification
The supply-chain.yml workflow runs lib/verify_requirements.py, lib/verify_base_images.py and lib/verify_version.py, then audits the lockfile for known advisories. It runs on every pull request to main, and on pushes to main that touch the Dockerfile, a lockfile, pyproject.toml, server.json or lib/. It checks that lockfiles are well-formed, that every Dockerfile FROM line is digest-pinned, that server.json matches the version in pyproject.toml, and that no pinned dependency has a published vulnerability.
The audit is the same gate the publish workflow runs, so a lockfile that would block a release now blocks the pull request instead. Because it queries live advisory data, an unrelated pull request can start failing when a new advisory lands against a pinned dependency. That is the intended trade-off; the fix is to refresh the lockfile.
Note that pip-compile keeps existing pins unless told otherwise, so regenerating after an advisory needs the upgrade flag:
lib/compile_requirements.sh --upgrade
Verifying a published release
Every container image published to GHCR is signed by this repo's publish workflow using keyless cosign via sigstore, and ships with SLSA v1.0 build provenance and an SPDX SBOM attached as OCI artifacts. Every commit on main and every release tag is SSH-signed. You can verify all of this without holding any long-lived key material โ the signatures are anchored in sigstore's public transparency log.
Install cosign: https://docs.sigstore.dev/system_config/installation
Verify the image signature. A successful verification proves the image was built by this repository's publish.yml workflow, not just that its digest matches a reference someone sent you.
cosign verify \
--certificate-identity-regexp 'https://github.com/privacyplaybook/sops-mcp/\.github/workflows/publish\.yml@.*' \
--certificate-oidc-issuer https://token.actions.githubusercontent.com \
ghcr.io/privacyplaybook/sops-mcp:<tag>
Inspect the attestations.
cosign tree ghcr.io/privacyplaybook/sops-mcp:<tag>
cosign download sbom ghcr.io/privacyplaybook/sops-mcp:<tag>
cosign verify-attestation --type slsaprovenance1 \
--certificate-identity-regexp 'https://github.com/privacyplaybook/sops-mcp/\.github/workflows/publish\.yml@.*' \
--certificate-oidc-issuer https://token.actions.githubusercontent.com \
ghcr.io/privacyplaybook/sops-mcp:<tag>
Verify git tags and commits. The simplest check is the green Verified badge on the github.com commits and tags pages.
Development
python3 -m venv .venv
.venv/bin/pip install -e ".[dev]"
pytest tests/ -v
ruff check src/ tests/
Example: integrating with a CI/CD deployment pipeline
A common pattern: use this server to produce secrets.enc.yaml files committed to your infrastructure repo, then decrypt them in CI and inject the plaintext values as environment variables to a container orchestrator (Portainer, Kubernetes, Nomad).
- Generate an age keypair once. Give the private key to your CI as a secret (e.g.
SOPS_AGE_KEY), the public key to Claude Code as SOPS_MCP_AGE_PUBLIC_KEY.
- Ask the model to produce a
secrets.enc.yaml with sops_create_secrets.
- Commit the encrypted file.
- In your deploy workflow, run
sops decrypt secrets.enc.yaml > .env (or equivalent) and pass the result to your orchestrator.
- When secrets need rotating, ask the model to run
sops_rotate_generated or sops_update_external; commit and redeploy.
The _meta_unencrypted block lets your tools filter out the metadata (keys starting with _) when pushing values to an orchestrator, so metadata never leaks into environment variables.
License
Apache-2.0. See LICENSE.