Astrix's audit of more than 5,200 MCP servers found 53% relying on static keys or personal access tokens, and 79% passing that credential through environment variables. Two problems stacked: the credential never expires, and it lives somewhere that leaks easily.
Why environment variables are the worst place
Environment variables show up in process dumps, crash logs, diagnostic tool output, inspected container images and any child process that inherits the environment. They have no access control of their own — anyone running as that user reads everything.
Add to that the fact that a static key has no expiry: a credential leaked in 2025 is still valid today unless someone rotated it. Secret rotation in agent environments tends to get postponed precisely because it breaks the automation.
What federation changes
Instead of the workload holding a credential, it proves who it is. The execution environment issues a short-lived signed token — the Kubernetes service account, the provider metadata, the CI runner's OIDC — and the cloud provider exchanges that token for a scoped temporary credential.
- There is no key to leak, because there is no key.
- The credential expires in minutes, so a leak has a short window.
- Identity derives from context, so forging it requires compromising the environment, not copying a file.
- Rotation stops being a project and becomes default behaviour.
With no static key, half the attack playbook against agents loses its target.
What to do when the destination does not support it
Not every third-party API accepts federation. In those cases the goal shifts from eliminating to shortening: keep the secret in a secrets provider, inject it through a mounted file with restrictive permissions — not through the environment — and reduce the TTL to the minimum the API accepts. Then record that server as a known exception with a review date, so it does not become permanent through forgetfulness.
