Govern → Session Policy

Session Policy is the access firewall for interactive sessions. It decides — at the moment a session opens, and again for each command typed inside a shell — whether to Accept or Deny, based on rules you order from top to bottom. It lets you express controls like “operators may open read-only database shells in the EU region, but only admins may run write statements,” without touching individual resources.

The tab has two sub-views, selected with the Rules / ACLs toggle in its toolbar: Rules (the ordered decision list) and ACLs (reusable named sets of command patterns that rules reference).

Session Policy is an Enterprise feature. Without that edition the create/edit buttons show a lock, and the policy is not enforced at all: sessions open without the connection-time check (your role permissions still apply), and commands run without the per-command check.

How a decision is made

Ordinary Accept/Deny rules are evaluated at two moments — when the session opens, and again on each command typed in a shell (checked at the worker). Every decision is Accept or Deny; a matched rule can additionally notify and/or log:

flowchart TB
  open["Session opens"] --> c1{"Connection rules<br/>first match wins"}
  c1 -->|deny| refused["Session refused"]
  c1 -->|accept| live["Session runs"]
  live --> cmd["Each command typed"]
  cmd --> c2{"Command rules<br/>checked at the worker"}
  c2 -->|deny| blocked["Command blocked<br/>session stays open"]
  c2 -->|accept| run["Command runs"]
  extra["Any matched rule can also<br/>notify (automation event) and/or log (policy log)"]
  c1 -.-> extra
  c2 -.-> extra

How rules are evaluated

• Rules are checked top to bottom; the first rule that matches decides the outcome. Nothing below it runs.
• Each rule has several selector cells (resource types, session types, locations, tags, roles, command ACLs). A rule matches when every non-empty cell matches the session.
• Within one cell, multiple values are treated as “any of these.” An empty cell means “any” — it places no restriction on that dimension.
• Rules are evaluated at two points: at connection time (does this session open at all?) and, for shell sessions, at command time (may this specific command run?).
• No match means deny. If no rule matches at connection time, the connection is refused and the refusal is logged in the Policy Log as (no matching rule). The same default applies at command time: a command that no rule accepts is blocked. Accepting anything therefore always requires a matching Accept rule — see the seeded Default allow rule below.
• Chained commands are checked piece by piece. A command line is split on the shell chaining operators (;, &&, ||, |, &), and every piece must be accepted by a rule. If any piece matches a deny rule — or matches no rule at all — the whole line is blocked. So ls; rm -rf / is not let through by a rule that accepts ls *.
• At connection time, the command-ACL cell is interpreted specially: a Deny rule with an ACL is command-specific — it blocks those commands later but does not prevent the session from opening. An Accept rule opens the session whether or not it carries an ACL (you must be able to connect to run the commands it allows). A Deny rule without an ACL refuses the connection outright.

The Default allow rule

MisterShell ships with one seeded rule named Default allow — an Accept-anything rule near the bottom of the list. It is an ordinary rule: you can edit, move, or (as long as it is not the only rule left) delete it. Because of the default-deny behavior above, this rule is what keeps normal access working on a fresh installation; removing it without adding your own accept rules denies everything.

Rules view

What a rule contains

Field	Meaning
Name	A label for the rule.
Comment	Optional notes.
Action	Accept, Deny, or Approve. Approve gates resource access first and does not use command ACLs.
Resource Types	Which resource types the rule applies to (empty = all).
Session Types	Shell and/or Graphical (empty = all).
Locations	Which locations (empty = all).
Tags	Resources carrying any selected tag (empty = all).
Roles	Which user roles the rule applies to (empty = all).
Command ACLs	One or more named command sets to match. Empty = the rule matches every command — an empty-ACL Accept rule is what allows normal commands to run, and an empty-ACL Deny rule blocks all of them.
Notify	When on, a match fires an automation event so you can wire alerts to it.
Log	When on, every decision this rule makes is recorded in the Policy Log.
Enabled	Turn the rule on or off without deleting it.

Common tasks

• Create a rule — Click Create Rule, fill the form, save. New rules are added at the bottom of the list — below the seeded Default allow rule. Because the first match wins, a new Deny rule left there never fires: drag it above Default allow (and above any other broad accept rule) after creating it.
• Reorder — Drag a row by its handle, or use the up/down arrows. Order is the whole point: put narrow, specific rules above broad ones.
• Edit — Click the pencil icon on a row.
• Enable / disable — Flip the Enabled toggle. The rule is kept but ignored while off.
• Toggle Notify / Log — Flip these inline on the row; the change applies immediately.
• Watch usage — Each rule shows a Hits badge counting how often it has matched. Click the reset control to clear the counter.
• Delete — Click the delete icon and confirm. The last remaining rule cannot be deleted — to enforce a deny-all posture, edit the remaining rule instead of emptying the list.

There is no separate preview mode; turn on Log for a rule and watch the Policy Log to confirm it behaves as intended before relying on it.

ACLs view

A Command ACL is a reusable, named list of command patterns. Rules reference ACLs instead of repeating patterns, so you can maintain “read-only SQL” or “dangerous shell commands” in one place.

What an ACL contains

Field	Meaning
Name	Identifies the ACL (this is what rules select).
Description	Optional notes.
Patterns	One or more command patterns, each marked Glob or Regex.

Pattern matching:

• Glob patterns match the whole command, case-insensitively (for example kubectl get *).
• Regex patterns match case-insensitively anywhere in the command (a substring search); anchor with ^ and $ to match the whole command (for example ^drop\b).

Runs of extra whitespace inside a command are collapsed before matching, so padding a command with spaces cannot evade a pattern written with single spaces.

Built-in vs. custom ACLs

Built-in ACLs — the ready-made Database - read-only and Database - mutating SQL command sets — are marked in the Built-in column. You can open them to view their patterns, but you cannot edit or delete them. Create your own ACLs for anything beyond the built-ins.

Common tasks

• Create an ACL — Click Create ACL, give it a name, then Add Pattern for each entry and choose Glob or Regex. Save.
• View a built-in — Click the view icon to inspect its patterns read-only.
• Edit / delete a custom ACL — Use the pencil and delete icons (built-ins do not offer these).

What an operator sees when a rule fires

• A denied command in a shell session raises a Command denied dialog naming the rule and showing the blocked command. The command is never sent to the target — the operator clicks OK and continues.
• A denied connection prevents the session from opening; the operator sees that the session was refused by policy.
• Accepted sessions and commands proceed normally. If the matching rule had Notify or Log on, the event is raised and/or recorded behind the scenes.

Permissions

• View rules, ACLs, and the Policy Log: app.policy.read.
• Create / edit / reorder rules and custom ACLs: app.policy.write.
• Delete rules and custom ACLs: app.policy.delete.

Require approval for access

Choose Approve to gate access to a resource before ordinary rules are evaluated. See Access approval rules for consistent Session and File Transfer configuration, grant lifetime, and rule-change behavior.