Hand secrets to agents, CI jobs, servers and people

curl -sS --fail-with-body \
  "${CKRETS:-https://ckrets.ai}/v1/secrets" \
  -H 'content-type: application/json' \
  -d '{"value":"LAB_7f3a9c","ttl":"1h"}'

Try it

The safe shape first: the value comes from a file, is addressed to one key, and is revealed straight into the process that uses it. Needs curl, jq and uuidgen; set CKRETS to the origin you call.

CKRETS=${CKRETS:-https://ckrets.ai}
# KEY_ID: the recipient's keyId, from
# the free key it minted (POST /v1/keys)
jq -n --rawfile v ./secret.txt \
  --arg to "$KEY_ID" \
  '{value:$v, ttl:"1h",
    audience:{type:"key", id:$to}}' |
curl -sS --fail-with-body "$CKRETS/v1/secrets" \
  -H 'content-type: application/json' \
  -H "idempotency-key: $(uuidgen)" \
  --data-binary @- > created.json
TOKEN=$(jq -er .token created.json)
# hand the token on; keep created.json
# (its manageToken reads status and revokes)

# CKRETS_KEY: its own key (POST /v1/keys
# mints one); CKRETS as above
# who sent it (spends nothing):
curl -s "$CKRETS/v1/secrets/$TOKEN/public" \
  | jq .sender
# reveal into deploy.sh's environment only;
# deploy.sh runs only if the reveal worked:
v=$(curl -sS --fail-with-body \
  -H "authorization: Bearer $CKRETS_KEY" \
  "$CKRETS/v1/secrets/$TOKEN" \
  | jq -er .value) &&
  DATABASE_URL="$v" ./deploy.sh
# once the helper is published, it does the same
# (then check: npm audit signatures):
# npx -y @ckrets/helper@0.9.0 \
#   reveal "$TOKEN" \
#   --env DATABASE_URL -- ./deploy.sh

CKRETS=${CKRETS:-https://ckrets.ai}
TOKEN=$(curl -sS --fail-with-body \
  "$CKRETS/v1/secrets" \
  -H 'content-type: application/json' \
  -d '{"value":"LAB_7f3a9c","ttl":"1h"}' \
  | jq -er .token)
U="$CKRETS/v1/secrets/$TOKEN"
# its state, spending nothing: pending
curl -s "$U/public" | jq -r .state
# reveal once, off screen: 200
curl -s -o /dev/null -w '%{http_code}\n' "$U"
# and now: revealed, gone for good
curl -s "$U/public" | jq -r .state

{ "token": "ck_SRG73…",
  "url": "https://ckrets.ai/r/ck_SRG73…",
  "manageToken": "ckm_…",
  "expiresAt": "2026-12-01T13:11:09Z",
  "revealsLeft": 1,
  "digest": "hmac-sha256:Rk3pX9…",
  "receipt": "eyJhbGciOiJFUzI1NiJ9…" }

Every use case, runnable: examples by use case. The API, keys, limits and errors: the API, limits, errors.

How it works

1. Create. POST /v1/secrets with the value (from a file) and a time to live. No key for the first call; a free key raises every limit.
2. Name the recipient. An audience: a ckrets key, a CI job's OIDC identity, or a public key. Without one, the link is the key.
3. Reveal, once. The recipient proves who it is and gets the value straight into its process, or a person clicks the link. Then it is gone.
4. Keep the receipt. Signed with published keys, checkable offline: proof that the right party collected it.

Security

Beta: no uptime commitment yet; pricing and limits may change, with notice in the changelog.

For agents

Start at /quickstart.md (create, check, reveal: one short page), then /llms.txt, the index. Each docs page made from Markdown links its source (/for-agents.md, /limits.md and the rest); /docs/start is HTML only.

{ "mcpServers": { "ckrets": { "url": "https://ckrets.ai/mcp" } } }

Tools on the remote server (/mcp-tools.json also lists the stdio-only and planned ones): create_secret, get_secret_status, revoke_secret, get_limits, get_public_view, verify_receipt. No tool returns a value. create_secret takes the value as an argument, so a value you create through MCP is in your context.