Govern → Recording Policy

Recording Policy decides, at the moment a session connects, whether that session is recorded, which store the recording is written to, and how long it is kept. It is an ordered list of rules evaluated top-to-bottom; the first rule that matches wins. It is a tab on the Govern page.

Recording is opt-in: a session that matches no rule is not recorded. MisterShell ships with one seeded rule named Do not record — a Skip-everything rule near the bottom of the list that makes this default explicit. It is an ordinary rule you can edit or move. To record sessions, add at least one rule with the Record action that matches them — and note that new rules are added at the bottom of the list, below the seeded rule, so drag your Record rule above “Do not record” or it never fires.

Recording sessions is an Enterprise feature. Without that edition the create/edit buttons show a lock and, more importantly, no session is recorded — even when Record rules are configured, they have no effect until the entitlement is present. Sessions themselves still open normally.

A session’s retention period is fixed by the matching rule when the session connects; the recording is then removed once that many days have passed after the session ends. A later edit to the rule does not shorten or extend an existing recording. Recordings and their command evidence are immutable operational evidence: deleting the current resource, user, or Worker definition does not delete them. When the stamped deadline is reached, MisterShell removes the replay artifact and structured command output while independently retained policy-log rows remain available.

This is the sibling of Session Policy: Session Policy is access control — whether a session may open and what commands may run; Recording Policy is capture and retention — whether an allowed session is recorded, where, and for how long. The two share the same permissions.

The tab has two sub-views, selected with the toggle in its toolbar:

• Rules — the ordered record/skip rules.
• Stores — the destinations recordings are written to.

Rules

Each rule matches sessions with a set of selectors and applies one action.

Table columns

Column	Notes
Order	Position; drag or use the arrows to reorder. Order decides which rule wins.
Name	The rule’s name.
Resource Types / Session Types / Locations / Tags / Roles	The selectors. An empty selector shows an Any chip.
Action	record (green) or skip (grey).
Destination	The store a record rule writes to, or — for a skip rule.
Retention	How long a record rule keeps its recordings (e.g. 30 d), or —.
Enabled	Inline toggle; a disabled rule is skipped during evaluation.
Hits	How many times the rule has matched, with a reset button.
Actions	Edit / Delete. The last remaining rule cannot be deleted — edit it instead.

Rule fields

Field	Meaning
Name	A descriptive label for the rule.
Comment	Free-form notes.
Action	Record captures the session; Skip (do not record) exempts it.
Destination	(Record only) the recording store to write to. Required for a record rule.
Retention	(Record only) how many days to keep the recording — between 1 and 3650 (default 30).

Selectors narrow which sessions the rule applies to. Leave a selector empty to match any value for that dimension; within one selector the values are OR’d, and all non-empty selectors must match (AND across selectors).

Selector	Matches on
Resource Types	The type of resource being connected to.
Session Types	Shell (text terminals) or Graphical (RDP / VNC / web).
Locations	The resource’s location.
Tags	Tags on the resource.
Roles	The connecting user’s roles.

Stores

A recording store is a destination that recordings are written to. Keeping more than one lets you route recordings by data-residency requirements — for example, sessions in one region to a store in that region.

Table columns

Column	Notes
Name	The store’s name.
Backend	Local, S3, or Azure.
Destination	Where recordings land — for the built-in store, the server data volume; for cloud stores, the bucket/container and prefix.
Credential	The credential used to reach a cloud store.
Built-in	The built-in Local store carries this mark and cannot be deleted.

The built-in Local store keeps recordings on the server’s data volume. Add an Amazon S3 or Azure Blob store to keep recordings in your own cloud storage.

Store fields

Field	Meaning
Name	A descriptive label.
Description	Optional notes.
Backend	Amazon S3 or Azure Blob.
(S3) Bucket / Region / Prefix / Role ARN	The target bucket and region, an optional key prefix, and an optional role to assume.
(Azure) Storage account / Container / Tenant ID / Prefix	The target account and container, the directory tenant, and an optional prefix.
Credential	The credential that authorizes writes to the store.

Use Test connection on the form to verify the store is reachable with the chosen credential before you save.

Common tasks

Record a class of sessions

1. On the Rules view, click Create Rule.
2. Set the selectors so the rule matches the sessions you want to record (leave a selector empty to mean any).
3. Set Action to Record, pick a Destination store, and set a Retention in days.
4. Click Create Rule, then drag the new rule above the seeded “Do not record” rule — new rules land at the bottom of the list, and the first match wins, so a Record rule left below it never fires. Place more specific rules above broader ones.

Exempt sessions from recording

Add a Skip (do not record) rule that matches those sessions and place it above any broader record rule. (Sessions that match no rule at all are already not recorded.)

Add a cloud recording store

1. On the Stores view, click Create Recording Store.
2. Choose the Backend, fill in the bucket/container details, and pick the Credential.
3. Click Test connection to verify access, then save. The store is now selectable as a rule Destination.

To view and replay the recordings these rules produce, see Review → Sessions.

Permissions

Recording rules can use global location, tag and role selectors with policy-read access alone. Selecting storage credentials requires app.credentials.read; editing other settings preserves an existing credential assignment without loading the credential catalog.

• Read rules and stores: app.policy.read.
• Create / edit / reorder rules, toggle, clear hits, create / edit stores: app.policy.write (testing a store connection also needs app.credentials.read).
• Delete rules and stores: app.policy.delete.