No session, no live approval, no interactive fallback
A batch or scheduled job typically runs unattended, often at an hour with nobody watching, using credentials configured well before the job actually executes. It can't prompt for step-up authentication if it hits something sensitive, and it can't pause for human approval the way an interactive workflow can. Whatever authorization the job needs has to be fully determined and provisioned ahead of time, not negotiated at run time.
This makes the credential a scheduled job runs under a particularly consequential design decision. A job that runs under a broad, general-purpose service account because it was convenient to set up inherits far more authority than the specific task needs — and because nobody's watching when it runs, that excess authority sits quietly available to anything that manages to trigger or tamper with the job.
Scoping the job's authority to exactly its task
The more defensible pattern scopes each scheduled job's credential to precisely what that job does and nothing else: a service account with access to the specific resources the job touches, ideally time-bound to the job's expected run window, and monitored for any execution outside its expected schedule or scope. A job that unexpectedly runs at an unusual time, or attempts to access something outside its normal pattern, is a meaningful signal precisely because there's no human in the loop who might otherwise have simply misclicked.