Session Recording vs Command Filtering: Detective and Preventive Privileged Controls Compared

Recording a privileged session tells you what an administrator did, while filtering commands tries to stop them doing it, and most programmes overestimate what either control delivers on its own. Session recording is a detective control: it captures keystrokes, commands, output or screen video so actions can be reviewed, alerted on and used as evidence. Command filtering is a preventive control: it compares each command against an allow or deny policy and blocks what is not permitted. This guide compares them as control designs, not products: threat model, bypass, privacy cost and combined use, for PAM owners, platform engineers and auditors. How a session broker works end to end is in the Privileged Session Management Guide, and this page does not repeat it.

Key takeaways

• Short answer: record broadly, filter narrowly. Recording suits wide, interactive and unpredictable administration; command filtering only holds where the permitted task set is small and well defined, so use it as a constrained endpoint, not a blocklist over a full shell.
• Deny lists over a shell do not hold. The sudo project itself warns that subtracting commands from ALL is trivially circumvented by copying the command to a different name, and that shell escapes in editors and pagers bypass command control.
• Allow lists work when the endpoint is the control. PowerShell Just Enough Administration (JEA), OpenSSH ForceCommand and sudo rules naming exact binaries and arguments prevent misuse because there is no general shell to escape into.
• Recording without review is storage, not a control. Its value depends on indexing, risk-scoring and someone acting on alerts within hours, and on recordings that cover every path to the target.
• Both need privacy and secrets governance. Recordings and input logs capture passwords and personal data; the UK ICO lists keystroke monitoring as high-risk processing that needs a data protection impact assessment.

What each control is

Session recording: capture and review

Session recording captures the content of a privileged session. NIST SP 800-53 Rev. 5 control AU-14 (Session Audit) describes the capability to record, view, hear or log the content of a user session. Implementations differ in what they capture, and the capture method decides what you can later search:

• Terminal input and output logging: sudo's log_input and log_output options run the command in a pseudo-terminal and log what the user typed and what the terminal displayed. Both are off by default. Logs go to iolog_dir (default /var/log/sudo-io), can be replayed with sudoreplay and can be sent to a central sudo_logsrvd server through log_servers.
• Command and script logging: PowerShell script block logging writes the content of every script block processed to event ID 4104 in the PowerShell Operational log, whether run interactively or by automation.
• Brokered session capture: a PAM gateway or cloud session service records the session as it passes through. AWS Systems Manager Session Manager logs commands and output to CloudWatch Logs or S3 depending on session preferences; Azure Bastion (Premium SKU) records graphical RDP and SSH sessions to a blob container you own.
• Screen video: graphical recording of RDP or web console sessions. It is the only option for GUI tools and the hardest to search.

Command filtering: decide before execution

Command filtering evaluates each requested command before it runs and allows, blocks, or holds it for approval. It appears in three forms, and their strength differs sharply:

• Allow-list endpoints: the user never receives a general shell. JEA exposes only the cmdlets, functions and external commands named in a role capability file, runs them under a virtual account, and writes transcripts. OpenSSH ForceCommand replaces whatever the client asked for with a fixed command and stores the original request in SSH_ORIGINAL_COMMAND for a wrapper to validate.
• Per-command privilege rules: sudoers rules that grant named binaries with named arguments, plus tags such as NOEXEC (stops a dynamically linked program launching further commands where the platform supports it) and INTERCEPT (validates and logs programs spawned by the permitted command, sudo 1.9.8 or later).
• Gateway pattern matching: a PAM proxy inspects the command line in an SSH, database or web session and blocks strings that match a deny pattern, or flags them for live supervision.

Side-by-side comparison

Threat model for each option

Session recording: what it defends and what it does not

Recording defends against misuse that someone will later look at: it deters named individuals, holds vendors accountable, and supports incident reconstruction and evidence. The NCSC's secure system administration guidance treats recorded admin actions feeding an auditing function as a deterrent against insider misuse and a source of evidence.

It does not prevent anything in real time unless someone supervises live or an analytic raises an alert that triggers session termination. Against an external actor with a stolen admin account, it shows the damage afterwards. It also misses whatever does not pass through the capture point. AWS states that Session Manager logging is not available for sessions that connect through port forwarding or SSH, because the service is only a tunnel for that traffic. Azure Bastion records sessions through the portal but not through the native client.

Command filtering: what it defends and what it does not

Filtering defends against actions inside an authorised session that fall outside the role: a support engineer restarting services they should not touch, an operator running a destructive command against production by mistake, or a contractor browsing data beyond their task.

It does not defend against a user who wants to get around it and holds a general shell. The sudoers manual is explicit: subtracting commands from ALL with ! "rarely works as intended", a user can circumvent it by copying the command to a different name, and restrictions such as excluding shells should be treated as advisory and backed by policy. It also notes that restricting users to programs without shell escapes is often unworkable, and that shell built-ins cannot be intercepted. A string-matching filter is a guard rail for the careful, not a barrier for the determined.

How filtering is bypassed, and what closes each path

These are the classes of bypass defenders need to plan for. They are described at design level so you can test for them in an assessment; no attack steps are given.

Recording has its own bypass classes: connecting directly to the target instead of through the broker, using a protocol the broker only tunnels, working at the console or out of band, and disabling or editing local logs (ATT&CK T1685 Disable or Modify Tools). The fixes are network enforcement so the broker cannot be skipped (NIST SC-7(15) routes networked privileged access through a dedicated managed interface), central log forwarding before local tampering is possible, and alerts on privileged logons the broker cannot explain. See Agent-Based vs Agentless PAM.

Privacy, secrets and legal exposure

• Personal data in recordings: in the UK, the ICO's guidance on monitoring workers says a DPIA is required for monitoring likely to be high risk and lists keystroke monitoring as an example; workers must be told before monitoring starts, consent is usually inappropriate in employment, and legitimate interests needs a documented assessment. Retention must rest on a documented business need.
• Secrets in input logs: sudo warns that input logs can capture passwords even when they are not echoed and are stored unencrypted, and its log_passwords option is on by default. AWS recommends disabling terminal echo when entering sensitive data in Session Manager. PowerShell script block logs can contain credentials, so Microsoft recommends Protected Event Logging, which encrypts events with a certificate whose private key is kept off the logging hosts.
• Access to recordings is privileged access: limit playback to a small reviewer group (NIST AU-9(4)), log every playback, and keep recordings in storage administrators of the recorded systems cannot alter. Azure documents that Bastion recording does not support immutable storage policies or blob versioning on the container, so plan protection of the storage account itself.
• Filtering logs: decisions are low risk; full arguments of blocked commands can hold secrets, so treat them like recordings.

Where works councils, unions or national employment rules apply, involve them before switching on recording. This page is not legal advice.

Choosing: decision guidance

Small organisations can start with native features: central sudo I/O logging, PowerShell script block logging to the SIEM, and a few JEA or ForceCommand endpoints. Large organisations usually add a PAM gateway for recording and supervision, while still moving frequent tasks onto allow-list endpoints. Requirements for buying a platform are in the PAM Buyer's Guide.

Combined design: how the two fit together

The two controls are strongest when each covers the other's blind spot:

1. Reduce who holds a shell. Move every recurring task onto an allow-list endpoint.
2. Record every remaining privileged session. Capture commands as text where possible, video only for GUI, and forward centrally in real time.
3. Use deny patterns as alerts first. On full shells, configure the riskiest patterns (mass deletion, disabling logging, changing audit policy, adding admin group members) to alert and notify a supervisor rather than block. Promote a pattern to blocking only when false positives are near zero.
4. Use filter hits as review triggers. A flagged command marks the recording for priority review. The Privileged Session Review Checklist gives a review routine.
5. Escalate high-impact actions to a person. Destructive or irreversible commands can be held for a second approver, as described in Dual control and four-eyes approval for privileged and agent actions.

Worked scenario: hosting team with a managed service partner

A mid-sized company runs 400 Linux and 150 Windows servers. Twelve internal engineers have full administration; a managed service partner provides out-of-hours support with eight named staff. Audit asked for command blocking on all privileged sessions.

• Partner support: 80% of partner tickets are restarts, disk clean-ups and log collection. The team builds six JEA endpoints and four ForceCommand wrappers that accept only those actions with validated parameters. Partner staff lose full admin rights; other tickets go through the recorded gateway.
• Internal engineers: blocking full shells would be bypassed and break scripts, so the team records all sessions through sudo I/O logging and the gateway, sets alert patterns for disabling audit logging and adding admin group members, and reviews flagged sessions within one business day.
• Privacy: a DPIA is completed, engineers and partner staff are told before recording starts, recordings are kept for a defined period with playback limited to two reviewers, and log_passwords is turned off.
• Result: audit receives a description of which tasks are prevented, which are recorded and how flagged sessions are reviewed, not a blanket claim of blocking.

The figures in this scenario are illustrative.

Where identity fits

Both controls depend on knowing who ran the command. Shared root or local administrator accounts make recordings unattributable and make per-role filtering impossible, so personal admin accounts or brokered sessions that tie a human to each action come first. A service account or AI agent with an interactive shell is unreviewable; one bound to a ForceCommand or JEA endpoint, or to allow-listed tools, is preventive and auditable. See the JIT Access Guide for removing standing privilege first.

How to implement: phased approach

1. Inventory (weeks 1 to 4): every privileged access path per target class, and the twenty most frequent privileged tasks from tickets.
2. Turn on native recording in audit mode (weeks 2 to 6): enable sudo I/O logging with a central log server, PowerShell script block logging with Protected Event Logging, and gateway recording; confirm central arrival and no captured passwords.
3. Complete the privacy work before production capture: DPIA, worker notice, retention schedule, reviewer group.
4. Build allow-list endpoints for frequent tasks (weeks 6 to 12): pilot with one team, run in parallel with old access for two weeks, then remove the full role. Keep the old role disabled for a rollback window.
5. Add deny patterns in alert-only mode: tune for four weeks, then switch only zero-false-positive patterns to blocking, with a documented exception route.
6. Close bypass paths: network rules so targets accept administration only from the broker, forwarding disabled on restricted SSH roles, alerts on direct logons.
7. Test regularly: have an authorised assessor test each bypass class against restricted roles.

Detection and measurement

Log session start and end (user, target, path, ticket), commands on recorded sessions, filter decisions with rule ID, playback, and changes to sudoers, JEA role capability files (Microsoft advises only highly trusted administrators edit these) and gateway policy.

• Brokered coverage: share of privileged logons on in-scope targets that used the recording path.
• Review latency: median time from a flagged session to completed review.
• Full-shell population: number of people and service accounts holding unrestricted shells, trending down as endpoints replace them.
• Filter precision: share of blocks that were confirmed policy violations rather than false positives.
• Bypass test results: classes tested, and how many were caught by prevention, detection or neither.
• Secrets in recordings: count of recordings found to contain credentials, which should fall to zero.

Common failure patterns

• A deny list on a full shell sold as prevention: auditors are told commands are blocked, but renamed binaries, scripts and shell escapes defeat it, as the sudo documentation warns.
• Recordings nobody watches: years of video, reviewed only after an incident.
• Recording only the front door: the gateway records, but direct SSH, port-forwarded sessions and consoles remain open and unrecorded.
• Passwords in the archive: input logging captures credentials typed during sessions, turning the recording store into a credential store.
• Permissive allow lists: JEA roles with wildcard cmdlet names or Start-Process, or sudo rules granting an interpreter, which recreate a full shell.
• No privacy groundwork: recording switched on without a DPIA or worker notice, then paused by legal.

Framework mapping

CIS Controls v8.1 safeguards 5.4 (restrict administrator privileges to dedicated administrator accounts) and 8.5 (collect detailed audit logs) also apply.

Decision checklist

• Can the task be a fixed set of commands with validated parameters? Then build an allow-list endpoint.
• Does every path to the target pass through the recording point, including tunnels and consoles?
• Who reviews flagged sessions, and within what time?
• Is a DPIA complete and have workers been told before recording starts?
• Are passwords kept out of input logs and recordings, and is playback limited and logged?

Practitioner checklist

• Replace frequent delegated tasks with JEA, ForceCommand or exact-path sudo rules, and remove the full role afterwards.
• Never rely on ! negation in sudoers or wildcard cmdlet names in JEA for security.
• Enable sudo I/O logging to a central sudo_logsrvd server and turn off log_passwords.
• Enable PowerShell script block logging with Protected Event Logging and forward event 4104 to the SIEM.
• On ForceCommand roles set DisableForwarding yes and PermitTTY no.
• Run deny patterns in alert mode first and promote only precise patterns to blocking.
• Limit playback to a named reviewer group and log each playback.
• Test filtering bypass classes at least yearly with an authorised assessor.

Standards and references

• NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
• Sudo project: sudoers manual (shell escapes, security notes, I/O logging)
• Microsoft Learn: JEA role capabilities
• Microsoft Learn: about_Logging_Windows (script block logging and Protected Event Logging)
• OpenBSD: sshd_config manual (ForceCommand, DisableForwarding)
• NCSC: Secure system administration, use privileged access management
• ICO: Data protection and monitoring workers
• AWS: Session Manager logging

Related NHI Mgmt Group resources: Privileged Session Management Guide, Agent-Based vs Agentless PAM, Endpoint Privilege Management Guide, Securing the jump host and bastion itself, PAM Buyer's Guide.