Prompt: api keys for scripts and ci, least privilege and rotation
Have an agent set up ird API keys for unattended use — one key per job,
named so you know what to revoke — wire them into scripts and CI with
the right flags, prove each key works, and put a rotation and leak
response routine in place, without the key ever landing in a repo or a
prompt.
Needs: the ird CLI, logged in with your account (key management refuses API keys — ird login first); a secret store on the CI/host side
Costs: nothing in the price book covers ird keys or ird whoami; the verification reads are ordinary per-request reads (check credits_prices if a job runs them in a loop)
Group: developer workflow
Paste everything below the line into a fresh conversation. Fill in the
FILL IN block first.
Task
Create the API keys listed below, hand me each one exactly once, verify
them, and produce the wiring and the rotation plan. Never print a key
into this conversation after the creation step.
FILL IN
JOBS: # one key per job: name — what it is allowed to do
ci-deploy-docs — pin ./dist and publish the IPNS name for docs.example.ro
cron-dns-check — read-only: dns_get_zone, list_tunnels, credits_balance
server-tunnel — run `ird tunnel` on one host
ROTATE_EVERY_DAYS: 90
SECRET_STORE: GitHub Actions secrets # where keys live on the job side
Non-negotiable rules
- One key per job, named after it.
ird keys create takes a name
and nothing else — no scopes, no expiry (ird keys create --help) —
so a key is account-wide. Least privilege is a separate key per JOBS
line plus a written allowed-action list the script sticks to; the
name is what makes one leak revocable without downtime elsewhere.
- Treat the key as shown once.
ird keys create prints it; relay
it to me immediately in the creation
step and never repeat it — not in summaries, files, commit messages,
examples or the deliverable. If it ends up in a repo or a prompt,
treat it as leaked (step F).
- Keys are not sessions. Some operations refuse API keys and need a
logged-in session, sometimes with a TOTP code —
ird keys itself,
and anything on a domain marked sensitive (apps_deploy's totp_code
is "session auth only — API keys are refused"; ird vps create
--totp likewise needs a code). Plan those jobs
as manual steps, don't work around it.
- Unattended means
--no-input. Scripts run with --json --yes
--no-input so a prompt fails the job instead of hanging it — but
--yes answers confirmation prompts, so such a script can spend
credits; keep spending calls out of jobs that don't need them.
Steps
A. Baseline. ird whoami (my account; ird keys needs the ird
login session, not a key) and
ird keys list --json — existing keys with ids and names; flag any
JOBS doesn't mention as revocation candidates.
B. Create. For each JOBS line: ird keys create <name>. Show me the
key once, with name, id and where it goes (SECRET_STORE). Name pattern
<job>-<YYYYMM> makes the creation month visible for rotation.
C. Wire it. Two ways, pick per job:
- environment:
IRD_API_KEY=… — the CLI and ird mcp read it (same
key for both);
- explicit:
--api-key … on any command — it overrides the stored key
and IRD_API_KEY; prefer the env var so the key never appears in a
process list or log.
Unattended commands get --json --yes --no-input (-q for essentials
only). Servers running ird tunnel may instead
ird login --with-key once.
D. Verify each key from the job's side, never from my machine:
ird whoami --api-key "$IRD_API_KEY" --json must name my account;
then one read the job actually needs (ird dns records example.ro
--json, ird tunnels list --json, ird credits --json). A job that
only reads must never be tested with a write.
E. Rotation. Every ROTATE_EVERY_DAYS: create <job>-<new month>,
update SECRET_STORE, run step D with the new key, then
ird keys revoke <old key-id> — it stops working immediately, so the
order matters. Write it as a deliverable checklist.
F. Leak response. ird keys revoke <key-id> first, questions later;
then ird credits ledger --limit 200 --kind charge --json for charges
since the leak and ird tunnels list, ird vps list, ird ipfs pins,
ird p2p list for resources you did not create — remove those only
with my approval per item (destroy is irreversible). Then steps B and D
for the replacement key.
G. Hygiene check. Grep the jobs' repos for IRD_API_KEY= followed
by a literal and for any key prefix ird keys list shows; a hit is a
leak. Confirm .env is git-ignored and CI masks the secret.
Deliverable
A table: job, key name, key id, created, allowed actions, where stored,
verified (yes/no, account matched), next rotation date. Then the
exact command lines per job (with $IRD_API_KEY, never the value), the
rotation checklist, the leak-response checklist, and the list of
operations from JOBS that need a session instead of a key.