Workload identity tokens (WIMSE)

Use WIMSE Workload Identity Tokens with agentgateway to authenticate service-to-service and egress traffic in your ambient mesh.

WIMSE (Workload Identity in Multi-System Environments) is an IETF working group that defines standards for carrying workload identity across system boundaries. The core problem it addresses is that mTLS-based identity (SPIFFE/X.509) is scoped to a single connection. When a workload makes an outbound HTTP call to an external service or crosses a trust boundary, the originating workload’s identity is not automatically carried with the request. WIMSE defines the Workload Identity Token (WIT), a structured token format that encodes workload identity claims so they can travel as an HTTP header (Workload-Identity-Token) alongside the request, independently of the underlying transport security.

Solo Enterprise for Istio 1.30 adds WIMSE WIT support for agentgateway waypoints. When agentgateway is deployed as a waypoint proxy, it can extract workload identity claims from the mTLS peer certificate SAN, expose those claims in CEL policy expressions, and forward or exchange the WIT for outbound requests to external services.

This feature requires agentgateway as a waypoint proxy. For setup, see Install agentgateway as a waypoint.

How it works

The trust chain involves three components working together:

1. Istiod embeds workload identity claims in the certificate SAN when it mints workload certificates.
2. Ztunnel reads those SAN claims for L4 policy and forwards the WIT header on outbound HBONE connections.
3. Agentgateway extracts the claims at L7 from the peer TLS certificate SAN and exposes them in CEL policy expressions.

Inbound policy with workload claims

When agentgateway receives a request, it extracts workload identity claims from the peer certificate and makes them available to EnterpriseAgentgatewayPolicy expressions as CEL attributes:

These attributes are available in EnterpriseAgentgatewayPolicy expressions targeted at a Gateway, HTTPRoute, or Service.

Enable workload claims on the waypoint proxy

• Ztunnel: Set ENABLE_WORKLOAD_CLAIMS=true in your ztunnel Helm values. For setup instructions and ztunnel-level enforcement of the same claims, see CEL and workload claims authorization for L4 traffic.
• Agentgateway waypoint proxy: Enable workload claims on the waypoint proxy by using EnterpriseAgentgatewayParameters. Without this reference, source.claims is never populated, and all claims-based authorization expressions evaluate to false.

To enable workload claims on the agentgateway waypoint proxy, create an EnterpriseAgentgatewayParameters resource and reference it from your waypoint Gateway.

1. Create the EnterpriseAgentgatewayParameters resource.

   apiVersion: enterpriseagentgateway.solo.io/v1alpha1
   kind: EnterpriseAgentgatewayParameters
   metadata:
     name: waypoint-params
     namespace: ${NAMESPACE}
   spec:
     workloadClaims:
       enabled: true

2. Reference the parameters from your waypoint Gateway.

   spec:
     infrastructure:
       parametersRef:
         group: enterpriseagentgateway.solo.io
         kind: EnterpriseAgentgatewayParameters
         name: waypoint-params

The following EnterpriseAgentgatewayPolicy example combines workload claims with JWT validation to allow requests only when the source workload carries the eu jurisdiction claim and the end-user JWT subject ends with @example.com.

apiVersion: enterpriseagentgateway.solo.io/v1alpha1
kind: EnterpriseAgentgatewayPolicy
metadata:
  name: upstream-authz
  namespace: ${NAMESPACE}
spec:
  targetRefs:
  - group: gateway.networking.k8s.io
    kind: Gateway
    name: <gateway_name>
  traffic:
    authorization:
      action: Allow
      policy:
        matchExpressions:
        - 'jwt.sub.endsWith("@example.com") && source.claims["solo.io.security-claims.jurisdiction"] == "eu"'

Workload identity propagation

To carry workload identity claims on outbound requests, configure backend.workloadIdentity in an EnterpriseAgentgatewayPolicy. Target the policy at a Service when you don’t need routing rules, or at an HTTPRoute when you do. These modes control the Workload-Identity-Token HTTP header sent to the upstream service. The mTLS identity of the outbound HBONE connection always uses agentgateway’s own workload certificate and is not affected by this setting.

SourceDelegation

Forwards the inbound Workload-Identity-Token from the source workload to the upstream service. Use this when the upstream service needs to verify the source workload’s identity independently, for example when calling an in-mesh service or an external API that accepts WIMSE tokens.

apiVersion: enterpriseagentgateway.solo.io/v1alpha1
kind: EnterpriseAgentgatewayPolicy
metadata:
  name: forward-wit
  namespace: ${NAMESPACE}
spec:
  targetRefs:
  - kind: Service
    name: <svc_name>
    group: ""
  backend:
    workloadIdentity:
      mode: SourceDelegation

SelfIdentification

Uses agentgateway’s own WIT as the outbound identity rather than delegating the source workload’s identity. Use this when the upstream should authorize the gateway as the caller, not the original source workload. If agentgateway has no minted WIT available, it logs a warning and sends no Workload-Identity-Token header on that request.

apiVersion: enterpriseagentgateway.solo.io/v1alpha1
kind: EnterpriseAgentgatewayPolicy
metadata:
  name: self-identification
  namespace: ${NAMESPACE}
spec:
  targetRefs:
  - kind: Service
    name: <svc_name>
    group: ""
  backend:
    workloadIdentity:
      mode: SelfIdentification

JWT propagation for end-user identity

WITs carry workload identity and identify the calling service, not an end user or external application. When external callers present an OIDC or OAuth2 bearer JWT (for example, from Keycloak, Entra ID, or a cloud identity provider), that is a separate identity layer that requires different handling. For this identity layer, you can add JWT validation in addition to WIT.

When agentgateway is deployed as a waypoint, it can validate inbound JWTs and make claims from the validated token available in EnterpriseAgentgatewayPolicy CEL expressions, alongside the workload identity claims in the claims map. This lets you combine both layers in a single policy: enforce that the source workload is a trusted service account (WIT) and that the end-user token carries the expected role or scope (JWT).

JWT passthrough: By default, agentgateway forwards the inbound Authorization header to the upstream service. No additional policy is needed if you only want to pass the token through for the upstream to validate independently.

JWT validation and claim-based policy: To validate JWTs at the waypoint and use their claims in authorization decisions, configure JWT validation in agentgateway with a JWKS endpoint. For configuration steps, see the agentgateway JWT authentication documentation.

JWT token exchange: To exchange an inbound JWT for a different credential before forwarding (for example, to call a downstream service that requires a different issuer or token format), configure backend.tokenExchange in an EnterpriseAgentgatewayPolicy. The inbound JWT can serve as the subject_token passed to the STS.