OAuth for Agents Exe has added support for Workload Identity Federation (WIF), allowing agents and workloads running on exe to access cloud resources without long-lived credentials. The integration, announced in a blog post, uses OAuth 2.0 token exchange to let an agent's identity be exchanged for short-lived access tokens from providers like AWS and GCP. This approach, inspired by Kubernetes' use of the API server as an identity provider, reduces the risk of credential leakage and improves auditability. Agents are unusually capable credential-handling tools. They read logs, execute commands, inspect files, call external services, and frequently operate on inputs that weren’t written by the person who deployed them. Giving an agent a long-lived secret means trusting not only the agent itself, but every tool it invokes, every file it reads, and every instruction it encounters, magnified by autonomous decision making. At exe, we believe agents should be able to access everything they need. That said, we do our best to avoid giving them persistent credentials that could leak. The safer model is to give the agent an identity and let it obtain narrowly scoped, short-lived access when it needs it. We’ve already built quite a few things around this idea, including our HTTPS proxy integration and our LLM integration, and recently we added support for Workload Identity Federation, or WIF. So what is WIF, and why is it a big deal? Years ago, back when I was working on Kubernetes, one of the most popular workflows users had was giving workloads running in k8s access to some cloud resource, say BigQuery. The typical solution up until that point was to create a service account, download its secret JSON file—which let you act as that service account—put it in a Secret in the k8s API, mount it into your pod, and then configure the cloud APIs to use it. It was a fairly suboptimal user experience. The secret had to be long-lived, could be leaked, needed to be rotated periodically, and there was really no way to know who or what was using it. Sounds familiar Then the great security engineers working on Kubernetes realized that, by adding a few features to GCP and Kubernetes, they could use the Kubernetes API server as a trust boundary by having it act as an identity provider. In some ways, it already was one: the secrets were stored there, it already had a concept of service accounts, and it knew which workload was running as which identity. It worked by letting pods ask the k8s API server for a signed token or JWT , which could then be presented to GCP to impersonate a service account. GCP would confirm that the k8s API server had signed it and that the cluster was within the configured trust boundary. If everything was configured correctly, your Kubernetes pods could now magically act as a GCP service account without ever being given a long-lived GCP credential. As a bonus, you could know exactly which pod was accessing which resources. Under the hood, this uses a lesser-known OAuth 2.0 flow called token exchange . One system issues a cryptographically signed token asserting who you are, and another system decides whether it trusts that issuer and is willing to exchange that token for one of its own. The method quickly spread, and all the major clouds shipped some version of it. Things like GitHub Actions adopted it too, letting you use GitHub’s identity to access cloud resources instead of storing long-lived cloud credentials. The new exe WIF integration follows suite and allows an agent or workload running on exe to use its identity to access resources on any cloud, or really anywhere, without needing a long-lived credential sitting around inside the VM. It is the same basic idea Kubernetes arrived at years ago: give the workload an identity, establish trust between systems, and mint short-lived access when it is actually needed instead of copying secrets everywhere. To use it in exe, go to the integrations page and create a new Identity Federation integration. You can then attach it to tags or individual VMs. You’ll need to configure the resource provider GCP, AWS, etc to consume the credentials. We have some guides for AWS https://exe.dev/docs/integrations-aws-wif and GCP https://exe.dev/docs/integrations-gcp-wif already and more are coming soon. We would love to hear which services you would use this with and how we could improve the experience. Bonus - sequence diagram sequenceDiagram autonumber box Inside the exe VM actor Agent as Agent or workload participant Auth as Google auth library end box exe.dev participant Integration as Attached WIF integration participant Issuer as exe.dev OIDC issuer end box Google Cloud participant STS as Google STS participant IAM as IAM Credentials API participant BigQuery as BigQuery end Note over Integration,BigQuery: One-time setup