OAuth for Agents

The core problem exe.dev is addressing is specific to autonomous agents, not generic workloads. An agent reads logs, executes commands, inspects files, and calls external services, often operating on inputs that were not written by the person who deployed it. Giving such a system a long-lived secret means trusting not just the agent but every tool it invokes, every file it reads, and every instruction it encounters, all magnified by autonomous decision-making. A leaked static credential in this context is not a single-service compromise; it is a credential that an autonomous system can use to chain access across multiple resources.

The solution exe.dev shipped is Workload Identity Federation, which uses an OAuth 2.0 flow called token exchange. One system issues a cryptographically signed token asserting identity, and another system decides whether it trusts that issuer and exchanges that token for one of its own. In practice, an agent running in an exe VM requests an exe identity token, exe verifies the VM is allowed to use the attached WIF integration, returns a short-lived OIDC token, and the agent presents that token directly to the target cloud's STS endpoint to obtain a federated access token. No long-lived cloud credential ever exists inside the VM.

This pattern is not new. It originated in Kubernetes, where pods were historically given GCP service account JSON keys stored as Kubernetes Secrets. The Kubernetes API server was then repurposed as an identity provider, signing JWTs that GCP would validate and exchange for service account impersonation. The approach spread to all major clouds and to GitHub Actions, which lets workflows use GitHub's identity to access cloud resources without stored secrets. exe.dev is applying the same architecture to agents, treating the exe platform as the trust boundary and OIDC issuer rather than a Kubernetes control plane.

Adoption cost is split across two systems. On the exe side, an operator creates an Identity Federation integration from the integrations page and attaches it to tags or individual VMs. On the cloud provider side, the resource provider (GCP, AWS, or others) must be configured to consume the federated credentials, which means establishing trust in the exe.dev OIDC issuer and granting the exe identity permission to impersonate a service account. exe has published guides for AWS and GCP, with more providers planned. The configuration is one-time per integration, but each new cloud provider or service account requires its own trust setup.

Where this stops working is at the boundary of what the token exchange flow can express. The agent must be running on exe with the integration attached, and the target system must support OIDC-based workload identity federation. Services that only accept static API keys or username-password authentication cannot participate. The scoping is also only as narrow as the cloud-side IAM configuration permits; if the impersonated service account has broad permissions, the short-lived token inherits that breadth. The model reduces credential leakage risk but does not eliminate the need for least-privilege IAM design on the cloud side.