CLI commands

seekrit <command> [options]. At runtime a service token selects the org, app, and environment — so seekrit run/export need no config file. Management commands select their target with --org/--app/--group/--env flags (plus --branch for an ephemeral branch config), falling back to the optional seekrit.json written by seekrit init.

Environment variables

Precedence: environment variables override values saved by seekrit login in ~/.config/seekrit/config.json. seekrit run additionally reads these from its .env file(s) (below process.env, above saved config) — see Running & exporting.

Output conventions

Everything the CLI can do from the dashboard, it can do from the terminal, and every listing reads the same way:

• Listings print an aligned table with a header when stdout is a terminal, and plain tab-separated rows with no header when it is piped — so seekrit app list | cut -f1 keeps working.
• --json on any read command prints the API's own response instead. Use it when a table would flatten something you need (ids, nested config, timestamps).
• Data goes to stdout; everything else goes to stderr — confirmations (created app …), "nothing to list" notes, and pagination hints. A command's stdout is always safe to pipe.
• Destructive commands ask first. Anything that deletes or revokes prompts for confirmation at a terminal, and refuses outright when there is no terminal unless you pass -y/--yes (or, for sync enable, --acknowledge-decryption). Two commands deliberately skip the question: org invite rm, because rescinding an unaccepted invitation costs one re-send, and agents revoke, because revoking is the safe direction and a run about to be killed is not the moment to ask.
• list is aliased as ls, and rm as delete, wherever both read naturally.

Auth & identity

seekrit login

With no flags, signs you in through your browser: it prints a URL and a pairing code, opens the URL when you press [Enter], and waits while you authorize the device in the dashboard (re-entering your authenticator code if you have one). The session it saves authenticates as you — every org you belong to, at your role — and lasts 90 days. Nothing to copy and paste, and no org, app, or environment to choose.

Passing a credential stores that instead and skips the browser entirely — the path machines and CI use.

A browser session carries no key material, so reading a secret's value still unlocks your private key with your passphrase (SEEKRIT_PASSPHRASE, else prompted) — exactly as the dashboard does. Service tokens carry their own key and don't prompt, which is why they remain the right credential for unattended jobs.

seekrit logout

Forget the saved credentials. A browser-authorized session is also revoked server-side, so the token can't be used again; a service token is only removed locally (other machines may hold it — revoke it with seekrit token revoke). Machine (M2M) credentials are left in place.

seekrit whoami

Show the authenticated identity. For a service token, prints its bound org/app/env scope; for a browser session, names the session so you can revoke it.

seekrit doctor

[--json] — check the setup failures that would otherwise be silent.

This is deliberately not a general health sweep. The CLI already explains the loud failures where they happen: a blank SEEKRIT_TOKEN reports as "no credentials" rather than as a 401, a transport failure names the address it tried and why it failed, and seekrit whoami says when key setup is pending. What doctor covers is the class of problem that produces no symptom at all:

It reports and never repairs; each finding names the command that fixes it. A failure sets a non-zero exit code, so it works as a CI preflight. Credential values never appear in the output.

seekrit keys setup

Generate your P-256 keypair and upload your public key plus a passphrase-encrypted private key. Run once per account. Honors SEEKRIT_PASSPHRASE, otherwise prompts.

Resources

seekrit init

--org <slug> --app <slug> — write seekrit.json naming default org + app for management commands. Environment-independent and safe to commit — it never pins an environment (the token does that at runtime).

Organizations (seekrit org)

Applications (seekrit app)

Environments (seekrit env)

seekrit env diff

--from <slug> --to <slug> [--org <slug>] [--app <slug>] [--values] [--json] — what differs between two environments. Either side may name a branch instead of an environment, which is the comparison branches make necessary: a branch overlays its parent rather than copying it, so seekrit secrets list --env pr-142 shows the override set with nothing to compare it against.

By default the diff is name-level and decrypts nothing — each name lands in only in <from>, only in <to>, or declared in both, with each side's version. That works with any credential that can list secrets.

--values decrypts both sides and splits the shared names into different values and identical values. The values themselves are never printed. An identical row between two environments is worth looking at rather than skipping past: it means one credential spans both, so revoking it hits both.

Two limits, stated in the output as well as here:

• It compares what each environment declares, not what it resolves. A secret contributed by a composed group belongs to the group environment, so it is not on either side of this comparison. seekrit env show lists the groups composed into an environment.
• --values compares stored values, not expanded ones. A ${OTHER_SECRET} reference expands against the full composed set, which a declared-only diff does not gather — so the comparison is of what seekrit secrets set wrote.

seekrit branch create

<slug> [--org <slug>] [--app <slug>] --from <env> [--name <name>] [--ttl <duration>] [--no-share] — fork an application environment into an ephemeral branch (a per-PR / preview config). The branch inherits its parent's secrets by layering at read time — nothing is copied or re-encrypted — and stores only what you override on it. Generates the branch's own data key locally and, unless --no-share, wraps it to everyone who already holds a grant on the parent.

--ttl accepts 30m, 12h, 7d, 2w, … or never (default 7d, max 30 days). Expired branches are deleted automatically, along with their overrides, key grants, and any service token bound to them.

seekrit branch list

[--org <slug>] [--app <slug>] [--env <slug>] — list branches in an application, or just those of one environment. Prints slug, id, and expiry.

seekrit branch delete

<slug> [--org <slug>] [--app <slug>] [--yes] — tear down a branch and every value it overrode. The environment it overlays is untouched. Aliased as branch rm.

Shared groups (seekrit group)

A group is a reusable secret bag shared across applications, holding one environment per slug (its variants).

Composition (env groups)

Compose shared groups into an application environment. At resolve time each group is matched to the environment whose slug matches the app environment's (or a --with override).

Secrets

Every secrets command targets one environment: an application environment (--app --env, or the config's app + --env) or a group environment (--group --env). --org is inferred from seekrit.json or a lone org.

With a service token, --env is optional — the token is bound to exactly one environment, so seekrit secrets list on its own is the whole command in CI and for agents. Pass it and it is checked against the binding rather than ignored. Naming --app or --group opts back into explicit targeting, and a logged-in user always passes --env.

Every write command takes -m, --note <text>. It is ignored unless the environment requires approval, in which case the write is queued rather than performed and the note is what reviewers see:

queued for review: set STRIPE_KEY — needs 2 approvals (chg_…)

See approval workflows.

JSON and multi-line values

A value is an opaque string to seekrit — a service-account key, a PEM block, or a certificate chain is stored and delivered byte-for-byte. The only thing that needs care is getting it in without a shell or a .env file mangling it first. Read it from a file and neither is involved:

seekrit secrets set GOOGLE_SERVICE_ACCOUNT --file ./service-account.json \
  --app storefront --env production
cat ./key.pem | seekrit secrets set TLS_KEY - --app storefront --env production

Both drop a single trailing newline and store everything else exactly as written. To read one back formatted:

seekrit secrets get GOOGLE_SERVICE_ACCOUNT --pretty --app storefront --env production

--pretty only re-indents values that parse as JSON; anything else prints unchanged. Without it, output stays byte-exact, which is what you want when piping to a file or another tool.

.env syntax

seekrit secrets import, the --env-file overlays, and the dashboard's paste .env tab all use one parser — as does the seekrit-run launcher, byte-for-byte:

A quoted value may span lines — it runs to its closing quote, wherever that lands. That is what makes a pretty-printed credential storable:

GOOGLE_SERVICE_ACCOUNT='{
  "type": "service_account",
  "private_key": "-----BEGIN PRIVATE KEY-----\nMIIEvQ…\n-----END PRIVATE KEY-----\n"
}'

Single quotes are the right choice for JSON: the value is full of double quotes and \n escapes that must survive as written, and single quotes pass them through untouched.

seekrit export --format dotenv writes this same syntax and quotes as needed, so exporting and re-importing a value round-trips exactly, escapes included.

Point-in-time restore

Every write appends to the secret's history, so a bad value is always one command away from being undone:

seekrit secrets history DATABASE_URL --app storefront --env production

VERSION  WHEN                      BY                  NOTE
v3       2026-07-24T18:22:05.994Z  user:usr_KvxTL40S…  current
v2       2026-07-24T18:19:41.769Z  user:usr_KvxTL40S…
v1       2026-07-24T18:02:13.539Z  user:usr_KvxTL40S…

Check what you're rolling back to, then roll back:

seekrit secrets get DATABASE_URL --version 2 --app storefront --env production
seekrit secrets restore DATABASE_URL 2 --app storefront --env production

Restoring is a roll-forward: v2's value is written back as v4, so nothing in the history is lost and the rollback is itself undoable. Because the server simply replays ciphertext it already stores, no key is involved — a machine (M2M) credential that cannot decrypt the value can still roll it back. The restore is audited as secret.restored.

Running & exporting

Both resolve a layered environment for the current principal:

group secrets  <  app-env secrets  <  .env file  <  process env   (highest wins)

With a service token, org/app/env come from the token. As a logged-in user, pass --app --env (and --org if ambiguous).

Once the layers are merged, ${OTHER_SECRET} references inside values are expanded — locally, in the same process that decrypted them.

seekrit run -- <command…>

Run a command with the resolved environment injected. Everything after -- is the command.

SEEKRIT_TOKEN=skt_… seekrit run -- ./start-server
# swap only the auth group to its staging slice for this boot:
seekrit run --with auth-providers=staging -- pnpm dev

run reads its .env file(s) before authenticating, so SEEKRIT_TOKEN and SEEKRIT_API_URL can live in .env — resolved as process.env > .env > saved config, matching the seekrit-run launcher. Drop a token into a project's .env and seekrit run uses it with no global login.

Resolving seekrit secrets is best-effort: if no credentials are configured or seekrit can't be reached (network, auth, or decryption failure), run logs a warning to stderr and still launches the command with just the .env overlay and process.env. This mirrors the seekrit-run launcher. (seekrit export does not degrade — it errors if it can't resolve the secrets.)

run is a transparent wrapper: it forwards termination signals (SIGINT from Ctrl-C, plus SIGTERM/SIGHUP/SIGQUIT) to the command and every process below it, then stays alive until the command exits and exits with its status (signal death is re-raised, so Ctrl-C yields 130). Relaying down the whole process tree, rather than to the one process, is what makes Ctrl-C reliably tear down commands that spawn their own children (npm/pnpm scripts running nodemon, for example), since those don't always pass the signal on themselves.

The command keeps your terminal: run does not put it in a separate session, so it stays visible in ps as usual, still gets the terminal's own Ctrl-C and its hangup when you close the window, and can still prompt on /dev/tty for things like a git credential or an SSH passphrase.

Nothing the command started outlives run. Once the command itself has exited, anything still alive underneath it has both ignored the signal and lost the process that started it, so nothing is left to stop it — not the terminal either, which only ever hangs up its own foreground group. Rather than trust it, run escalates: SIGTERM, then SIGKILL two seconds later, printing the pids it had to force-kill. A process that ignores both is usually a signal handler in the app that cleans up but never exits — in Node, process.on("SIGINT", …) replaces the default action, so the process stops dying on Ctrl-C unless the handler itself exits. Watch for that if you see the message; it names the pids. A command that exits on its own is never chased this way, so if it deliberately leaves a daemon running in the background, that keeps working.

The compiled seekrit-run launcher replaces itself with the command (exec), so signals and the process tree behave exactly as if you had run the command directly — with no wrapper left to escalate, cleaning up a command that ignores signals is up to the command. See its exit-code notes below.

seekrit export

Print the resolved secrets (managed layers + .env, without process.env). --format <dotenv|json|shell> (default dotenv).

Use shell if a shell is going to evaluate the output, not dotenv. The shell format single-quotes every value and escapes embedded quotes, so eval "$(seekrit export --format shell)" reproduces each value byte-for-byte. dotenv is written to be read back by a .env parser — seekrit's own, seekrit-run's, or your framework's — and a value carrying a $ or a backtick is not escaped against shell expansion, because a parser must not see an escape that isn't part of the value. source-ing a .env is a shell evaluating it.

seekrit-run launcher

seekrit-run is a separate, compiled single-file binary — a dependency-free seekrit run for machines (containers, CI, agents). It is service-token only and reproduces seekrit run's precedence and .env parsing exactly. See the launcher guide for install and container usage.

seekrit-run [OPTIONS] [--] <command> [args...]
seekrit-run run [OPTIONS] [--] <command> [args...]   # `run` is optional

Like seekrit run, it degrades gracefully: a missing/malformed token or an unreachable API is logged to stderr, and the command runs with just .env + the live environment. Exit codes: 2 usage error, 1 a local failure (an unreadable explicit --env-file, or a reference cycle in one), 127 command not found; otherwise the command's own exit code (Unix exec). Honors HTTPS_PROXY / ALL_PROXY. Its default API URL is the hosted https://api.seekrit.dev — the same default the Node seekrit run uses when nothing else is configured.

Last-known-good cache

Off by default. With --cache, a successful resolve is written to disk and a later run falls back to it when the seekrit API cannot be reached — so a deploy, a CI job, or an agent boot still works during an outage.

seekrit run --cache -- ./start-server

seekrit-run: could not reach the seekrit API: … — using cached secrets fetched 6m ago

Only the encrypted response is stored — ciphertext plus your token's wrapped data keys, the same bytes the API serves. Decrypting still requires the service token's private key, so the file is no more sensitive than the token sitting beside it; it is written 0600 inside a 0700 directory. The zero-knowledge invariant is untouched: nothing is written in plaintext, and nothing new is sent to the server.

How it behaves:

• Live first, always. Every invocation tries the API before touching the cache, so a recovered network is picked up immediately — the cache never serves a request that could have been answered fresh.
• A refused resolve does not fall back. If the API answers 401/403/404, the entry is deleted and the command fails as it would have anyway. Revoking a token still takes effect on the next run. Only "the API is unreachable" — a network failure, a 5xx, or a rate limit — uses the cache.
• Bounded by --cache-max-age (default 24h). Past that, the entry is ignored and pruned.
• Scoped to the exact request. The entry is keyed by API URL, token, --branch, and --with overrides, so a different environment or override never reads another's copy.
• Shared with seekrit-run. Both use the same file format and directory, so whichever one runs first warms the cache for the other.

Two trade-offs worth stating plainly, both consequences of a copy that outlives the network:

• A revoked token keeps working offline until the entry expires. That window is exactly --cache-max-age, and it only applies while the API is unreachable (a reachable API that refuses the token clears the entry immediately). Set a shorter max-age if that window matters more to you than the outage coverage.
• A run served from cache makes no resolve call, so it produces no env.resolve_denied audit entry. If you monitor for revoked credentials still in use, a cached client is invisible to that signal until it next reaches the API.

For the long-lived integrations, the same cache is configured in their own way: [cache] enabled = true in the egress proxy's config, and cache.enabled=true in the Kubernetes chart. Both also retry in the background and switch to live secrets as soon as the API answers.

Access

Who can decrypt an environment. Every command targets the environment with --env plus --app or --group.

seekrit grant --user … --env … is the bare grant verb and behaves exactly as it always has; list and rm are subcommands beside it.

Service tokens

An admin token can also be bound to an environment (pass --admin --app --env) to both provision structure and decrypt that environment.

Change approval (changes)

Review gate in front of a protected environment. See the approval workflows guide.

Approving requires a signed-in admin: a service token cannot review, because whatever holds one can already write.

Honey tokens

Decoy credentials that unlock nothing and alert your admins the moment anyone presents one. See the honey tokens guide.

A decoy is byte-for-byte indistinguishable from a real skt_ token, and presenting one returns exactly the same 401 unknown service token an unregistered token gets — so an attacker probing credentials can't tell bait from a typo. Plant them where a thief would look, never anywhere your own tooling reads: a deploy script that tries one by mistake trips the alarm just as loudly.

Agent integration

seekrit mcp

Run an MCP server over stdio so AI agents (Claude Code and other MCP clients) can drive seekrit as tools. It reads the same credentials as every other command — a SEEKRIT_TOKEN, machine credentials (SEEKRIT_CLIENT_ID + SEEKRIT_CLIENT_SECRET, which auto-mint an admin token), or the saved config.

# Register with Claude Code (token selects the org; admin token enables provisioning):
SEEKRIT_TOKEN=skt_… claude mcp add seekrit -- seekrit mcp

For a fully autonomous agent, pass machine credentials instead — the server mints and caches its own admin token from them (see the AI agents guide):

claude mcp add seekrit \
  --env SEEKRIT_CLIENT_ID=… --env SEEKRIT_CLIENT_SECRET=… -- seekrit mcp

All decryption happens locally, in this process — the server exposes the tools that touch plaintext (secret values, data keys, decryption-capable grants), which is why it runs on your machine rather than a hosted endpoint. Call get_started first — an in-protocol tool (and the server's instructions, shown to the model on connect) that returns the recommended first-project recipe so an agent landing here mid-context can orient itself. Other tools include create_org/create_app/create_env, set_secret/get_secret, create_token, grant_env, and run_command (inject secrets into a subprocess without returning their values). Because stdin is the transport, user-auth sessions that decrypt need SEEKRIT_PASSPHRASE set (token auth needs nothing extra). Prefer run_command over get_secret with reveal:true so plaintext never enters the agent's context.

seekrit paperclip init

Attach the seekrit MCP servers to a Paperclip agent, and print the environment variables to paste into its adapter config.

Paperclip is a control plane: its adapter launches the runtime, and the runtime is what speaks MCP. So there is no Paperclip-side switch that means "give this agent the seekrit tools" — the servers go in a project-scoped .mcp.json in the working directory the agent runs in, which is what this writes.

seekrit paperclip init --dir /srv/paperclip/workspaces/storefront \
  --preset anthropic --preset openai

An existing .mcp.json is merged, not replaced: other servers and unknown top-level keys survive, and a seekrit entry someone customised (a pinned version, an added env) is left alone unless you pass --force.

Every printed value is a plain string — a placeholder is not a secret, so none of it needs a Paperclip secret_ref and none of it trips PAPERCLIP_SECRETS_STRICT_MODE. The proxy config itself stays with seekrit proxy init, which the output points you at.

seekrit openclaw init

Add the seekrit exec SecretRef provider to an OpenClaw gateway, so openclaw.json names credentials instead of holding them.

seekrit openclaw init --write

openclaw.json is JSON5, so a file carrying comments or trailing commas is printed to, never written — a rewrite through a JSON round trip would delete every comment in it. A file that is also valid strict JSON is merged: other providers and unknown top-level keys survive, and a seekrit entry someone customised is left alone unless you pass --force.

With --exec, the generated command is an absolute path to the Node binary and the first argument is this CLI's own entry file. That is deliberate: OpenClaw refuses a symlinked command, and the seekrit on your PATH is a package-manager shim that symlinks into node_modules.

seekrit openclaw ref

Print the SecretRef object to paste in place of a plaintext credential.

seekrit openclaw ref OPENAI_API_KEY
seekrit openclaw ref STRIPE_SECRET_KEY --app billing-api --env production

seekrit openclaw resolve

The exec SecretRef protocol handler: reads a JSON request on stdin and writes the resolved values on stdout. OpenClaw calls this — there is no reason to run it by hand, and it takes no flags precisely because the gateway passes none.

It resolves each distinct environment once per batch, skips .env overlays entirely (the working directory belongs to the gateway, so a stray .env must not override a gateway credential), and reports a failure as a per-id error code with no message — resolver output may contain credentials, so OpenClaw declines to display it.

seekrit hermes init

The hermes commands wire seekrit into a Hermes Agent as a secret source. The source itself is Python and ships in the Python SDK (pip install seekrit); these two commands cover the parts that are not.

Print the secrets: block for ~/.hermes/config.yaml, and optionally scaffold the plugin directory.

seekrit hermes init
seekrit hermes init --mapped \
  --bind OPENAI_API_KEY=OPENAI_KEY \
  --bind STRIPE_SECRET_KEY=billing/STRIPE_SECRET_KEY \
  --token billing=SEEKRIT_TOKEN_BILLING

config.yaml is printed, not written: it is YAML belonging to somebody's agent, with comments and anchors this CLI carries no parser for. The scaffolded plugin files are written, because those two files are entirely ours — and __init__.py re-exports register from the installed SDK rather than copying the implementation, so it never has to be regenerated.

seekrit hermes ref

Print the skt:// reference to bind a Hermes variable to.

seekrit hermes ref OPENAI_KEY
seekrit hermes ref STRIPE_SECRET_KEY --token-alias billing

A reference names a token and a secret, not an app and environment: a skt_ service token is bound to one environment, so an skt://app/env/NAME spelling would be a reference nothing on the read path could resolve.

Temporary Postgres credentials (pg)

Mint short-lived database logins that auto-expire. Minting happens client-side: the password and its SCRAM verifier are generated on your machine and only the verifier is sent, so the plaintext never reaches seekrit or Postgres at rest. See Temporary access.

# Register a read-only target (prints the group-role setup SQL to run once):
SEEKRIT_PG_ADMIN_URL=postgres://admin:…@db.example.com:5432/app \
  seekrit pg target add --name prod-db --host db.example.com --database app --access readonly

# Lease a 30-minute credential and hand the URL straight to psql:
psql "$(seekrit pg lease prod-db --ttl 30m)"

Temporary MySQL / MariaDB credentials (mysql)

The MySQL/MariaDB analog of pg. Minting is client-side too: the password and its mysql_native_password hash are generated on your machine and only the hash is sent, so the plaintext never reaches seekrit or MySQL at rest. Presets apply their GRANTs inline per user (no one-time setup step), and there is no account-level expiry — the broker drops the user at the deadline. See Temporary access.

# Register a read-only target (no setup SQL needed — grants apply inline):
SEEKRIT_MYSQL_ADMIN_URL=mysql://admin:…@db.example.com:3306/app \
  seekrit mysql target add --name prod-db --host db.example.com --database app --access readonly

# Lease a 30-minute credential and hand the URL straight to the mysql client:
mysql "$(seekrit mysql lease prod-db --ttl 30m)"

Temporary Redis credentials (redis)

The Redis (6+) analog of pg/mysql. Minting is client-side too: the password and its SHA-256 digest are generated on your machine and only the digest is sent (ACL SETUSER … on #<digest>), so the plaintext never reaches seekrit or Redis at rest. Presets apply their ACL rules inline per user (no one-time setup step), and there is no account-level expiry — the broker deletes the ACL user at the deadline. See Temporary access.

# Register a read-only target (ACL rules apply inline, no setup step):
SEEKRIT_REDIS_ADMIN_URL=rediss://default:…@cache.example.com:6379 \
  seekrit redis target add --name prod-cache --host cache.example.com --access readonly

# Lease a 30-minute credential and hand the URL straight to redis-cli:
redis-cli -u "$(seekrit redis lease prod-cache --ttl 30m)"

Agent egress proxy (proxy)

Fetch, configure, and run seekrit-proxy without a Rust toolchain and without hand-writing a config file. The proxy itself is unchanged by these commands — they resolve the released binary (verifying its SHA-256) and generate the same TOML you would otherwise write.

Generating a config

init and run share these flags. Pass presets, ad-hoc hosts, or an agent identity — the last takes the rules from published policy and cannot be combined with the first two, because server-policy mode rejects local rules rather than silently ignoring them.

init additionally takes -o, --out <path> (default ./seekrit-proxy.toml), --print to write to stdout instead, and --force to overwrite.

run additionally takes -c, --config <path>, --proxy-version <version>, and --print-config. With no generation flags it runs the config file as-is.

Deciding a held request

[approval] in the proxy's config marks operations that stop for a human before they are dispatched — see stop for a human. A proxy attached to a terminal prompts there; these commands are for every other case.

seekrit proxy approvals

ID            OPERATION        REQUEST                              CARRIES              EXPIRES
apr_00000003  money movement   POST api.stripe.com/v1/charges       STRIPE_SECRET_KEY    98s

seekrit proxy approve apr_00000003

They talk to the proxy's [control] listener, so that block has to be configured and SEEKRIT_PROXY_CONTROL_TOKEN has to be set to the same value the proxy was started with. The token is read from the environment and has no flag: it is what decides whether a held request goes through, and a flag would put it in shell history beside the operation it is guarding.

Resolving the binary

Downloads are cached under $XDG_CACHE_HOME/seekrit/proxy/v<version>/<target>/, so the fetch happens once per version. A binary already on PATH is deliberately not used: silently running a different version than the one the CLI pins is the kind of surprise that costs an afternoon.

Agent access policy (agents)

Author, review, and publish the agent access policy the proxy above enforces. Everything the dashboard's Agents screen does, from a terminal — including signing, which still happens on this machine with your own key, never on the server.

<ref> is a slug or an id, so nova works everywhere agt_… does.

Dispatching a run

Policy says what an agent may do; a task says what this run may do, and expires on its own. The token is printed to stdout and everything else to stderr, so the common thing needs no parsing:

TASK=$(seekrit agents dispatch nova --scope GITHUB_TOKEN --ttl 15m --label "triage 412")

The run then presents it in x-seekrit-ticket, the same header a locally-minted proxy ticket uses — an enforcement point tells them apart by prefix (skd_ was dispatched by seekrit, skp_ was minted by the proxy's own control listener).

The token is shown once. seekrit stores only its hash, so a lost token cannot be recovered — dispatch another and revoke the first.

Policy as code (agents policy)

The loop the pull/publish pair exists for:

seekrit agents policy pull nova -o nova.policy.json

Edit it, commit it, get it reviewed like any other change, then:

seekrit agents policy publish nova -f nova.policy.json --ttl 7d

publish prints a diff against the live version and asks before signing (-y skips the question). -f - reads the rules from stdin. A rule file is either a bare JSON array or the { "rules": [...] } object pull writes, validated against the same schema the dashboard and API use — so a typo fails before anything is signed.

Reviewing a grant against what happened

Policy drifts in both directions: rules nobody exercises stay forever, and rules the agent needs never get added. review closes that loop from the evidence a proxy reported.

seekrit agents review nova --days 14

nova — policy v7, 4,983 decision(s) over 14d

proposals
- rule 1 (api.openai.com) permits ANTHROPIC_API_KEY, never injected in 4102 permitted request(s)
- rule 3 (api.github.com) never matched a request, while other rules did
? 12 request(s) to hooks.slack.com matched no rule (POST) — the agent wants this and cannot have it

2 narrowing change(s) can be applied; 1 need a human decision

- is a narrowing review will apply; ? needs a person. Write the narrowed rules out and publish them through the normal path:

seekrit agents review nova -o nova.policy.json

seekrit agents activity nova shows the raw evidence — hosts, methods, decisions, which rule decided, and which secrets were actually injected.

Checking a policy before an agent hits it

simulate runs the same evaluator the proxy compiles in, so a dry run and a real refusal agree — including which rule decided and which constraint refused.

seekrit agents simulate nova --host api.stripe.com --method POST --path /v1/charges --secret STRIPE_SECRET_KEY

It exits non-zero on a denial, which is what makes it usable as a policy test in CI:

DENY  POST api.stripe.com/v1/charges [STRIPE_SECRET_KEY]
  v3: this host has rules, but none cover this path

HashiCorp Nomad (nomad)

Helpers for the Nomad secret provider plugin — the seekrit-nomad-secrets binary a Nomad client execs to resolve a job's secret block. The plugin does the decrypting; these commands install it, print the configuration, and prove it works.

seekrit nomad init

Print the agent stanza, the plugin config, and a job snippet — filled in for the machine you run it on.

seekrit nomad init --profile billing-prod --namespace billing
seekrit nomad init --profile billing-prod --namespace billing --write

Without --namespace or --job, the profile is reachable by every job on that client — which is a weaker boundary than a job file suggests. The config is written 0600 because it names token files and decides which jobs reach them; the plugin refuses to read it if it is group- or world-writable.

seekrit nomad install

Download the plugin onto this Nomad client, verify its SHA-256, and place it where Nomad will find it.

sudo seekrit nomad install

The binary is installed as <plugin-dir>/secrets/seekrit, not under its artifact name: Nomad matches a job's provider value against the executable's filename. The checksum is verified before anything is written, and the file is renamed into place atomically so Nomad can never fingerprint a partial download.

Restart the agent afterwards — plugins are fingerprinted at client startup.

seekrit nomad check

Run the installed plugin exactly the way Nomad does, including the namespace and job id it would pass.

seekrit nomad check --path billing-prod --namespace billing --job billing-api

Reports whether the plugin is installed, whether it fingerprints, and how many secrets a fetch returned — a count, never names or values. Exits non-zero if any step fails, so it drops into a provisioning run.

Self-hosted provisioner (provisioner)

Helpers for the remote executor — the seekrit-provisioner daemon that runs a target's provisioning SQL inside your own network, so seekrit never sees the database admin credential.

Temporary SSH access (ssh)

Issue short-lived SSH certificates. seekrit acts as a certificate authority: target add generates a CA keypair locally (only the private half is wrapped and uploaded) and prints the public key to install on your hosts. Minting generates an ephemeral keypair on your machine and sends only the public key; the signed certificate comes back and the private key never leaves. See Temporary access.

# Create a CA target and install the printed CA key on your hosts:
seekrit ssh target add --name prod-fleet --host bastion.example.com --user deploy --principal deploy

# Issue an 8-hour cert, then run the ssh command it prints:
seekrit ssh lease prod-fleet --ttl 8h

Temporary AWS credentials (aws)

Mint short-lived AWS credentials via STS AssumeRole (a tier-2 provider — the credential comes back wrapped to your machine's ephemeral key, never in the clear through seekrit). target add registers one assumable IAM role and wraps a base IAM credential (needs only sts:AssumeRole) to the broker. Minting generates an ephemeral P-256 keypair locally, sends only the public key, and unwraps the returned credential on your machine. See Temporary access.

# Register a role (base creds from your AWS env vars), then source a 1h credential:
seekrit aws target add --name prod-deploy \
  --role-arn arn:aws:iam::123456789012:role/seekrit-deploy --region us-east-1

eval "$(seekrit aws lease prod-deploy --ttl 1h)"
aws sts get-caller-identity

Temporary GCP credentials (gcp)

Mint short-lived GCP access tokens via IAM generateAccessToken (a tier-2 provider — the token comes back wrapped to your machine's ephemeral key, never in the clear through seekrit). target add registers one impersonable service account and wraps a base service-account key (needs roles/iam.serviceAccountTokenCreator on the target) to the broker. Minting generates an ephemeral P-256 keypair locally, sends only the public key, and unwraps the returned token on your machine. See Temporary access.

# Register a service account (source key from GOOGLE_APPLICATION_CREDENTIALS),
# then source a 1h token:
seekrit gcp target add --name prod-deploy \
  --service-account deploy@my-project.iam.gserviceaccount.com

eval "$(seekrit gcp lease prod-deploy --ttl 1h)"
gcloud storage ls

Temporary MongoDB credentials (mongodb)

Mint short-lived MongoDB users (a tier-2 provider — MongoDB hashes the password server-side, so the broker generates it, runs createUser, and returns the credential wrapped to your machine's ephemeral key, never in the clear through seekrit). target add registers one cluster and wraps an admin mongodb:// connection string (needs userAdmin on the database) to the broker. Minting generates an ephemeral P-256 keypair locally, sends only the public key, and unwraps the returned credential on your machine. Unlike AWS, revoke is real — it drops the user. See Temporary access.

# Register a cluster (admin creds from SEEKRIT_MONGODB_ADMIN_URL), then lease a 1h user:
export SEEKRIT_MONGODB_ADMIN_URL='mongodb://admin:pw@mongo.example.com:27017/?authSource=admin'
seekrit mongodb target add --name prod-app --database app --access readonly

eval "$(seekrit mongodb lease prod-app --ttl 1h)"
mongosh "$MONGODB_URI"

Managed keys (kms)

Client-side managed keys for application-layer encryption and signing. Material is generated locally and wrapped to grantees; the server never sees it. See the Managed keys guide.

# Encrypt a field, bound to its context, then read it back:
echo -n "$SSN" | seekrit kms encrypt --key pii --context "field=ssn" > ssn.enc
seekrit kms decrypt --key pii --context "field=ssn" < ssn.enc

# Sign a release and verify it:
echo -n "release-v1.2.3" | seekrit kms sign --key release-signer > r.sig
echo -n "release-v1.2.3" | seekrit kms verify --key release-signer --signature "$(cat r.sig)"

Secret rotation (rotation)

Managed, scheduled replacement of a stored secret's value — and, for the database kinds, of the password on the account it belongs to. (admin). Enabling rotation wraps the environment's data key to your org's rotator key locally; see the rotation guide and Secret rotation.

Every command accepts a rotation id (rot_…) or the secret's name when that name rotates in only one environment. Durations accept s/m/h/d suffixes (minimum 5 minutes, maximum 365 days).

# Re-key an existing Postgres role weekly, against a registered target:
seekrit rotation enable DATABASE_PASSWORD --app web --env production \
  --kind postgres --target prod-db --username app_user --every 7d --now

# A value only your own code checks — nothing external is contacted:
seekrit rotation enable API_SIGNING_KEY --app web --env production \
  --kind generated --every 30d

seekrit rotation list
seekrit rotation rotate DATABASE_PASSWORD   # e.g. after a suspected exposure

Customer-controlled recovery (recovery)

Org-scoped M-of-N recovery. The recovery key is generated and split locally; seekrit stores only its public half and shares it cannot open. Management is (admin); any custodian can approve a ceremony. See the recovery guide.

# Enable 3-of-5 recovery, then check coverage:
seekrit recovery setup --threshold 3 \
  --custodian alice@example.com --custodian bob@example.com --custodian carol@example.com \
  --custodian dan@example.com --custodian erin@example.com
seekrit recovery status

# Run a ceremony: start it, custodians approve, then the target completes.
seekrit recovery request                 # prints rrq_…
seekrit recovery approve rrq_XXXXXXXX     # each custodian, until the quorum is met
seekrit recovery complete rrq_XXXXXXXX

Break-glass export (archive)

The whole org as one signed file, and the offline tools to open it. create is the only subcommand that talks to the API; info, verify, share, decrypt, and decryptor never touch the network and need no credentials or config, so they work on an air-gapped machine. See the export guide.

decrypt takes its key from --token, --key-file, a quorum of --share files, or (by default) the archive's own keyMaterial unlocked with your passphrase — prompted, or SEEKRIT_PASSPHRASE. Environments your key holds no grant on are skipped, not failed.

# Export, verify against the published signing key, and open it offline.
seekrit archive create --out acme.json
seekrit archive verify acme.json --key-id 1ab3bd8b98170773
seekrit archive decrypt acme.json --out ./plaintext

# Break glass: two custodians each unwrap a share, then a quorum opens everything.
seekrit archive share acme.json --out share-ana.json          # custodian 1
seekrit archive share acme.json --token skt_… --out share-ci.json  # custodian 2
seekrit archive decrypt acme.json --share share-ana.json --share share-ci.json --out ./recovered

Your account

Your devices and your email preferences. Both are per-user, not per-org, so neither takes --org.

Audit

seekrit audit

Print the org's audit trail — the append-only record of every mutation. Admins only.

When more entries remain, the next cursor is printed to stderr so it doesn't corrupt piped output.

seekrit audit actions

List every action the trail can record — the vocabulary for --action.

# Everything that changed who can decrypt something, as JSON:
seekrit audit --action env.key_granted --all --json

Audit export (log-sink)

Ship every audit row to your own OTLP/HTTP collector (SIEM) within about a minute of it being written. Admins only. Header values are write-only — encrypted at rest and never returned — so show reports only the header names.

seekrit log-sink set https://collector.example.com/v1/logs \
  --header "Authorization: Bearer $SIEM_TOKEN"
seekrit log-sink test

Third-party sync

Push an environment's resolved secrets to a platform that keeps its own copy: Vercel project env vars, Cloudflare Worker secret bindings, Cloudflare Pages env vars, Cloudflare Secrets Store secrets, Railway service variables, AWS Secrets Manager secrets, AWS SSM parameters, a Render service or environment group, a Fly.io app's secrets, a Northflank secret group, DigitalOcean App Platform variables, Heroku config vars, Netlify site variables, Bunnyshell environment or project variables, GitHub Actions secrets, or Google Secret Manager secrets. Admins only. Each destination has its own guide under Third-party sync.

A connection is a destination account; a binding is one environment syncing to one place in it.

seekrit sync enable takes the environment (--env, plus --app), the connection (--connection), and the destination:

Enabling wraps the environment's data key — and the key of every group it composes — to the connection, on your machine. You need a key for all of them, so run it as someone who can already read the environment.

printf '%s' "$VERCEL_TOKEN" | seekrit sync connect --name acme-vercel --team-id team_…
seekrit sync enable --connection acme-vercel --app storefront --env production \
  --project prj_… --target production --acknowledge-decryption
seekrit sync run syb_…

# Cloudflare: one scoped token per product, plus the account id
printf '%s' "$CLOUDFLARE_API_TOKEN" | seekrit sync connect --name acme-cf \
  --provider cloudflare-workers --account-id 0123456789abcdef0123456789abcdef
seekrit sync enable --connection acme-cf --provider cloudflare-workers \
  --script my-api --app storefront --env production --acknowledge-decryption

# Railway: three UUIDs address a variable, and the token kind picks the header
printf '%s' "$RAILWAY_TOKEN" | seekrit sync connect --name acme-railway \
  --provider railway --token-kind project
seekrit sync enable --connection acme-railway --provider railway \
  --railway-project 11111111-1111-4111-8111-111111111111 \
  --railway-environment 22222222-2222-4222-8222-222222222222 \
  --service 33333333-3333-4333-8333-333333333333 \
  --app storefront --env production --acknowledge-decryption

# AWS: the region and key id are config, the secret access key is the credential
printf '%s' "$AWS_SECRET_ACCESS_KEY" | seekrit sync connect --name acme-aws \
  --provider aws-secrets-manager --region us-east-1 --access-key-id AKIA…
seekrit sync enable --connection acme-aws --provider aws-secrets-manager \
  --path prod/storefront/ --app storefront --env production --acknowledge-decryption

# Render: one key for the whole workspace, then a service or an env group
printf '%s' "$RENDER_API_KEY" | seekrit sync connect --name acme-render --provider render
seekrit sync enable --connection acme-render --provider render \
  --service srv-abc123 --app storefront --env production --acknowledge-decryption
seekrit sync enable --connection acme-render --provider render \
  --env-group evg-xyz789 --app storefront --env staging --acknowledge-decryption

# Fly.io: the app name is the whole destination; nothing to set on the connection
printf '%s' "$(fly tokens create deploy -a storefront-production)" \
  | seekrit sync connect --name acme-fly --provider fly
seekrit sync enable --connection acme-fly --provider fly \
  --fly-app storefront-production \
  --app storefront --env production --acknowledge-decryption

# Northflank: one secret group, named by slug — the token carries its own team
printf '%s' "$NORTHFLANK_API_TOKEN" | seekrit sync connect --name acme-northflank \
  --provider northflank
seekrit sync enable --connection acme-northflank --provider northflank \
  --project default-project --secret-group app-secrets \
  --app storefront --env production --acknowledge-decryption

# DigitalOcean App Platform: app-level variables, written encrypted.
# Each push submits a new app spec, which starts a deployment.
printf '%s' "$DIGITALOCEAN_TOKEN" | seekrit sync connect --name acme-digitalocean \
  --provider digitalocean
seekrit sync enable --connection acme-digitalocean --provider digitalocean \
  --do-app 4f6c71e2-1e90-4762-9fee-6cc4a0a9f2cf \
  --app storefront --env production --acknowledge-decryption

# Heroku: config vars on one app — each push restarts its dynos
printf '%s' "$(heroku authorizations:create --short)" \
  | seekrit sync connect --name acme-heroku --provider heroku
seekrit sync enable --connection acme-heroku --provider heroku \
  --heroku-app storefront-production \
  --app storefront --env production --acknowledge-decryption

# Netlify: one site's variables, per deploy context — the team is on the connection
printf '%s' "$NETLIFY_AUTH_TOKEN" \
  | seekrit sync connect --name acme-netlify --provider netlify --account-id acme
seekrit sync enable --connection acme-netlify --provider netlify \
  --netlify-site 3970e0fe-8564-4903-9a55-c5f8de49fb8b \
  --target production,deploy-preview \
  --app storefront --env production --acknowledge-decryption

# Bunnyshell: one environment's variables — the connection carries no scope
printf '%s' "$BUNNYSHELL_TOKEN" \
  | seekrit sync connect --name acme-bunnyshell --provider bunnyshell
seekrit sync enable --connection acme-bunnyshell --provider bunnyshell \
  --bunnyshell-environment env-9f3a2b \
  --app storefront --env production --acknowledge-decryption

# Bunnyshell: the project instead, to seed ephemeral environments that don't exist yet
seekrit sync enable --connection acme-bunnyshell --provider bunnyshell \
  --project prj-4c8d1e \
  --app storefront --env preview --acknowledge-decryption

# GitHub Actions: prefer seekritdev/github-action, which decrypts in the run.
# Sync only for what an Action cannot reach — `with:` inputs of third-party
# actions, `secrets: inherit`, job-level container/services credentials.
printf '%s' "$GITHUB_TOKEN" \
  | seekrit sync connect --name acme-github --provider github-actions
# ...to one deployment environment's secrets, the narrowest scope GitHub has
seekrit sync enable --connection acme-github --provider github-actions \
  --gh-repo acme/storefront --gh-environment production \
  --app storefront --env production --acknowledge-decryption
# Google Secret Manager: the credential is the whole key file, so pipe it in
seekrit sync connect --name acme-gcp --provider gcp-secret-manager \
  --project-id acme-prod < key.json
seekrit sync enable --connection acme-gcp --provider gcp-secret-manager \
  --gcp-prefix prod-storefront- --gcp-prune-versions \
  --app storefront --env production --acknowledge-decryption

# Azure Key Vault: a service principal's client secret, one vault per binding
printf '%s' "$AZURE_CLIENT_SECRET" \
  | seekrit sync connect --name acme-azure --provider azure-key-vault \
      --azure-tenant-id 72f988bf-86f1-41af-91ab-2d7cd011db47 \
      --azure-client-id 0a1b2c3d-4e5f-6071-8293-a4b5c6d7e8f9
seekrit sync enable --connection acme-azure --provider azure-key-vault \
  --vault acme-prod \
  --app storefront --env production --acknowledge-decryption

Billing