Giving Cloud Agents Production Access with OIDC, Not Secrets

At Formal, we hate secrets. Since day one, we’ve been on a quest to drive the number of long-lived secrets in our infrastructure to zero.We want our product and the way our customers interact with it to reflect that philosophy, too. Accordingly, we built OIDC Integrations a few months ago: a way for arbitrary machine workloads to authenticate to Formal on the strength of their own infrastructure identity, and optionally attest a human identity along the way.Beyond product and CI/CD workloads, we’ve also found that supporting OIDC has been extremely useful for enabling agents to do more in our infrastructure. Cloud coding agents like Cursor and Devin themselves are OIDC issuers, which means that we can now give them auditable, policy-controlled, read-only access through Formal to our production data and cloud infrastructure.OpenID Connect (OIDC)For a brief refresher, an OIDC authentication flow works as follows for machine workloads. The goal is to obtain a short-lived token from the workload’s identity provider (IdP) and use it as proof of identity on an external service, known as the relying party (RP). The relying party is usually preconfigured with knowledge about the IdP.The workload obtains its OIDC JWT token from its environment. Sometimes this is provided as an environment variable (e.g., GitHub, GitLab); sometimes the workload needs to retrieve it by making an API call to a metadata endpoint (e.g., AWS, GCP, Azure). Typically, the token is scoped to the RP (e.g., by setting the Audience aud claim) to prevent token reuse across different RPs.The workload makes an API call to the RP, using the obtained OIDC token as a bearer token (i.e., Authorization: Bearer eyJ...).The RP looks up the JWKS endpoint (usually something like https://idp.com/.well-known/openid-configuration) from its configuration and obtains the IdP’s public key to verify the JWT with.The RP verifies the JWT is signed with the IdP’s private key. The RP also checks some of the claims embedded in the JWT as an authentication condition — which is important, because IdPs are typically multi-tenant. These claims are also typically used to map the incoming identity to a machine identity on the RP.If all checks pass, the API call is allowed to proceed. Sometimes, additional authorization conditions are applied to API calls that are authenticated via OIDC.OIDC at FormalOur OIDC integrations follow the above flow, with a few key additional details:Customers can specify a CEL condition for each integration, where a given token is only allowed to authenticate if that condition evaluates to true. Additionally, OIDC claim fields are also surfaced as inputs to Permissions, such that customers can define more granular authorization conditions for specific control plane API requests.One endpoint that OIDC-authenticated callers can call is CreateFederationToken, which returns a short-lived Connector access token that embeds the source OIDC claim fields. This means that workloads can use the Connector as a credential-injecting proxy without needing to store long-lived credentials themselves.SPIFFE workloads work natively too: Formal verifies JWT-SVIDs from SPIRE like any other OIDC token, with the SPIFFE ID available to Policies and Permissions.OIDC can also be used to authenticate the Formal Endpoint and Kubernetes Egress Agent.Attesting human identityEvery OIDC integration maps to a single machine user. This is a good default model for most traditional machine workloads; however, many workloads we care about don’t act on their own behalf. For example, CI jobs can usually be attributed to a human that pushed a commit, and cloud agents are often run because someone kicked one off from Slack. As such, each integration can optionally define a token claim that Formal resolves to a human identity which appears in logs and as input to policies.The two identities involved here come with different kinds of trust. Formal can cryptographically authenticate the machine identity, but the human identity is only asserted by the downstream workload. We accept that claim because our customer trusts the system making it, and explicitly configures Formal to trust it too.We’ve supported this shape since day one, but for a very different use case: many of our customers use Formal to control database traffic between business intelligence (BI) tools and their data sources. Tools like Metabase can only use one credential per database, but customers often differentially enforce controls based on the human user logged into Metabase. We originally built end-user identity propagation as a way to allow Metabase to assert the human identity to database queries and let Formal evaluate policies against it.That pattern turns out to fit cloud coding agents almost perfectly, especially multiplayer ones that a whole team shares and anyone can launch from Slack, Linear, or GitHub.

Our customers already trust their agent platform to make that statement, just as they trust Metabase to report who is logged in.