Eliminating Secrets: How We Grant Cloud Agents Production Access via OIDC

By Aditya Saligrama, Software Engineer | October 23, 2026

At Formal, we have a very specific stance on security: we tolerate secrets we hate secrets.

"Our overarching mission since inception has been to systematically eliminate long-lived secrets from our entire infrastructure."

To ensure our product reflects this internal philosophy, we developed OIDC Integrations. This system allows any machine-based workload to authenticate with Formal using its own native infrastructure identity, with the optional ability to attest to a specific human's identity during the process.

While this is great for CI/CD, we've discovered it is a powerhouse for enabling AI agents. Modern coding agents (such as Devin or Cursor) act as OIDC issuers. By leveraging this, we can grant them read-only, policy-governed, and fully auditable access to our production environments and cloud data.

---

Understanding OpenID Connect (OIDC)

For those needing a refresher, the OIDC flow for machine workloads is designed to replace static keys with short-lived tokens. The primary goal is to get a temporary token from an Identity Provider (IdP) and present it to a Relying Party (RP).

The Technical Workflow

1. Token Acquisition: The workload retrieves an OIDC JWT (JSON Web Token) from its environment.
   • Environment Variables: Common in GitLab or GitHub.
   • Metadata Endpoints: Common in AWS, Azure, or GCP.
2. Scoping: To prevent "token replay" attacks across different services, the token is typically scoped to the RP using the aud (Audience) claim.
3. Presentation: The workload calls the RP's API, passing the token in the header: Authorization: Bearer <token>.
4. Verification: The RP fetches the public key from the IdP's JWKS endpoint (e.g., https://idp.com/.well-known/openid-configuration) to verify the JWT's signature.
5. Validation: The RP checks the signature and examines specific claims to ensure the identity is valid, which is critical since most IdPs are multi-tenant.
6. Mapping: The RP maps these claims to a specific machine identity within its own system.

OIDC Architecture Visualization

---

The "Formal" Implementation

We've extended the standard OIDC flow with several advanced features to increase granularity:

• CEL Conditions: Customers can write Common Expression Language (CEL) logic to determine if a token is allowed to authenticate.
• Granular Permissions: OIDC claims are passed directly into our Permissions engine, allowing for highly specific authorization rules.
• Federation Tokens: Callers can hit the CreateFederationToken endpoint. This generates a short-lived Connector access token that carries the original OIDC claims.

Why this matters: Workloads can use the Connector as a proxy to inject credentials without ever storing a long-lived secret themselves.

Compatibility Matrix

---

Attesting to Human Identity

Usually, an OIDC integration maps to one machine user. However, many workloads are "proxies" for humans (e.g., a CI job triggered by a developer or an agent launched via Slack).

The Trust Model

We distinguish between two types of identity:

1. Machine Identity: Cryptographically proven and verified by Formal.
2. Human Identity: Asserted by the workload.

We trust the human identity claim because the customer explicitly configures Formal to trust the asserting system.

From BI Tools to AI Agents

This pattern was originally designed for Business Intelligence (BI) tools like Metabase.

• The Problem: Metabase uses one database credential, but different humans need different data access.
• The Solution: Metabase asserts the logged-in human's identity to Formal, which then evaluates the policy.

This fits cloud agents perfectly. An agent platform cannot create a unique credential for every single human user. Instead, it issues a signed token stating:

• The specific agent session.
• The repository being accessed.
• The human who initiated the task.

$\text{Trust}(\text{Agent Platform}) \implies \text{Trust}(\text{Human Identity Claim})$

---

Dogfooding our Infrastructure

We apply these exact patterns to our own production environment. Our setup includes:

• Production Access: A Connector guarding our S3 buckets, log clusters, and production databases.
• Local Control: The Formal Endpoint monitors agent activity on our engineers' laptops.
• Infrastructure as Code: Our production tenant's control plane is managed entirely via Terraform.

Our "Zero Secret" Checklist

• Implement OIDC for CI/CD
• Enable Human Identity Propagation
• Integrate SPIFFE/SPIRE
• Migrate Production DB access to Connector
• Eliminate all remaining legacy static keys

// Example of a claim-based policy check
{
  "condition": "token.claims.repo == 'formal/formal' && token.claims.user_team == 'infra'",
  "action": "allow",
  "resource": "prod-db-read"
}