Workload binding

When a managed agent forwards a request to another gateway or external service, the receiver has no inherent way to identify the original caller. It only sees a request arriving from the sending gateway. Without additional verification, the receiver must either accept the sender’s claims on trust or ignore caller identity entirely when evaluating access policies.

Workload Binding closes this gap by having the sending gateway attest the caller’s verified identity in a signed Verifiable Presentation on the outbound edge. A downstream gateway can verify the signature and expose the caller’s context to its own OPA policies as trusted, cryptographically attested input. See Transit Points in Surfaces →

Why it exists

In a single-gateway deployment, the gateway authenticates the caller directly and evaluates all policies with full knowledge of who is calling. When a deployment spans two gateways, a caller reaches GW1, which forwards through a Transit Point to GW2. GW2 only receives a request from GW1 and has no direct view of the original caller.

Without Workload Binding, GW2 cannot make caller-aware policy decisions. It cannot know whether the original caller came from an authorised department, whether they granted consent on GW1, or what attestation mode and identity source GW1 used. Any caller context sent in custom request headers is unverified and could be fabricated.

How it works

Workload Binding can be placed on two edges: on a Transit Point (MA → TP) or on the target leg (MA → External). On the target leg, caller context is always sourced from the inbound Authorization bearer JWT, as no transit token is available on that path.

When a request reaches a Transit Point configured with Workload Binding enabled, GW1:

1. Captures the caller’s context from the transit token (which carries claims gathered on the inbound path) or the bearer JWT presented at the Transit Point.
2. Builds a workloadBinding credential subject containing the caller’s context, GW1’s policy decisions, and the managed agent’s identity, embedded inside the outbound agent-identity-credential/v1 VP.
3. Signs the VP with GW1’s issuer key.
4. Injects the signed VP into the outbound request body before forwarding to the destination.

On the receiving gateway, GW2 extracts the VP from the forwarded request body and verifies the signature against GW1’s trusted issuer key. On successful verification, GW2 exposes the VP payload as structured OPA input at input.identity_binding. GW2’s OPA policies can then reference the original caller’s identity, attestation mode, identity source, and delegation flag.

If VP verification fails or no VP is present, input.identity_binding.verified is false and GW2’s policies can deny accordingly.

On a Transit Point, the G2G topology is required: the Endpoint Type must be set to via Gateway Connection (a fabric:// target) for the VP to reach another gateway for verification. On the target leg, the VP is attached to the outbound request regardless of the endpoint type.

What the VP contains

The credentialSubject.workloadBinding payload carries:

• Agent identity: the managed agent’s DID on GW1, establishing which surface the request originated from.
• Caller context: the caller’s identity claims (selected by the configured caller_context_fields allowlist), a hash of the caller’s identity, the attestation mode, and the identity source.
• Delegation flag: whether GW1 was acting for a caller. Set to true whenever caller context was bound, regardless of whether the Credential Delegation vault was used.
• Policy decisions: the OPA allow/deny decisions GW1 evaluated before forwarding. Present in the VP credential subject for audit and chaining, but not exposed in input.identity_binding on GW2.
• Trace ID: the request trace identifier for end-to-end correlation across both gateways.
• Target: the endpoint the request was forwarded to.

GW2 reads this as input.identity_binding in OPA:

Attestation modes

The VP carries one of two attestation modes in caller.assurance, determined by how the Transit Point is configured:

Gateway attested ("gateway_attested", default). GW1 attests the caller’s identity claims based on its own source-authentication verification. The caller’s credentials are not embedded in the VP itself. GW2 trusts GW1’s attestation.

Caller credential chained ("caller_credential_chained"). Embeds the caller’s own verifiable credential or presentation directly inside the VP, so GW2 can independently verify the full delegation chain without relying solely on GW1’s attestation. Enable this by turning on Chain caller-supplied credentials in the Workload Binding configuration on the Transit Point.

Relationship to caller context binding

Caller context binding and Workload Binding address separate problems and operate independently.

Caller context binding is the vault mechanism that scopes per-caller delegated credentials on any surface, with or without Transit Points or G2G routing.

Workload Binding is the VP attestation mechanism that attests the caller’s identity on an outbound edge. On a Transit Point, it requires a Gateway Connection target to carry the VP to another gateway for verification. On the target leg, it attaches to any outbound request.

When a surface has both Credential Delegation and a Workload Binding Transit Point, the VP includes the delegation action summary. GW2 receives not only who the original caller was but also whether they granted consent and which tokens were injected on GW1.

Use cases

Cross-gateway policy enforcement. A managed agent forwards requests to a partner network’s gateway. The partner’s OPA policies must verify that the caller came from an authorised department and already passed GW1’s identity checks. Workload Binding makes GW1’s caller attestation available as verifiable OPA input on GW2, without any out-of-band trust configuration.

Delegation propagation. A caller was identified on GW1 and their context was bound into the Workload Binding VP. GW2 needs to confirm that the request originated from an identified caller before permitting downstream tool calls. The VP’s delegated field carries this forward, allowing GW2 to gate decisions on whether GW1 acted for a caller.

End-to-end audit correlation. The VP’s trace ID links the full request chain (original caller, GW1, and GW2) in the audit log across both gateways. A single trace ID surfaces the complete call path for attribution and debugging.