Recording & Redaction

Every session that passes through Britive Bridge is recorded - this gives you a complete, replayable audit trail of who connected to what and what they did. Recording is always on by default. The only way a session is not recorded is when a particular checkout is explicitly configured to opt out, which is decided per session, not in this config file.

Because recordings can contain sensitive output, Bridge also redacts (masks) secrets as it records. This page explains where recordings go and how redaction works.

Redaction is a best-effort safeguard, not a guarantee. Bridge masks known secret patterns and configured sensitive fields before storing recordings, but it cannot promise to detect every possible secret or every application-specific format. Do not rely on redaction as the only control for keeping sensitive data out of recordings.

Where recordings are stored

Option	Type	Default	Description
`server.recording.output_dir`	string	`/data/recordings`	The directory where Bridge writes recordings. Required.

bridge.yaml

server:
  recording:
    output_dir: /data/recordings

In a clustered deployment, output_dir must point at a shared volume - storage that every worker can read and write (for example a network file share or a cloud file system). Different workers may handle different parts of the same session, so they must all write to the same place. With local-only storage, recordings would be scattered and incomplete. In a single-container deployment, an ordinary local directory is fine.

Redacting secrets in recordings

Option	Type	Default	Description
`server.recording.redact_response_bodies`	bool	`true`	Mask secrets that appear in the response (output) side of recorded sessions.

To understand this setting it helps to know that many sessions have two sides:

The request side - what the user sends to the target system.
The response side - what the target system sends back.

The request side is always passed through redaction, regardless of any setting. The redact_response_bodies option controls the response side, and it defaults to true. It applies to:

WinRM - the standard output and error text returned when running commands on Windows hosts.
RESTCONF - the response bodies returned by network-device REST APIs.

Leave this on unless you have a specific, audited reason to capture raw responses. Turning it off means secrets returned by a target system could be stored verbatim in recordings.

bridge.yaml

server:
  recording:
    output_dir: /data/recordings
    redact_response_bodies: true   # the default; mask secrets in returned output

How redaction works for web traffic (HTTP proxy)

When you use the explicit HTTP proxy feature, Bridge captures the web requests and responses passing through it. Redaction there is governed by separate sanitize lists - names of sensitive headers, query parameters, and body fields whose values are replaced with a placeholder before anything is written to the capture.

These lists have sensible built-in defaults (covering things like authorization headers, password fields, and token parameters). An individual checkout may extend the lists to mask additional fields, but it can never shrink them - the baseline protection always applies.

The HTTP proxy’s sanitize_headers, sanitize_query_params, and sanitize_body_fields settings are documented in full on the HTTP proxy protocol page. See Protocols → HTTP Proxy for the complete defaults and how per-checkout extensions work.

Command logging for shell sessions

For interactive shell protocols (such as SSH), Bridge captures the commands users run so that recordings include a readable history of activity, not just raw screen output. As part of this, Bridge automatically masks recognized secrets that would otherwise appear in that captured history - for example, common password or token patterns typed on a command line are replaced with a placeholder before they are stored.

This happens automatically; there is no setting to configure. The result is a recording that is safer to retain and review: you can usually see what was done without exposing common credential patterns used along the way.

Command masking is best-effort. It catches recognized secret patterns and secrets typed at an unechoed prompt (for example a password after sudo), but it cannot detect every secret a user might type or paste. As noted above, don’t rely on it as your only control for keeping credentials out of recordings.

Last updated on July 9, 2026

Licensing