Session recording

A brokered session is already attributable — you know who connected to what. Session recording goes further: it captures what actually happened during the session, so you can replay the terminal exactly as it ran.

What gets recorded

• Terminal I/O. The full output stream of an interactive shell is captured to a replayable cast, along with the terminal size, duration, byte count, and start time. Empty sessions where nothing happened are not stored.
• SFTP operations. File transfers through the broker — list, download, upload, mkdir, rename, delete — are recorded to the audit trail with their path and size.
• Single commands. Commands run against a host are written to your command history and the audit trail with their exit code and risk classification.

What a recording contains, and who can read it

A recording is the shell’s output stream as the host sent it, with one change: secrets that the exposure detectors recognise are replaced before the recording is stored. Keystrokes are not captured on their own; what you type appears only where the remote host echoes it back. Commands typed into a shell, a shared session or a snippet are checked against a risk list after they reach the shell, and a risky one is flagged in the audit trail as an SSH_SHELL_RISKY_INPUT entry that records at most the command name, never what was typed. Nothing is shown to you when this happens. The check is best-effort: it rebuilds lines from keystrokes, so history recall, tab completion and cursor edits are not seen. It is capped at 20 entries a minute per session, after which one summary entry counts the risky lines past the cap and any lines not checked. Recording never delays or changes what you type.

Recordings are kept in the Kutrion database. They are not sealed: Kutrion’s at-rest guarantee covers credential material, and terminal recordings, their summaries and command history fall outside it. On Team and Enterprise, the plans that carry session recording, an interactive brokered shell is recorded, whether you use it alone or share it; there is no per-host or per-session switch. On Free and Pro it is not recorded, except a demo session, which is always recorded. A shared session is recorded on the same rule and stored as a recording of the member who shared it. Each guest, who may be from another organization, is told the session is recorded before they can type: the terminal shows it as Recorded, and while recording review is on it also shows the review notice described below. Each change of who holds the keyboard is written to the recording as a marker naming the holder and to the audit trail as COLLAB_CONTROL_GRANTED, COLLAB_CONTROL_RECLAIMED or COLLAB_CONTROL_RELEASED. The web app does not offer Share session on the demo host. Recordings are kept under the organization’s retention policy and are not part of the hash-chained audit log, so they are not tamper-evident. When a member deletes their own recording, the deletion is audited.

The user who recorded a session can list, play back and summarise it, and delete it unless the organization’s retention policy keeps it. Nobody else in the organization can open it unless the organization has turned on recording review, below. Because recordings are not sealed, whoever operates the database can read them there.

Secrets filtered out of the stored recording

Each recorded shell’s output passes through the same detectors the exposure scanner uses. Where one matches, the stored recording carries a marker such as [redacted: github_token] in place of the secret. The label before a secret is kept, so GITHUB_TOKEN=ghp_... is stored as GITHUB_TOKEN=[redacted: github_token]. The detectors recognise:

• private key blocks, from the -----BEGIN ... PRIVATE KEY----- line to the next END line;
• AWS access key IDs (AKIA...), and AWS secret access keys on an aws_secret_access_key line;
• Google API keys (AIza...);
• GitHub tokens (ghp_, gho_, ghu_, ghs_, ghr_ and fine-grained github_pat_ tokens);
• Slack tokens (xoxb-, xoxp- and the other xox forms);
• API keys of the sk- / rk- / pk- form, and Stripe sk_live_, sk_test_, rk_live_ and rk_test_ keys;
• JSON Web Tokens;
• the password in a URL of the form scheme://user:password@host;
• a value of six or more characters assigned to a name containing SECRET, TOKEN, PASSWORD, PASSWD, APIKEY, API_KEY or PRIVATE_KEY, such as DB_PASSWORD=... or api_token: ....

Text a terminal receives but does not draw is checked as well: window titles, clipboard writes (OSC 52, decoded from base64 and re-encoded), hyperlink targets, and DCS, APC, PM and SOS payloads. Each is checked on its own, and a secret in one is replaced inside it.

A secret is caught wherever the network happens to split it, and when a colour code or another terminal escape sequence sits inside it. To do that the recorder holds back the last 4096 characters of visible output (or 16 KiB of raw output, whichever is shorter) before storing them. Each piece keeps the time it arrived, so replay timing is unchanged; a secret that arrived in several pieces appears, as its marker, at the moment its first piece arrived. A private key block is held from its BEGIN line until its END line arrives.

What is not filtered:

• Secrets the detectors do not recognise. A bare password with no label, a database password outside a URL, an arbitrary hex or base64 key, or another vendor’s token format is stored as shown.
• Secrets a program draws rather than prints. Full-screen programs such as editors, pagers and monitors place characters by cursor movement, so a secret on their screen may never appear as one continuous string in the output, and is then not recognised.
• Very long secrets. One that only becomes recognisable at its end and is longer than the window above can be stored before it is recognised. A match still running after 64 KiB, or a BEGIN ... PRIVATE KEY block with no END line within 64 KiB, is replaced up to that point and the output after it is stored as shown; a real key or token is far shorter.
• A JSON Web Token joined to the word before it, such as x-eyJ.... Only a token that starts after a space, punctuation other than - and _, or the start of a line is recognised.
• The live terminal. You see the original output; only the stored copy is filtered. A re-attached session replays the original output too.
• Recordings stored before filtering existed, and recordings of an organization that has turned it off. These are kept as captured.
• RDP recordings and command history. Windows session recordings and the command history of single commands are stored as captured.

Two limits keep filtering from slowing the server, and both leave output out rather than store it unchecked. A title, clipboard write or inline image still unterminated after 64 KiB is left out of the recording through to its end. And a session whose output keeps the filter working far harder than ordinary output does, such as a stream of tokens tens of kilobytes long, stops being recorded: the recording ends with [recording truncated: redaction limit reached] and nothing after that point is stored.

An exposure suppression silences alerts for a pattern; it does not exempt that pattern from filtering. Filtering is on for every organization by default, and an organization admin can turn it off with the organization’s recording_redaction_enabled setting; the change is recorded in the audit trail.

A filtered recording is marked as such, with the number of secrets it replaced, and the replay on the web, in Kutrion Terminal and on mobile shows a Secret redaction note. A recording without the note was stored unfiltered.

Recording review

An organization owner or admin can turn on recording review under Organization → Recordings review on the web. It is off by default, and turning it on or off is recorded in the audit trail as ORG_RECORDING_POLICY_UPDATED, with the policy before and after.

While review is on, owners and admins can:

• list members’ recorded shell sessions, filtered by member, by host or connection name, and by date;
• replay any of them;
• read or generate its summary.

Review is not retroactive. It covers only recordings of sessions that started at or after the moment review was last turned on, because members are told about review only in sessions opened while it is on. A recording from before that moment is not listed, and opening it by its id answers as if it did not exist. Turning review off and on again starts over from the new moment, so recordings from an earlier period of review are not shown again.

An owner’s recordings are reviewed by owners only. An admin does not see them listed and is refused a replay or a summary of one, the same rule that stops an admin ending an owner’s live session. Whether a recording is an owner’s is fixed when it is stored: a recording made by an owner stays owner-only after that person stops being an owner, and a member promoted to owner later does not take their earlier recordings with them. Recordings stored before this rule existed count as not an owner’s.

Review is limited to the organization’s own recordings, and it is not available to a support “view as” session or to an MSP “act as” session. There is no separate auditor role: review belongs to owners and admins.

Members are told. While review is on, a session that is being recorded opens with this line in the terminal, on the web, in Kutrion Terminal, on mobile and in the CLI:

This session is recorded. Your organization’s owners and admins can replay it and read its summary.

The Recordings screen on the web, in Kutrion Terminal and on mobile says the same. The line is shown when the session opens; a session already open when review is turned on does not show it.

Retention

An owner or admin also sets how long recordings are kept, on the same page:

• Members may delete their own recordings (the default). Nothing is deleted automatically.
• Keep for a number of days (1 to 3650). Members, admins and owners cannot delete a recording from the Recordings screen. Once a day, the server deletes recordings that started more than that many days ago, and records each deletion as ORG_RECORDINGS_PURGED with the number removed.
• Keep forever. Members, admins and owners cannot delete a recording from the Recordings screen, and nothing is deleted automatically.

While either of the last two applies, a member who tries to delete a recording is told why, and the delete control is not offered. Retention applies to terminal recordings only, and two removals are outside it: removing a user from the product entirely still removes that user’s recordings with the account, and resetting the guided demo removes the recordings of the demo host it made.

Any owner or admin can make the policy stricter: turn review on, move from members deleting their own to a number of days or to keeping forever, or keep recordings for more days. Making it less strict needs an owner who verifies with a passkey or app-MFA first: turning review off, leaving keep forever, keeping recordings for fewer days, or going back to members deleting their own. An admin is refused, and an owner who has not verified recently is asked to, with nothing changed until they do. A refused owner attempt is recorded as ORG_RECORDING_POLICY_STEP_UP_REQUIRED.

A new or shorter window does not delete anything straight away. After moving to a number of days, or lowering the number, the daily purge leaves the organization’s recordings alone for 7 days, then applies the new window. That gives an owner a week to notice and undo a change before anything is lost; recordings the earlier window would also have removed wait those 7 days too.

Exposure detection flags secrets as well

The same output stream is also fed to the credential-exposure scanner, independently of whether the session is being recorded. When a key or password surfaces in the terminal, the scanner raises a CREDENTIAL_EXPOSURE_DETECTED event in the audit trail and stores a redacted sample of the finding. See Credential health. A secret that reached the terminal was seen by whoever was at it, so treat an exposure finding as a reason to rotate the credential whether or not the recording was filtered.

Replay and summaries

Recordings are playable, not just listed. You can step through a recorded session to see exactly what ran, in order and with timing. An optional summary extracts the commands and risky actions from the stored recording, so it reads the filtered output: a command that carried a recognised secret is listed with the marker in its place. The extraction is deterministic, so the factual record holds even with no AI model involved; where a model is available it only narrates over those facts. A summary is narrated by the organization’s self-hosted model or by none: a recording’s transcript is not sent to a cloud model, whether the summary is read by the member or by a reviewer, and whether or not the organization has opted in to cloud AI elsewhere. See Privacy-first AI.

Plan availability

Capability	Plan
Terminal and SFTP audit-trail records	All plans
Session recording (replayable terminal casts)	Team and above

On plans without session recording, sessions run normally and stay on the audit trail — they just are not captured as replayable casts.

Access to recordings is audited

Viewing a recording is itself an audited event, as are generating or reading its summary and deleting it. A reviewer’s reads are recorded under the reviewer: listing recordings as ORG_RECORDINGS_LISTED, replaying one as ORG_RECORDING_REVIEWED and reading its summary as ORG_RECORDING_SUMMARY_REVIEWED, each naming the member whose recording it was. An admin refused a replay of an owner’s recording is recorded too, as a failed ORG_RECORDING_REVIEWED. The audit trail therefore covers not only who ran the session but every later read of the recording, and who read it.

Where to go next

• SSH broker overview — how brokered sessions are made attributable.
• Audit logs — where session, SFTP, and recording-access events land.
• Fleet commands — run and track a command across many hosts at once.