Sessions

A work session is a bounded slice of access: a person (or a token acting for one) asks to do specific work on specific servers, an admin approves the request, the work happens, and the session closes. Everything else in Audit — commands, sudo grants, file transfers — ties back to one of these sessions.

The Sessions page lists them all so you can see the full lifecycle at a glance.

How to get here

Open the sidebar and go to Audit → Session history (or Audit → My sessions if you’re a regular user).

What’s in the list

Each row is one session. The columns are tuned for audit questions like “who asked?”, “what scope?”, and “did it actually run?”

Description — the title and short summary attached when the session was requested.
Operator — who actually ran the work: a user, an API token, or a service token. The icon next to the name shows the type.
Scopes — the operation categories the session was approved for: terminal access, commands, file transfers, sudo, and so on. Extra scopes collapse into a tooltip.
Servers — the servers in scope. Extras collapse into a tooltip when there are many.
Status — where the session is in its lifecycle: waiting for approval, approved but not started yet, currently running, finished normally, expired without finishing, terminated early by an admin, or cancelled before it started.
Risk — the risk level from the AI analysis once the session has finished. Blank until the analysis completes.
Duration — how long the session actually ran, from start to finish (or to “now” if it’s still running).
Date — when the session was first requested.

Click a row to open the session detail, which has the full timeline (commands, file transfers, sudo grants that happened inside), the approval record, and the AI analysis when the session has finished.

Filtering

Use the filter bar above the list to narrow what you see.

Status — show only one outcome at a time. For example, only sessions that were terminated early.
Scope — filter by operation category. For example, only sessions that included sudo.
Server — find every session that touched a specific server.
User — find every session a specific person requested or ran.
Date range — bound the audit to an incident window.

Who sees what

The page itself is open to everyone, but the rows you see depend on your role.

Regular users see only the sessions they requested or were assigned to run. The sidebar shows the page as My sessions and the page header reads the same.

Administrators see every session in the workspace. The sidebar label stays Session history.

Questions this page answers

“Who got into prod-web-01 last Tuesday afternoon, and why was it approved?” → filter by server and date range, then open the row.
“How many sessions did this team run with sudo this quarter?” → filter by scope sudo and a date range.
“Did this session actually end?” → check the status column on the row, or open the detail.
“Was this terminated early, or did it expire on its own?” → the status column distinguishes the two.

For real-time visibility into active sessions (instead of after-the-fact review), see Live activity in the Execution sidebar group.
For the individual events inside a session — commands, websh terminals, file transfers, sudo grants — open the session detail or use the corresponding page under Events.