Session recording and live view
What a vendor did on your systems is recorded on your side, encrypted with a key only your connector holds. This page covers where that lands, how to replay and search it, how to watch a session as it happens, how deletion works, and the audit log underneath all of it.
Where recordings live
Screen streams, keystroke logs and isolated-browser video are written to the connector's own disk, under /data/recordings, encrypted with AES-256-GCM. The key is /data/recording.key, generated by the connector on its first start, and it never leaves that machine. The control plane, ours on Cloud or yours on your own server, receives neither the content nor any way to read it. Command search runs on the connector as well, over its own store.
recording.key with it: without the key the files cannot be read, and the key cannot be reissued. A recording is playable and searchable only while its connector is online; the console then says an answer is incomplete rather than "no matches". And size the disk for recordings, not just for a token: a recording runs as long as its session, nothing cuts it short, so what bounds the disk is the retention set in Policy and how long your sessions tend to run.Turning recording on
Tick Record sessions on the resource, or set the Session recording mode in Policy to Required to record every session of every resource. Web apps are captured by a DOM recorder injected into the page, remote desktops from the session engine's stream, isolated browsers as a seekable video.
The vendor is told. A recorded session opens with a branded RECORDED card that shrinks to a compact REC pill in the corner and stays visible for the whole session. If Require recording consent is on in Policy, the session does not start until the vendor accepts the notice, and the acceptance is audited.
Replay and command search
Recordings lists every recording with filters by user, resource and date. Open one to replay it: remote-desktop and isolated-browser recordings seek freely, so a two-hour session can be scrubbed to the minute that matters. For SSH sessions with keystroke logging on, command search finds the recording in which a given command was typed, and the keystroke timeline jumps the player to that moment.
Both reach into the connector on demand. When that connector is offline the player cannot open the recording and search reports its result as incomplete; see a recording cannot be played or deleted.
Live view, take-control and terminate
Sessions lists what is running right now. An Admin or Auditor opens a remote-desktop or isolated-browser session and watches it live: the viewer joins the same connection, so the current screen appears at once rather than only future changes. An Admin can take control of the keyboard and mouse, hand it back, or terminate the session outright.
Nothing here is silent. The vendor sees a "being monitored" notice the moment someone joins, and every watch, take-control and release is written to the audit log with who did it and when.
Deleting recordings and retention
Because the bytes are on the connector, deleting is a two-step act. Pressing Delete in Recordings records the request immediately and writes it to the audit log. The content is removed when the connector confirms; until then the row shows as pending. If the connector is offline at that moment, the deletion completes the next time it connects, with no further action from you.
Retention works the same way in the other direction. Policy sets the number of days; the connector applies it to the files on its own disk, and the console trims its index to match, so a recording older than the window disappears from both.
The audit log
Audit holds every allowed request and every authenticated denial: who, when, which resource, which decision and why (no grant, pending approval, outside hours, denied, expired). It is append-only, and each row is hash-chained to the one before it. The console verifies the chain on demand and reports any alteration, deletion, splicing or truncation of the tail. Rows can be exported as CSV, and retention follows the days set in Policy while keeping the chain verifiable.
A chain alone cannot defend against someone who can rewrite the whole database and recompute every hash. The optional external anchor closes that gap: with a Time-Stamp Authority URL set in Policy, the chain head is sealed daily by an RFC 3161 timestamp from a trusted authority such as KamuSM, which no one inside your organisation can forge. Together with the recordings, this is the trail that answers a KVKK or Law No. 5651 question about what an outside party did and when.