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:

1. Create secrets.enc.yaml via this server — age-encrypted against your public key, safe to commit.

2. Commit it alongside your code.

3. 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.

Related MCP server: Janee

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:

1. 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.

2. 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.

3. 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.

Transforms (for derived secrets)

Tools

Creation and listing

Mutation (require a private key for the target domain)

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

* 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...          # CI runner
      - age1operator...    # operator laptop
    keys:
      - AGE-SECRET-KEY-1CI...
  client-acme:
    recipients:
      - age1acme...
    key_file: /run/secrets/acme.agekey   # an age keys file
  archive:
    recipients:
      - age1archive...
    # no keys: this domain can encrypt but never decrypt

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:

1. Edit the domain's recipient list and restart the server.

2. 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.

• Another encryption mode: encrypted_regex, unencrypted_regex, encrypted_suffix, the comment regexes, or an unencrypted_suffix other than _unencrypted. This server re-encrypts with --unencrypted-suffix _unencrypted, so it would change which values are left in the clear. That includes the manifests sops_create_k8s_secret writes, which are refused with a message of their own.

Each is a silent downgrade or reshape, 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_]*$.

Encrypted file format

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 a Kubernetes Secret, create it in that shape with sops_create_k8s_secret (below). For any other document shape, build it from the flat file at deploy time (Kustomize's secretGenerator, helm-secrets, sops-secrets-operator) rather than reshaping the encrypted file.

Kubernetes Secret manifests

sops_create_k8s_secret writes a whole Secret manifest, with each value already at its path under stringData, so nothing has to be moved afterwards:

apiVersion: v1
kind: Secret
metadata:
    name: web-app
    namespace: prod
    labels:
        app.kubernetes.io/name: web
    annotations:
        sops-mcp.privacyplaybook.com/meta: '{"version":1,"domain":"default","secrets":{"DB_PASSWORD":{"source":"generated","generation":{"length":32,"charset":"alphanumeric"},"last_rotated":"..."}}}'
type: Opaque
stringData:
    DB_PASSWORD: ENC[AES256_GCM,data:...,tag:...,type:str]
sops:
    ...
    encrypted_regex: ^(data|stringData)$

• Only stringData is encrypted (--encrypted-regex '^(data|stringData)$'). apiVersion, kind, metadata and type stay readable, and sops decrypt, ksops or Flux turn the file into a manifest kubectl apply accepts as it is.

• Everything in the clear is an argument: name, namespace, labels, annotations and type. The MAC covers plaintext too, so none of it can be edited afterwards. Label and annotation keys data and stringData are refused, because sops would encrypt them too.

• Key names follow Kubernetes' rule ([-._a-zA-Z0-9]+), not the environment-variable one, so typed Secrets can use keys such as tls.crt or .dockerconfigjson. Values go in stringData as strings; the tool never writes base64 data:.

• Metadata lives in the sops-mcp.privacyplaybook.com/meta annotation, as JSON with the same fields as _meta_unencrypted: the domain, and per secret its source, description, generation and derivation. It never holds a value. It cannot sit at the root, because kubectl's strict validation rejects an unknown root field. It does reach the cluster object, so don't put anything in a description you would not put in an annotation.

• The file is create-only. Every mutation tool (sops_rotate_generated, sops_add_secrets, sops_update_external, sops_rename_secret, sops_delete_secrets, sops_add_metadata, sops_rekey) recognises it from its sops envelope, without decrypting, and refuses it. To change or rotate anything, call sops_create_k8s_secret again with the full set, supplying external values again. sops_list_secrets reads it: the key names under stringData, their sources from the annotation, and the domain.

• Minimum version. The refusal exists only in the release that adds this tool and later ones. sops-mcp 0.11.0 and earlier have no such guard: sops_add_secrets, sops_rekey or any other mutation there would rewrite the manifest as a flat file, encrypting kind: and metadata: and adding root-level keys. The values still decrypt, so nothing is lost, but the manifest is no longer applyable. Don't point an older server at these files.

Why these tools and not others

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  # one-time; cosign on PATH is needed for the signature checks
python3 lib/pin_base_images.py

Base image updates from Dependabot. .github/dependabot.yml checks the two cgr.dev/chainguard/python digests every Monday. When one has moved, Dependabot opens a single PR that changes the FROM lines in the Dockerfile and nothing else. It does not touch base-images.lock.json, so the PR's verify check fails: lib/verify_base_images.py requires every FROM digest to be the one the lock records for that image, and every image in either file to be in the other. (The advisory cosign check in that script verifies the lock's digests, so a stale lock would have it vouch for images no longer in use.) The PR stays red until the lock is regenerated on its branch:

gh pr checkout <number>
pip install requests  # one-time; cosign on PATH for the signature checks
python3 lib/pin_base_images.py

Commit only if the script exited 0 and its summary reads 2/2 pinned, 2/2 cosign verified. If a tag failed to resolve it exits 1 and writes "digest": null; without cosign on PATH it writes "cosign_signed": false. Either way, fix that and re-run. Then:

git add Dockerfile base-images.lock.json
git commit -S -m "build(deps): regenerate base-images.lock.json"
git push

main requires signed commits, hence -S (or commit.gpgsign set). The script re-resolves both tags, so it may pin a digest newer than the one Dependabot proposed; that's expected, and it is the digest the lock then records and cosign verified. Once you push to its branch, Dependabot stops rebasing that PR, so merge it or close it before the next Monday run.

A latest move can also be a Python minor upgrade (3.13 to 3.15, say), and CI's test jobs don't run on the image's Python. Before merging, check the Python version in the new image (docker run --rm cgr.dev/chainguard/python:latest --version). If it changed, recompile requirements.lock.txt for it (lib/compile_requirements.sh) and make sure the image builds.

Dependabot tracks digest moves only. It does not report vulnerabilities in the image's OS packages. Two scans look for vulnerabilities, and only the second sees the OS packages and the binaries: vuln-scan audits requirements.lock.txt with pip-audit, and image-scan runs Grype over the built image (Wolfi apk packages, the venv's Python packages, and the Go binaries sops, age and age-keygen, by their embedded build info). The image scan runs in the Image build workflow on pull requests, and in publish.yml, which builds the image once to an OCI archive, scans it in a job holding no credentials, and only then pushes that same archive (same digest) to GHCR and signs it. Nothing reaches GHCR unless the scan passes. It fails on a vulnerability that has a fix available at severity high or above; one with no fix yet doesn't fail. When it fails on a base package, the fix is usually a base digest bump (python3 lib/pin_base_images.py); on sops or age, a rebuild picks up Wolfi's newest (see below). To accept a finding instead, add an ignore: rule naming the vulnerability: with a reason: to .grype.yaml.

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 not pinned by the base image digest: apk installs the newest version in the repository when the image is built, so every rebuild can pick up a newer sops or age. The Wolfi CA bundle is upgraded the same way.

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  # one-time
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.

# List all artifacts attached to the image
cosign tree ghcr.io/privacyplaybook/sops-mcp:<tag>

# Download the SBOM (SPDX JSON)
cosign download sbom ghcr.io/privacyplaybook/sops-mcp:<tag>

# Verify the SLSA build provenance
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  # unit tests plus end-to-end sops round-trips
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).

1. 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.

2. Ask the model to produce a secrets.enc.yaml with sops_create_secrets.

3. Commit the encrypted file.

4. In your deploy workflow, run sops decrypt secrets.enc.yaml > .env (or equivalent) and pass the result to your orchestrator.

5. 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.