{"slug": "oauth-for-agents", "title": "OAuth for Agents", "summary": "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.", "body_md": "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.\n\nGiving 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.\n\nAt 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.\n\nThe 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.\n\nSo what is WIF, and why is it a big deal?\n\nYears 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.\n\nThe 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.\n\nIt 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.\n\nSounds familiar!\n\nThen 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.\n\nIn 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.\n\nIt 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.\n\nIf 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.\n\nUnder 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.\n\nThe 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.\n\nThe 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.\n\nIt 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.\n\nTo 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.\n\nYou’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.\n\nWe would love to hear which services you would use this with and how we could improve the experience.\n\n## Bonus - sequence diagram\n\n```\nsequenceDiagram\n    autonumber\n\n    box Inside the exe VM\n        actor Agent as Agent or workload\n        participant Auth as Google auth library\n    end\n\n    box exe.dev\n        participant Integration as Attached WIF integration\n        participant Issuer as exe.dev OIDC issuer\n    end\n\n    box Google Cloud\n        participant STS as Google STS\n        participant IAM as IAM Credentials API\n        participant BigQuery as BigQuery\n    end\n\n    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\n\n    Agent->>Auth: Make a BigQuery request\n\n    Note over Auth: Google auth loads the external account configuration<br/>and discovers the exe token endpoint\n\n    Auth->>Integration: Request an exe identity token\n\n    Note over Integration,Issuer: Request crosses from the VM<br/>into exe.dev\n\n    Integration->>Integration: Verify the VM is allowed<br/>to use this integration\n    Integration-->>Auth: Short-lived exe.dev OIDC token\n\n    Note over Auth,STS: The VM sends the exe identity token<br/>directly to Google Cloud\n\n    Auth->>STS: Exchange exe.dev OIDC token<br/>for a Google federated token\n\n    opt Google does not have the signing keys cached\n        STS->>Issuer: Fetch OIDC metadata and signing keys\n        Issuer-->>STS: Issuer metadata and signing keys\n    end\n\n    STS->>STS: Verify signature, issuer,<br/>audience, expiry, and subject\n    STS-->>Auth: Short-lived federated token\n\n    Auth->>IAM: Request an access token for<br/>the configured service account\n    IAM->>IAM: Verify the exe identity may<br/>impersonate the service account\n    IAM-->>Auth: Short-lived service account access token\n\n    Auth->>BigQuery: Call BigQuery with<br/>the service account access token\n    BigQuery-->>Auth: Query response\n\n    Auth-->>Agent: Return result\n```\n\n", "url": "https://wpnews.pro/news/oauth-for-agents", "canonical_source": "https://blog.exe.dev/oauth-for-agents", "published_at": "2026-08-11 13:00:00+00:00", "updated_at": "2026-08-11 13:24:33.963313+00:00", "lang": "en", "topics": ["ai-agents", "ai-infrastructure", "ai-safety"], "entities": ["exe", "Kubernetes", "GCP", "AWS", "BigQuery", "GitHub Actions"], "alternates": {"html": "https://wpnews.pro/news/oauth-for-agents", "markdown": "https://wpnews.pro/news/oauth-for-agents.md", "text": "https://wpnews.pro/news/oauth-for-agents.txt", "jsonld": "https://wpnews.pro/news/oauth-for-agents.jsonld"}}