Caller context binding
When multiple callers share an AI agent surface, the gateway must identify which caller is making each request at the moment of every outbound call. Without this, it cannot determine whose delegated credentials to inject, and one caller’s access token could be silently reused for another caller’s request.
The gateway solves this through a three-part composite key that uniquely scopes every delegation context. The key combines the agent’s stable cryptographic identifier, a privacy-preserving hash of the caller’s identity, and the external provider identifier. No two callers on the same surface produce the same key, and the vault entry created during consent can only be resolved by the same combination that created it. Configure per-caller Credential Delegation →
How vault entries are scoped
Each delegation vault entry is scoped to three values:
A vault entry created during one caller’s consent can only be resolved by the same caller, on the same surface, for the same provider. Tokens are encrypted at rest using the gateway’s own key material.
How caller identity is stored privately
The user identity hash is a one-way transform of the caller’s source-authentication claims. Raw claim values are never stored. Only the derived hash is held in the vault.
| Property | What it means |
|---|---|
| Consistent lookup | The same caller identity produces the same hash on every request. The vault entry created during consent is resolved again on every subsequent call. |
| Privacy by design | An attacker with read access to the vault cannot reconstruct the caller’s original identity claims from the stored hash. |
| No claim collision | Two callers with different source-authentication credentials produce different hashes. Their vault entries cannot be confused. |
Relationship to Workload Binding
Caller context binding and Workload Binding are two distinct features that both involve the caller’s identity.
| Caller context binding | Workload Binding | |
|---|---|---|
| Purpose | Vault lookup key for per-caller delegated credentials | Signed VP attestation forwarded to downstream agents |
| Requires Transit Point | No | Yes |
| Requires G2G topology | No | Yes, for full enforcement |
| What it produces | An isolated delegation vault entry | A signed Verifiable Presentation |
| Configured on | Any surface with Credential Delegation | Transit Point element only |
Workload Binding is a Transit-Point-scoped element that embeds the caller’s context into a signed VP forwarded to a receiving gateway (GW2) via a Gateway Connection. The receiving gateway verifies the VP and exposes the caller context to OPA as input.identity_binding. See Workload Binding for a full explanation.
The two mechanisms draw from different data sources and do not depend on each other. The vault stores an encrypted OAuth token and uses the identity hash only as a lookup key. Raw credential values are never persisted. Workload Binding never reads the vault. Instead, it lifts live claims from the current authenticated request: either from the transit token (which carries claims captured at the Access Point) or from the Bearer JWT the managed agent presents at the Transit Point. The same caller’s request feeds both independently.
Use cases
Multi-user agent deployments. A single agent surface serves many callers. Each caller completes a one-time consent step to create their vault entry. Subsequent requests inject the stored token automatically, without re-prompting.
Per-caller attribution. The vault records when each caller granted consent and when their token was last used. Combined with the audit log, every outbound API call can be traced back to the specific caller who authorised it.
Token refresh without re-consent. When a caller’s OAuth access token expires, the gateway refreshes it automatically using the stored refresh token. The composite key persists across refreshes, so the caller is not interrupted.
Glad to hear it! Please tell us how we can improve more.
Sorry to hear that. Please tell us how we can improve.
Thank you for sharing your feedback so we can improve your experience.