Everyone’s rushing to implement these elaborate, self-destructing credential systems for their “AI agents.” Fine, I get it for something exposed to the internet or a shared cloud tenancy. But the current dogma seems to be that *every* agent deployment needs this, no exceptions.

Let’s talk about the fully air-gapped, physically isolated environment. No inbound *or* outbound network. No mysterious third-party APIs phoning home. Just a server rack in a locked room running your task scheduler and some scripts. If you’ve gone to the trouble and expense of actual air-gapping, you’ve already addressed the primary threat model ephemeral credentials are meant to mitigate: credential exfiltration and misuse over a network.

In that scenario, what’s the real risk a short-lived credential solves that a well-secured, static service account doesn’t? The threat becomes a malicious insider with physical access or a catastrophic kernel exploit on the box itself. If an attacker has that level of access, your fancy credential rotation cron job is just another process they can intercept or subvert. You’ve added operational complexity—secret distribution, renewal logic, failure modes—for a threat it doesn’t meaningfully contain.

I’m not arguing against the principle of least privilege. That’s just good design. But the scope should be defined in the system’s access controls, not purely in the credential’s lifespan. A single, tightly scoped role or service account that can only write to one specific log directory or read from one queue is often safer than a complex, fragile renewal system that might break and take your automation offline. Sometimes the simplest, most auditable solution is the correct one, even if it’s not the most fashionable.