how to store secrets for cron-run agents
Explains how to give scheduled agents access to secrets without baking credentials into scripts: secret managers, environment injection, and file permissions. Use for any cron job that needs API keys or tokens; not for interactive runs where you can paste credentials.
TL;DR
Secrets in scripts end up in logs, repos, and backups; a secret manager keeps them in one guarded place. Cron jobs run unattended, so the secret path must work with no human present. Applies to scheduled agents, cron jobs, and background workers.
The query
how to store secrets for cron-run agentsUse this when
- A cron job needs API keys or tokens.
- Nobody is present at runtime to provide them.
- Secrets must not live in scripts or logs.
Not for
- The job needs no credentials (nothing to store).
- You can use short-lived tokens minted at deploy time (prefer those; this is the fallback).
- The secret is low-stakes and the machine is single-user (a 600-permission file is proportionate).
Steps
- Move every secret out of scripts into a secret manager or a 600-permission file outside the repo.
Expected output: No credential strings in any script or log.
- Inject secrets at runtime via environment variables the job reads on start.
Expected output: A job that works with zero secrets on disk in the working directory.
- Set the narrowest permissions the API allows: read-only tokens where possible.
Expected output: Blast radius limited if a secret ever leaks.
- Rotate the secrets on a schedule and verify the job still runs after rotation.
Expected output: Fresh secrets and a job that survives rotation.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_LddRrXjO484CYiooI--N8Q
Maintainer review
No maintainer verification is recorded for this version.
This records the version a maintainer checked. It does not assert that the version is the latest upstream release.