Either you'd use an encryption algorithm that depended on a "deeper" key... or you'd fetch the new key while authenticated with, you guessed it, another "deeper" key.
It's keys all the way down. Every key you use, it's your responsibility to keep it private.
(Unless you want to be dealing with physical hardware dongles that generate keys, but those aren't exactly easily portable.)
What you have to consider is that starting a service is often not just a one time fire-and-forget operations. Applications crash need auto-restart, usually via systemd, kubernetes or something. So the keys-all-the-way down knowledge need to be integrated throughout that whole stack or on the side of it.
Kubernetes ServiceAccounts are based on a very similar flow, they are temporary certificates that are mounted into each Pod, used to connect to the API server and deciding what that Pod is allowed to access.
I'm not sure I really see the point, but I guess you could lock down the main call on another system, store the temporary token somewhere, and have the other systems use it.
As you say, you still need the top level credentials somewhere to get a new token.