Skip to main content
The client block controls how Bifrost manages its internal worker pool, request logging, authentication enforcement, header policies, SDK compatibility shims, and MCP agent behaviour.

Connection Pool

A larger pool reduces latency spikes under burst load at the cost of higher baseline memory. 500–1000 is a common starting point for production workloads with multiple providers.

Request & Response Logging

Set disable_content_logging: true for HIPAA / PCI compliance workloads where message content must not be persisted, and keep retain_content_in_object_storage: false: with it on, the full payload of every content-disabled request is still persisted in the object storage bucket. A virtual key with its own disable_content_logging: false overrides this for its traffic, so audit your keys as well.
This setting does not apply to observability connectors. Each connector (BigQuery, Kafka, Pub/Sub, OpenTelemetry, Datadog) has its own disable_content_logging flag that defaults to false and is read independently of this one. Setting the client flag alone still exports full message content to every configured connector.For a compliance workload where content must not leave the deployment, set disable_content_logging: true on every configured connector as well. These flags do not cover every exported value: BigQuery writes params and tools regardless of its flag, and captured request headers are exported regardless of content flags. If those fields or headers can contain sensitive data, do not export them or apply separate controls. Keep allow_per_request_content_storage_override off, and make sure no virtual key sets disable_content_logging: false. If retain_content_in_object_storage is on, its bucket holds the full payload of every content-disabled request: turn it off when content must not be persisted, or keep the bucket inside the approved deployment boundary when retention is allowed but content must not leave the deployment. See Content Logging for how the layers compose, and for retain_content_in_object_storage, which keeps content in your storage bucket while hiding it from the UI and API.

Reverse Proxy

When Bifrost acts as an OAuth client to upstream MCP servers, the redirect_uri it registers is built from the incoming Host header by default - behind a reverse proxy that is the proxy’s internal address, not its public one. One setting lets you override it with the proxy’s public URL. This field supports env var syntax ("env.MY_VAR"). When unset, it falls back to the incoming Host header.

The client role

When Bifrost connects to an upstream MCP server (Notion, Jira, GitHub, etc.) on behalf of a user, it acts as an OAuth client. mcp_external_client_url is the callback Bifrost registers as its redirect_uri with those upstream providers - they redirect the user’s browser to <client URL>/api/oauth/callback after login. Set it to the proxy’s public URL so the callback resolves to a publicly reachable address.

Example

Or as a plain URL:
When left empty, the redirect_uri falls back to the request’s Host header - correct for development or when no reverse proxy fronts Bifrost. This setting is also configurable via the UI (MCP Gateway → MCP Settings) and the management API, with no restart required.

Security & CORS

While dashboard auth is disabled or unconfigured, or Bifrost runs without a config store (config_store.enabled: false), a request to the management API (/api/*, /ws, /metrics) that carries an Origin header is accepted only from a localhost origin, from the gateway’s own origin (the Origin host and port match the request’s Host, as for the bundled dashboard’s own requests such as PUT /api/config), or from an origin listed in allowed_origins by name or pattern (for example https://*.example.com); the "*" entry does not count, and other origins receive 403. Requests without an Origin header (CLI and SDKs), whitelisted routes such as /health, and inference routes are unaffected. If the dashboard sits behind a proxy that rewrites the Host header, list its public origin in allowed_origins. To call the management API from a web app on another origin, list that origin explicitly, or enable dashboard authentication, which lifts this check. Dashboard authentication needs the config store: with config_store.enabled: false it cannot be turned on, so listing the origin is the only option.

Header Filtering

Controls which x-bf-eh-* extra headers are forwarded to upstream LLM providers. When both allowlist and denylist are empty, all x-bf-eh-* headers pass through. Specifying an allowlist enables strict whitelist mode - only listed headers are forwarded.

Compat Shims

Compatibility flags that let Bifrost silently adapt request/response shapes for SDK integrations.

Agent Gateway and Skills Marketplace URLs

Configure these public base URLs independently. Neither feature derives its public URL from request headers. Public base URLs for MCP, Agent Gateway, and Skills must use HTTP or HTTPS and must not contain userinfo, query strings, or fragments. Ports and path prefixes are supported. API updates reject invalid URLs without echoing their values. Config loading ignores invalid overrides: Agent Gateway and skills marketplace serving stay disabled, while MCP retains its request-derived callback fallback.
Both fields support environment references such as env.BIFROST_EXTERNAL_URL and vault references. They may share a value, but there is no common base-URL setting. Without a resolved Agent Gateway URL, HTTP protocol endpoints return 503 and A2A gRPC operations return UNAVAILABLE. Agent registration and management remain available. Without a resolved skills URL, marketplace registration and serving are disabled; skill management and direct downloads remain available. Use Agents → Agent Settings or Skills → Skills Settings to update the corresponding URL in the dashboard. See Agent Gateway configuration and Skills Repository marketplace access.

MCP Agent Settings


Async Jobs


Prometheus Labels

Add custom labels to every Prometheus metric emitted by Bifrost:

Authentication

governance.auth_config protects the Bifrost dashboard and management API with username/password auth.
A top-level auth_config is also accepted for backwards compatibility, but governance.auth_config is the preferred location.

Encryption Key


Global Proxy

The global outbound proxy is the one on the dashboard’s Config → Proxy page, including which components send their outbound requests through it. Declare it as a top-level proxy_config (not to be confused with a provider’s own proxy_config):

Full Example