Governing sudo: OpenHands and Privilege Escalation

Correction note (2026-10-13). An earlier version of this article said an ASK times out with a clean error, that the audit log records the reviewer's decision, and that ssg audit --format json exports a compliance report. In fact the hook waits 20 seconds (45 seconds at most) for a dashboard answer and then hands the call to the agent's own approval prompt. The audit log does not record who answered an ASK, and it records decisions on a best-effort basis (an entry can be dropped if the daemon queue is full, and old rows are deleted at the row caps). ssg audit search --json prints matching rows as JSON. The dashboard page is named Approvals, not a tab. The earlier ~38µs detection-latency figure had no benchmark behind it and was removed: ssg is designed to evaluate locally with a target under 2 ms. Sample output in this article is illustrative, not a recorded run. ssg daemon has no --env flag; edit the project rule files or add a waiver with ssg exceptions add.

Correction note (2026-10-13). An earlier version of the exemption rule in this article used an env SSG_CLIENT == "ci-agent" condition. The rule DSL has no env field and no == operator, so the rule did not load. The exemption now matches one fixed command and has a MESSAGE.

Describe the task

You're using OpenHands to set up a project environment. Mid-task, the agent determines it needs a missing system library and runs:

sudo apt-get install -y libssl-dev

Unattended sudo in an agentic session means the agent can make system-level changes without your knowledge — installing packages, modifying configs, or creating users. SSG's ask-sudo rule routes the call to a human approver before anything happens.

# illustrative sample output
[ASK] bash › sudo apt-get install -y libssl-dev — rule: ask-sudo
Pending human approval in dashboard...

Give SSG context

SSG evaluates OpenHands's shell commands via the SSG MCP Server integration for OpenHands agents.

Required context

rule ask-sudo {
  enabled true
  priority 90
  severity warning
  ASK execution
  IF command STARTS_WITH "sudo "
  MESSAGE "Privilege escalation detected. Confirm before executing."
  PROMPT "Allow this sudo command to run?"
}

Optional context

For a zero-tolerance policy, switch to DENY and require developers to manually approve a pre-approved command list:

rule deny-sudo {
  enabled true
  priority 90
  severity error
  DENY execution
  IF command STARTS_WITH "sudo "
  MESSAGE "sudo is not allowed in agent sessions. Run elevated commands manually."
}

What SSG does

On an ASK decision, SSG pauses the agent's tool call and sends the pending approval to your ssg dashboard. A human reviewer sees the exact command, the rule that matched, and can approve or deny with one click. The hook waits 20 seconds by default (45 seconds at most) for an answer. If nobody answers, the hook hands the call to the agent's own approval prompt.

Approve or deny from the web dashboard

Run ssg dashboard open and go to the Approvals page. You'll see:

• The full command: sudo apt-get install -y libssl-dev
• The rule that flagged it: ask-sudo
• Evaluation: designed to run locally, with a target under 2 ms (a design target, not a measured figure)

Click Approve and the command executes. Click Deny and OpenHands receives a rejection with your message.

Let approved agents skip the check

If a specific system package is known-safe (for example, one your CI image always needs), add an exemption for that exact command:

rule allow-sudo-libssl-dev {
  enabled true
  priority 91
  severity info
  ALLOW execution
  IF command EQUALS "sudo apt-get install -y libssl-dev"
  MESSAGE "Pre-approved system dependency."
}

Higher priority exemptions take precedence over the ask-sudo rule.

Audit all privilege escalations

Each sudo call that a rule evaluates is recorded on a best-effort basis in the local audit log with the command (cut at 8,192 bytes), the matched rule, and a timestamp. An entry can be dropped if the daemon queue is full, and old rows are deleted at the row caps. The log does not record who answered an ASK. List the rows as JSON with ssg audit search --query sudo --json.

How your rule shapes the experience

ASK creates a speed bump without breaking the workflow. DENY creates a hard stop — better for security-sensitive production environments. Start with ASK and migrate specific commands to DENY once you understand the agent's patterns.

Check the rule against your dev container config

If your dev container legitimately installs packages via sudo, edit the rule in the project's .sigmashake/rules files for that repository, or record a waiver with ssg exceptions add <rule-id> --reason <reason-code> --justification <text>.