Workload binding

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

Workload Binding closes this gap by having the sending gateway attest the caller’s verified identity in a signed Verifiable Presentation at the Transit Point. The receiving gateway verifies the signature and exposes 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 policy decisions GW1 already made. Any caller context sent in custom request headers is unverified and could be fabricated.

How it works

Workload Binding is configured on individual Transit Points, not on the surface root.

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, consent status, attestation mode, and GW1’s policy decisions.

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

Workload Binding requires the G2G topology. The Transit Point’s routing must be set to Gateway Connection (a fabric:// target). On a surface without a Transit Point, or where the target is a direct HTTPS endpoint, the feature has no effect.

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 status: whether credential delegation was active and what delegation actions occurred.
• Policy decisions: the OPA allow/deny decisions GW1 evaluated before forwarding.
• 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 carries the caller’s identity across a gateway hop. It requires a Transit Point configured with a Gateway Connection target.

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 granted consent on GW1 and had OAuth tokens injected for an outbound call. GW2 needs to know this occurred before permitting downstream tool calls. The VP’s delegated field carries this forward, allowing GW2 to gate decisions on whether consent already occurred upstream.

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.