Content Logging

Overview

Bifrost records two kinds of information about every request. Metadata covers model, provider, token counts, cost, latency, status, and governance attribution. Content is the actual prompts, completions, and tool traffic. Metadata is what dashboards, budgets, and alerts run on. Content is what makes a log useful for debugging, and what compliance regimes care about. Bifrost lets you keep the first without the second.

There is no single switch. Content is stripped independently at each destination, from that destination’s own setting. A log store with content disabled says nothing about what your BigQuery table or Datadog spans contain. This page covers how the layers compose.

What counts as content

Broadly, anything derived from the request or response body:

Category	Examples
Messages	Chat history, prompt text for completions, response messages with role attribution
Tool traffic	Tool definitions (names, descriptions, parameter schemas), tool call arguments, tool results
Parameters	Temperature, `max_tokens`, stop sequences, and other request parameters
Modality payloads	Embedding inputs, transcription audio, speech text, image prompts
Reasoning	Reasoning traces and refusal content, when the provider returns them
Raw bytes	Verbatim provider request/response bodies, when `x-bf-store-raw-request-response` is used

The categories each destination actually strips are not identical. A setting that removes messages may leave tool definitions or request parameters in place. Check the destination-specific notes below before treating a flag as a guarantee.

Attribution identifiers (user ID, team, customer, business unit, virtual key) are metadata, not content. They are never removed by a content setting. If end-user identifiers are sensitive in your deployment, treat that as a separate concern.

Where content can land

Destination	Governed by
Log store (Postgres / SQLite / ClickHouse row)	`client.disable_content_logging`
Object storage (offloaded log payloads)	`client.disable_content_logging` + `client.retain_content_in_object_storage`
Logs UI and Logs API	Whatever the log store holds, plus the hidden-content gate
Observability connectors (BigQuery, Kafka, Pub/Sub, OpenTelemetry, Datadog)	Each connector’s own `disable_content_logging`
Metrics (Prometheus, Datadog metrics, OTLP metrics)	Never carry content. Counters, histograms, and dimension tags only

The control layers

1. Global: `client.disable_content_logging`

The default for the Bifrost log store. Set it to true and log rows keep metadata only.

{
  "client": {
    "enable_logging": true,
    "disable_content_logging": true
  }
}

This governs the log store only. It has no effect on observability connectors.

2. Per-request: `x-bf-disable-content-logging`

Overrides the global setting for a single request, in either direction: true suppresses content for a request that would otherwise be logged, false captures content while the global setting is true. Per-request overrides are off by default. Enable client.allow_per_request_content_storage_override first. While it is off, the header is ignored and the global setting is authoritative. See Request Options for headers, context keys, and SDK examples.

3. Per-connector: each connector’s own flag

Every observability connector has an independent disable_content_logging, defaulting to false. It is not inherited from the client setting.

Connector	Flag	Notes
BigQuery	`disable_content_logging`	Gates `input_history` and `output_message`. `params` and `tools` are written either way.
Kafka	`disable_content_logging`	Strips `gen_ai.input.` and `gen_ai.output.` from all spans
Pub/Sub	`disable_content_logging`	Same as Kafka
OpenTelemetry	`disable_content_logging`, `disable_root_span_content`	The second drops content from the root span only
Datadog	`disable_content_logging`	Covers APM spans and LLM Observability payloads

Captured request headers (request_headers on a connector, client.logging_headers on the log store) are exported regardless of any content flag. Only capture headers you intend to export.

For a workload where content must not leave the deployment, set disable_content_logging: true on the client and on every configured connector. Setting only the client flag still exports full content everywhere.

Retaining content in object storage

Disabling content logging normally drops content permanently. client.retain_content_in_object_storage offers a middle ground: content is kept in the object storage bucket but never served back.

{
  "client": {
    "enable_logging": true,
    "disable_content_logging": true,
    "retain_content_in_object_storage": true
  }
}

In the UI this is Retain Content in Object Storage, under Logs Settings. The toggle is disabled unless object storage is configured on the logs store. When it is on and a request has content logging disabled, either by the global setting or by the x-bf-disable-content-logging header, Bifrost:

writes a metadata-only database row, with payload fields and the content preview cleared,
offloads the complete payload to object storage, marked hidden,
and never hydrates that payload back on reads. The Logs UI and the Logs API show metadata only.

The content is readable only by someone with direct access to the storage bucket. That is a different access path, typically governed by your cloud IAM rather than by Bifrost roles. The result is that retention and visibility become separate decisions.

Requirements and behavior

Condition	Result
Content logging enabled	Normal behavior; the toggle has no effect
Content logging disabled, toggle off	Content is dropped entirely
Content logging disabled, toggle on, object storage configured	Content retained in the bucket, hidden from UI and API
Content logging disabled, toggle on, no object storage	Content is dropped entirely, and Bifrost logs a warning at startup

Interaction with other features

Raw byte storage. x-bf-store-raw-request-response only persists raw provider bodies when content logging is on for that request. With content logging off, raw bytes are dropped from the log row even if the header is set. Guardrail redaction. When Enterprise redaction is enabled, redaction runs before persistence and before export, so connectors and object storage receive the redacted or placeholderized values. Reveal mappings stay on the Bifrost log row and are never exported. With disable_content_logging enabled, no reveal data is persisted at all. See Guardrail Redaction. Log exports. Offloaded payloads carry the same fields the log row would have carried. See Log Exports.

Choosing a configuration

Metadata only, everywhere. Set disable_content_logging: true on the client and on every connector. Confirm no connector is capturing headers you did not intend to export. Metadata in Bifrost, content retained for security review. Set disable_content_logging: true and retain_content_in_object_storage: true, with object storage configured. Restrict bucket access to the reviewing team. Content on by default, suppressed for sensitive traffic. Leave disable_content_logging: false, enable allow_per_request_content_storage_override, and send x-bf-disable-content-logging: true on the requests that need it. Content in Bifrost, not in third-party tools. Leave the client setting off and set disable_content_logging: true on each connector.

CLI Agents & Editors

SDKs & Frameworks

Identity Providers (SSO)

Content Safety (Guardrails)

Observability

Vector Databases

Content Logging

Overview

What counts as content

Where content can land

The control layers

1. Global: `client.disable_content_logging`

2. Per-request: `x-bf-disable-content-logging`

3. Per-connector: each connector’s own flag

Retaining content in object storage

Requirements and behavior

Interaction with other features

Choosing a configuration

​Overview

​What counts as content

​Where content can land

​The control layers

​1. Global: client.disable_content_logging

​2. Per-request: x-bf-disable-content-logging

​3. Per-connector: each connector’s own flag

​Retaining content in object storage

​Requirements and behavior

​Interaction with other features

​Choosing a configuration

Overview

What counts as content

Where content can land

The control layers

1. Global: `client.disable_content_logging`

2. Per-request: `x-bf-disable-content-logging`

3. Per-connector: each connector’s own flag

Retaining content in object storage

Requirements and behavior

Interaction with other features

Choosing a configuration