# Credentials > How the gateway stores outbound delegated credentials and uses them to authenticate to external services on behalf of agents and users. Credentials store the outbound authorisation material the gateway uses to authenticate to external services on an agent’s behalf. They let the gateway act as a delegate, attaching the right token or key to outbound requests without exposing underlying secrets to the agent. ## What a credential is A credential is a reusable outbound configuration that tells the gateway how to obtain authorisation for calls to an external provider. It is the opposite direction from source authentication on inbound requests. - Inbound source authentication verifies who is calling the gateway. - Outbound credentials prove the gateway’s right to call external services. This delegation keeps trust boundaries clean. An agent asks the gateway to perform an external action, and the gateway uses the matching credential to authenticate that outbound call. Tokens are held per acting agent, per represented user, and per provider so each delegation context remains isolated. ## Credential types ### OAuth 2.0 Authorization Code Three-legged, user-consented access. Use this when actions must run as a specific end user who has explicitly granted consent. Typical configuration includes: - Authorization endpoint - Token endpoint - Client identifier - Client secret reference from Secrets - Callback URL - Requested scopes - Automatic refresh setting ### OAuth 2.0 Client Credentials Two-legged machine-to-machine access with no end user involved. Use this for service-to-service calls. Typical configuration includes: - Token endpoint - Client identifier - Client secret reference from Secrets - Requested scopes ### API Key A shared secret used by providers that authenticate requests with a single key. The key value is referenced from Secrets and is never displayed in credential settings. ## Where credentials fit in the gateway Credentials are consumed on the outbound path. When a surface forwards a request to an external destination that requires authentication, the gateway: - Locates the credential binding for the acting agent and provider. - Obtains or reuses a valid token for the represented user context. - Attaches the required token or key to the outbound call. Because credentials are isolated per agent, per user, and per provider, the gateway can safely delegate many concurrent external interactions without cross-context leakage. Rotating a provider secret once in Secrets updates every credential that references it. ## Consent and elicitation modes When a surface is configured for credential delegation and an outbound call requires a credential the vault does not yet hold, the gateway initiates a consent flow. Three modes control how that flow works. The mode is set on the Consent Mode field of the Credential Delegation element in the surface canvas. ### Pre-authorize The gateway enforces that all required credentials are present before any MCP interaction begins. If a credential is missing, the gateway blocks the session at initialisation and returns the relevant authorisation URLs to the caller. The user completes the OAuth flow up-front, before any tool call proceeds. Use this mode when the client application can display an auth prompt before the session starts and you want to eliminate any mid-session interruption. ### On-demand The session and MCP interaction proceed normally until a tool call requires a credential that is not yet available. The gateway returns HTTP 401 with the authorisation URL in the response body. The client handles the consent flow out-of-band, completes OAuth, and retries the request. Use this mode when the client application can handle the consent_required response and trigger an external browser redirect. ### Elicit (MCP-native) When a tool call requires a missing credential, the gateway issues a formal MCP elicitation request to the client over the established stream and holds the original tool call open. The client surfaces the consent prompt inline. Once the user completes OAuth through the gateway’s callback listener, the gateway resumes the original call and forwards it with the injected token. From the perspective of both the agent and the MCP server, the interaction is continuous. Consent is handled in-band without breaking the protocol flow. Use this mode when the client application supports MCP elicitation and you want consent to feel native to the agent interaction. ### OAuth callback In all three modes, the gateway acts as the OAuth callback endpoint. The downstream provider redirects to the gateway callback endpoint with the authorisation code, for example https://GATEWAY_HOST/v1/identity/oauth/callback/PROVIDER_ID. The gateway exchanges it for a token, stores it in the delegation vault, and injects it on all subsequent calls. The calling agent never receives or stores the token. For step-by-step configuration of consent modes and the delegation vault, see [Configure per-caller Credential Delegation](/products/affinidi-trust-fabric/agent-gateway/how-to-guides/setup/configure-per-caller-credential-delegation.md). ## Related - [Surface reference](/products/affinidi-trust-fabric/agent-gateway/reference/surfaces/surface-reference.md): Top-level surface fields including outbound credentials. - [Settings](/products/affinidi-trust-fabric/agent-gateway/reference/configuration/settings.md): Admin and system settings relevant to secret-backed configuration. - [Secrets](/products/affinidi-trust-fabric/agent-gateway/concepts/secrets.md): Centralised storage model for sensitive material used by credentials. - [Validate bearer tokens on a surface](/products/affinidi-trust-fabric/agent-gateway/how-to-guides/access/validate-bearer-tokens-on-a-surface.md): How to create a JWT verification strategy and attach it to a surface.