OAuth for Agents - exe.dev blog

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<br>autonumber

box Inside the exe VM<br>actor Agent as Agent or workload<br>participant Auth as Google auth library<br>end

box exe.dev<br>participant Integration as Attached WIF integration<br>participant Issuer as exe.dev OIDC issuer<br>end

box Google Cloud<br>participant STS as Google STS<br>participant IAM as IAM Credentials API<br>participant BigQuery as BigQuery<br>end

Note over Integration,BigQuery: One-time setupThe integration is attached to this VMGoogle trusts the exe.dev OIDC issuerThe exe identity may impersonate the service account

Agent->>Auth: Make a BigQuery request

Note over Auth: Google auth loads the external account configurationand discovers the exe token endpoint

Auth->>Integration: Request an exe identity token

Note over Integration,Issuer: Request crosses from the VMinto exe.dev

Integration->>Integration: Verify the VM is allowedto use this integration<br>Integration-->>Auth: Short-lived exe.dev OIDC token

Note over Auth,STS: The VM sends the exe identity tokendirectly to Google Cloud

Auth->>STS: Exchange exe.dev OIDC tokenfor a Google federated token

opt...