Identity Providers¶

Identity providers connect RunAgents to your authentication system. When configured, RunAgents validates JWTs from client applications at the ingress, extracts the user identity, and propagates it through the entire request chain -- from client to agent to tool. This enables per-user access control, audit logging, and OAuth consent flows.

Navigate to Identity in the sidebar, then click + New Identity Provider.

If you prefer to set this up from the terminal, you can manage the same resource with:

runagents identity-providers apply -f google-oidc.yaml
runagents identity-providers list
runagents identity-providers get google-oidc

Identity Provider Configuration¶

How Identity Propagation Works¶

Once an identity provider is configured, here is what happens when a client application sends a request to an agent:

sequenceDiagram
    autonumber
    participant Client as Client Application
    participant Ingress as RunAgents Ingress
    participant IdP as Identity Provider (JWKS)
    participant Agent as Agent Runtime
    participant Tool as External Tool API

    Client->>Ingress: Authorization: Bearer <JWT>
    Ingress->>IdP: Validate signature + issuer + audience
    IdP-->>Ingress: JWT verification result
    Ingress->>Ingress: Extract userIDClaim (email/sub/etc.)
    Ingress->>Agent: Forward request + X-End-User-ID
    Agent->>Tool: Tool API call + X-End-User-ID
    Tool-->>Agent: Response
    Agent-->>Client: Agent response

1. Client authenticates: The client application includes a JWT in the Authorization header.
2. JWT validation: RunAgents validates the JWT signature using the JWKS endpoint, checks the issuer and audience, and verifies the token has not expired.
3. User identity extraction: The configured userIDClaim (e.g., email) is extracted from the JWT.
4. Identity propagation: The extracted identity is set as the X-End-User-ID header and flows through the entire chain -- from the ingress to the agent to every tool the agent calls.

What Identity Providers Enable¶

Per-User Access Control¶

Tools and policies can reference user identities. For example, you can create a policy that allows only users from the engineering group to access the GitHub API, or restrict a specific user to read-only operations on a financial tool.

Per-User OAuth Consent¶

When an agent calls a tool with OAuth2 authentication, the consent flow is per-user. Each user grants their own authorization to the tool (e.g., granting access to their Google Drive). The platform stores per-user refresh tokens and uses them automatically on subsequent requests.

Audit Trail¶

Every tool call includes the authenticated user identity. This means audit logs can answer not just "which agent called Stripe?" but "which user's request caused that agent to call Stripe?"

Domain-Based Access Control¶

The Allowed Domains field lets you restrict which users can access your agents. For example, setting company.com ensures only @company.com email addresses are accepted, even if the JWT issuer serves tokens for other domains.

Common Identity Provider Configurations¶

Google Workspace¶

Example CLI file:

name: google-oidc
spec:
  host: portal.yourcompany.com
  identityProvider:
    issuer: https://accounts.google.com
    jwksUri: https://www.googleapis.com/oauth2/v3/certs
    audiences:
      - portal.yourcompany.com
  userIDClaim: email
  allowedDomains:
    - yourcompany.com

Microsoft Entra ID (Azure AD)¶

Auth0¶

Okta¶

Using Identity Providers During Agent Deployment¶

During the Wire step of the deploy wizard, you can choose an access mode for your agent:

• Open -- No authentication; any client can call the agent.
• Authenticated -- Requires a valid JWT from a registered identity provider. Select which provider to use.

When Authenticated is selected and only one identity provider is registered, it is auto-selected for convenience.

What's Next¶