Agent Gateway

Outbound binding elements

Field reference for the Credential Delegation and Workload Binding canvas elements: attaching cached OAuth or API key tokens to outbound calls, and binding managed-agent identity and caller context into outbound Verifiable Presentations.

Two canvas elements bind outbound context to upstream requests. Credential Delegation injects cached OAuth or API key tokens from a credential provider into calls on the caller’s behalf. Workload Binding binds the managed-agent identity and selected caller-context claims into the outbound Verifiable Presentation injected on an outbound edge.

Credential Delegation

The Credential Delegation element binds external credential providers (OAuth, API key) to a surface so the gateway attaches cached tokens to outbound calls on the caller’s behalf. When no token is held for a given caller, the gateway signals consent_required back rather than forwarding the request.

Drop it on the Managed Agent → External request edge. One element per surface (singleton).

Fields

Each row in the outbound credential binding list configures one credential provider.

FieldTypeRequiredDefaultDescription
Credential ProviderselectYes—The credential provider supplying the token. Select from providers on the Credential Providers tab of the Credentials page.
ScopesstringNo—Space- or comma-separated OAuth scopes to request when acquiring a token for the caller.
Consent ModeselectNoOn demandHow the gateway handles a missing token. Options: On demand (signals consent_required back to the caller), Pre-authorize (blocks the request until consent is granted), Elicit (sends an MCP elicitation prompt to the caller). A binding set up through the API shows External consent (set through the API) and is read-only. See External consent.
Elicit timeout (seconds)integerYes (when Consent Mode = Elicit)300Seconds to wait for the caller to complete the elicitation prompt. A declined, cancelled, or timed-out prompt refuses the tool call with 503 and JSON-RPC error -32603.
Fallback when client doesn’t support elicitationselectYes (when Consent Mode = Elicit)On demandWhat the gateway does when the caller does not support elicitation. Options: On demand (signal consent_required), which falls back to the On demand flow, and Fail (return not_applicable), which refuses the tool call with 503 and JSON-RPC error -32603. Under Fail, a prompt that can’t be delivered, for example because the client has no open stream, is refused the same way.
Required ForselectNoAll outbound requestsWhich requests trigger credential injection. Options: All outbound requests, Specific MCP tools only. See Where each binding applies.
Tool namesstringYes (when Required For = Specific MCP tools only)—Comma-separated MCP tool names, entered in the field shown below Required For. The gateway injects the credential only on a tools/call that names one of these tools.
Inject AsselectNoBearer headerHow the token is attached to the outbound request. Options: Bearer header (Authorization: Bearer <token>), Custom header (a named HTTP header), JSON-RPC _meta (a field in the JSON-RPC _meta object).
Header namestringYes (when Inject As = Custom header)—The HTTP header name to write the token into.
Header formatstringNo (when Inject As = Custom header)token {value}Template for the header value. {value} is replaced with the token at injection time.
Meta field namestringYes (when Inject As = JSON-RPC _meta)—The _meta field name to write the token into.

Where each binding applies

A binding carries no destination, so where it applies depends on the hop the request takes:

  • Requests to the surface’s Target: every binding applies. A Specific MCP tools only binding applies to a tools/call that names one of its tools, and to no other MCP method.
  • Requests this surface receives over Fabric from a connected gateway: the same rule applies, because a receiving surface forwards only to its own Target.
  • Requests through a Transit Point: All outbound requests bindings apply, and tool-scoped bindings (Specific MCP tools only) stay with the Target, because a partner upstream names its own tools and a matching name could belong to a different tool. Every Transit Point on the surface receives each All outbound requests binding, so use that setting only when every Transit Point’s upstream should hold the credential.

The surface’s Target uses these bindings alone, and each Transit Point’s own credential stays with that Transit Point. For how a Transit Point uses its own Inject outbound credential setting, see Transit Points.

A Transit Point that receives a binding refuses a request with 403 when it has no agent identity or when the transit token names no caller. See Requirements for a Transit Point with delegated credentials.

An external consent binding takes its grants from another system that runs the consent flow, so it is created through the API. In the element it shows read-only, with External consent (set through the API) as its Consent Mode. On a surface’s Target it must be the only binding, on a surface without Transit Points. Changing or removing the binding revokes its grants.

Credential that cannot be resolved

When a binding applies but its credential cannot be resolved, the gateway refuses the request with 503 instead of forwarding it without the credential. This happens when the credential provider is deleted or cannot be read, an API key secret cannot be read, a client credentials token request fails, the stored token cannot be read, or consent cannot be asked for. On an MCP surface the refusal is a JSON-RPC error with code -32603 and the message Delegated credentials unavailable. On other surfaces it is a problem JSON body with the same message.

Delegated credentials over Fabric

When the Target or a Transit Point routes to a connected gateway (via Gateway Connection), the delegated access token reaches the remote gateway only when Send delegated credentials over Fabric is on for that route. The switch is off by default and is set per route, on the Managed Agent panel for the Target and on each Transit Point. With it off, the remote gateway receives no delegated credential. The refresh token always stays on this gateway.

Workload Binding

The Workload Binding element binds the managed-agent identity and a chosen set of caller-context claims into the outbound Verifiable Presentation (agent-identity-credential/v1) injected on an outbound edge. A downstream Agent Gateway can then verify which workload is acting and on whose behalf it is acting.

Drop it on a Managed Agent → Transit Point or Managed Agent → External edge. Each Transit Point or target leg can carry its own Workload Binding configuration. For setup steps, see Bind caller identity to your agent’s outbound calls.

Fields

FieldTypeRequiredDefaultDescription
Enable workload bindingboolNoOnActivates the binding for this Transit Point or target leg. When off, no VP is injected.
Caller context sourceselectNoTransit tokenWhere caller claims are read from. Options: Transit token (claims from the signed transit token presented to this Transit Point), Authorization bearer JWT (claims from the inbound Authorization: Bearer JWT), DID authentication (the resolved DID from a DID-authenticated session becomes the caller identity; requires the Caller Context element on this surface to use the DID Auth method). On the MA → External leg, Transit token is not offered since there is no transit token on that leg; the choice there is between Authorization bearer JWT and DID authentication.
Caller field allowliststring[]No[]Top-level caller claim names copied into the binding VP. Only listed names cross the boundary. Leave empty to bind no caller claims. Nested paths (a.b) are not supported.
Chain caller-supplied credentialsboolNoOffWhen on, a caller-presented VC or VP is chained into the binding VP so the downstream gateway sees the full delegation chain.