Ask any security engineer what the worst kind of credential is, and they'll tell you: the one that's shared, long-lived, and whose owner is a group chat rather than a person. Now hand that exact profile of credential to something that runs at 3am, retries on failure, and has no Slack account to notice when things go wrong. That's a static API key sitting in an agent's config file, and it is quietly the riskiest thing on most AI platforms today.
Humans Are a Terrible but Necessary Compensating Control
Every credential-management story you've ever heard - "the key leaked, but we caught it because someone noticed weird activity and rotated it" - relies on a human noticing. Humans notice slow logins, unfamiliar IP addresses, a Slack DM from security asking "hey, was this you?" They notice because they are the thing the credential represents.
An autonomous agent has none of that. It doesn't get suspicious when it's asked to do something unusual - it does the thing, because doing things is its job. It doesn't post in a channel when its key stops working - it just fails silently, or worse, retries in a loop that looks like a denial-of-service attack against your own infrastructure. And when a leaked static key gets used by an attacker at 3am, there is no human awake to think "that's odd."
This is the core argument for giving every autonomous agent its own federated machine identity rather than a shared static secret: the entire security model that static keys depend on - a human eventually noticing - doesn't apply.
Federation, Not Secrets
The alternative isn't "encrypt the key better" or "rotate it more often by hand." It's removing the long-lived secret from the picture entirely. A federated identity works by letting the agent's own already-trusted platform identity (its workload identity, its service account, whatever your infrastructure calls it) be exchanged for a short-lived, cloud-native credential - issued by the cloud provider itself, scoped tightly, and expiring on the order of minutes to hours.
Nothing long-lived is stored anywhere. There's no .env file with a key that, if it leaks, is valid until someone remembers to rotate it. The trust anchor is the platform's own identity infrastructure, which is exactly the thing you're already protecting with everything else.
The Google side vs. the Azure side (callback to post 2 in this series, where we forked the whole platform on this question): on Google Cloud, this is Workload Identity Federation - an external or on-platform identity gets mapped to a short-lived Google-issued credential via a trust configuration, no service account key file involved. On Azure, the equivalent is Workload Identity Federation paired with Managed Identity - a workload gets an identity from Entra ID directly, and downstream Azure services trust it natively without any credential ever being generated, stored, or passed around at all. Different plumbing, same principle: the agent proves who it is, not what secret it's holding.
Rotation Without a Window
Federated identity solves the "long-lived secret" problem. But even short-lived credentials need to be refreshed, and refresh is exactly where naive implementations create a new failure mode: revoke the old credential, then issue the new one, and hope nothing tries to use the agent in the gap between those two steps.
The fix is make-before-break rotation: issue and validate the new credential before revoking the old one. For a window, both are valid. Only once the new credential is confirmed working does the old one get torn down.
Break-before-make - revoke first, issue second - is tempting because it's simpler to reason about and there's a brief moment where it looks more secure (never two valid credentials at once!). But it guarantees a window where the agent has no valid credential, and if that window lands during an active task, you get a failure that's much harder to explain than "the credential was rotated slightly early."
A Small, Concrete Example
Imagine a mid-sized retailer running an overnight agent that reconciles inventory discrepancies across regional warehouses. It runs unattended, starting around 1am when transaction volume is lowest. If its credential is a static key embedded in a config map, that key is now the single most attractive target in the whole pipeline - valid indefinitely, used by something nobody's actively supervising, running at exactly the hour when anomalous activity is least likely to be noticed by anyone.
Swap that for a federated identity with automatic make-before-break rotation, and the attractive target disappears. There's no key to steal, because there was never a key - just a chain of trust that traces back to infrastructure the security team already monitors, refreshed on a schedule the agent never even has to know about.
Where We Went Back and Forth
We debated the fallback question longer than we expected to. There's a real argument for a degraded-but-working mode when the federated path is unavailable - availability matters too, and "fail the task" has its own cost if it happens often. We ultimately chose to fail closed rather than fall back to a static key, but we're not fully certain that's right for every workload, especially latency-sensitive ones where a failed task is expensive to retry. If you've built a fallback path you trust, we'd like to hear how you scoped it so it doesn't become the de facto credential.
A Few Things Worth Watching For
We'd steer away from leaving a static key as a literal fallback for the federated path - in our experience it tends to become the path of least resistance rather than a rare safety net, which quietly reintroduces the exact risk profile you were trying to eliminate.
Scoping the federated credential broadly "to be safe" is another one we'd caution against - the whole benefit of short-lived, federated credentials is that a leak is self-limiting, and broad scope trades that away for configuration convenience.
And it's worth double-checking that rotation is actually make-before-break rather than assumed to be, just because the cloud provider issues short-lived credentials. The provider issuing short-lived credentials doesn't automatically give you that overlap window - that's an integration decision your platform has to make deliberately, in how and when it requests a refreshed credential relative to expiry.
Getting an agent's own identity right helped us a lot, but it wasn't sufficient on its own - an agent also needs to act as the user who asked it to do something, not just as itself. That's the next post's whole argument, and it's one we're still refining too.
Suggested hashtags: #EnterpriseAI #AIInfrastructure #AIPlatform #AIGovernance #PlatformEngineering #ZeroTrust #WorkloadIdentity #IAM #CloudSecurity