## 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

```text
how to store secrets for cron-run agents
```

## Use 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

1. 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.
2. 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.
3. Set the narrowest permissions the API allows: read-only tokens where possible.
   Expected output: Blast radius limited if a secret ever leaks.
4. 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