Detector libraryPrivilege change

Privilege change

The task just asked for more power.

Catch recorded commands that request elevated access.

See the problem. Understand the finding.

English narration with captions.

How it gets overlooked

A routine coding task turns into a command that asks for elevated privileges. That may be necessary. It may also be more access than the task deserves. The moment the command changes is worth seeing.

An agent troubleshooting a missing dependency reaches for sudo. In a long session, that request can sit between ordinary checks and installation output. If you only review the final result, you may never notice the attempted change in authority.

What ClawMetry detects

ClawMetry recognizes privilege related patterns in captured tool arguments. A sudo command can raise a privilege change warning. The finding gives you a reason to review the attempted action in the context of the task.

The difference that changes the finding

Triggering example

sudo apt-get install jq

Warning finding

Quiet comparison

git status

No finding for this detector.

The checked example uses a sudo package installation command and raises a warning. An ordinary Git status command stays quiet. The signal concerns the command that was observed. It does not establish that the privilege request succeeded.

Inspect the detector result
{
  "kind": "privilege_change",
  "severity": "warning",
  "evidence": {
    "patterns": [
      "ran a command as root"
    ],
    "matches": 1,
    "irreversible": [],
    "command_sketch": "sudo apt-get",
    "observed": "tool_arguments"
  }
}
Download inputs and complete results (JSON)
How the example was checked

These examples evaluate the published detector with authored event data or disposable configuration files. The videos illustrate those behaviors. They are not recordings of live agents or the product interface. No command in the examples was executed.

The result establishes behavior for these inputs. It does not establish runtime ingestion, prevention or a real compromise. Inspect the pinned source contract.

What to check next

Check whether elevated access was actually needed. Inspect the target, the command and any approval involved. Prefer the narrowest access that completes the task, and verify the result using the runtime and system evidence available to you.

  1. Check why access is needed
  2. Inspect target and approval
  3. Verify the resulting state

What this signal establishes

This detector reads recorded commands, not resulting operating-system privileges. It does not itself deny elevation.

Keep the important moments visible.

Follow agent activity, inspect findings and decide what needs your attention.