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 and GCP 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<br/>The integration is attached to this VM<br/>Google trusts the exe.dev OIDC issuer<br/>The exe identity may impersonate the service account
Agent->>Auth: Make a BigQuery request
Note over Auth: Google auth loads the external account configuration<br/>and discovers the exe token endpoint
Auth->>Integration: Request an exe identity token
Note over Integration,Issuer: Request crosses from the VM<br/>into exe.dev
Integration->>Integration: Verify the VM is allowed<br/>to use this integration
Integration-->>Auth: Short-lived exe.dev OIDC token
Note over Auth,STS: The VM sends the exe identity token<br/>directly to Google Cloud
Auth->>STS: Exchange exe.dev OIDC token<br/>for a Google federated token
opt Google does not have the signing keys cached
STS->>Issuer: Fetch OIDC metadata and signing keys
Issuer-->>STS: Issuer metadata and signing keys
end
STS->>STS: Verify signature, issuer,<br/>audience, expiry, and subject
STS-->>Auth: Short-lived federated token
Auth->>IAM: Request an access token for<br/>the configured service account
IAM->>IAM: Verify the exe identity may<br/>impersonate the service account
IAM-->>Auth: Short-lived service account access token
Auth->>BigQuery: Call BigQuery with<br/>the service account access token
BigQuery-->>Auth: Query response
Auth-->>Agent: Return result