Activity Search & SIEM Export

Session recordings answer “what happened in this session”. They are the wrong tool for “who ran that command anywhere last month” - that means opening sessions one at a time until you find it.

Bridge also writes session activity to a searchable index, so the second question is a search rather than an excavation. The same stream of events can be sent to your SIEM, so Bridge activity lands next to the rest of your security telemetry.

What gets indexed

As a recorded session runs, Bridge indexes the things a reviewer looks for:

• Commands run in shell sessions - SSH, telnet, Kubernetes exec - and on network devices (NETCONF, RESTCONF, WinRM), one entry per line the user submitted, including attempts a command policy blocked and the fact that they were blocked. Both native and in-browser sessions.
• Database queries from both native and in-browser database sessions.
• HTTP requests passing through the web proxy.
• File transfers - clipboard file copies and browser uploads.
• Pasted text from in-browser RDP, SSH and VNC sessions, at the level set by paste_capture.
• Typed input in desktop sessions (RDP, VNC) - what was typed into the remote desktop, one entry per line, governed by keystroke_capture.
• Typed input in in-browser SSH, as a second entry alongside the command when the two differ - the edits, aborts and control keys the final command text hides.

Each entry keeps the session, user, target and timestamp, and links back to the moment in the recording it came from - so a search result opens the replay at that point rather than at the beginning.

Only recorded sessions are indexed. A checkout that sets record_session: false is not recorded and does not appear.

Desktop typing is indexed as keystroke entries, never as commands: nothing typed into a window was executed, and letting it land as a command would weaken the meaning of every command result.

What is not searchable

Desktop keystrokes

What someone typed inside a remote desktop is indexed and exported like any other activity, but it needs its own setting, because a desktop gives Bridge less to work with than a terminal does.

In a terminal, Bridge can tell a password from a command: a terminal only draws when it echoes, so input that produced no echo is a secret and is masked outright. A desktop draws constantly - the clock alone - so that signal means nothing there. What leaves the recording for a searchable index or a SIEM is therefore a deliberate setting rather than something inferred.

server:
  recording:
    keystroke_capture: "redacted"   # the default; "off" to index none of it

A checkout can override it for one grant with keystroke_capture.

This setting does not change the recording. Key events are captured either way, and remain visible in the player’s keystroke log - it governs only what becomes searchable and what is sent to a SIEM.

Searching

Open Activity Search from the floating search button in the web interface, beside the Admin button. Search by text, and narrow by event type, user, target, protocol or time range. Each result offers View session, which opens the replay at that event.

Indexing settings

New sessions are indexed as they run, and that is not optional. What you can control is the one-time catch-up for recordings that were made before the index existed, which is paced so it never competes with live sessions for disk or database.

server:
  audit:
    backfill_enabled: true          # import pre-existing recordings (default)
    backfill_batch: 20              # sessions per cycle
    backfill_interval_seconds: 5    # seconds between cycles

The Admin console’s Overview tab reports catch-up progress, so you can see whether the index is still filling in.

Streaming to a SIEM

The same events can be forwarded as they are indexed. Off by default.

server:
  audit:
    export:
      enabled: true
      type: "webhook"                       # or "syslog"
      endpoint: "https://siem.example.com/ingest"
      token: "REPLACE_WITH_YOUR_TOKEN"      # webhook only

Prefer tcp for syslog unless you have a reason not to - UDP silently drops under load.

Sending is best-effort, and the console tells you so

Export never blocks or slows a session. If the destination is unreachable, events are dropped and counted, and the session carries on. That is the right trade-off for access, but it means a misconfigured destination can look like it is working.

So the Admin console’s View Configuration tab reports export twice: what the configuration asks for, and what actually got wired. If the first is on and the second is off, Bridge could not establish the destination - check the endpoint and the logs. Do not treat configured as delivered.

The bearer token is never shown back, only whether one is set.