Risk Assessment

Suvadu automatically classifies every AI agent command by risk level — from Safe to Critical — so you can quickly identify potentially dangerous operations and audit agent behavior.

How It Works

Every command executed by an AI agent is analyzed against a set of pattern-matching rules that assess its potential impact. Views, reports, and risk checks assess command text with the configured rules; the risk label is not a fixed classification stored at recording time. Risk levels are based on the command text and its arguments, considering factors like:

Whether the command can delete or overwrite data
Whether it modifies system configuration or permissions
Whether it installs software or dependencies
Whether it affects version control history
Whether it's a read-only operation

Risk Levels

Suvadu uses five risk levels. Each level has a visual indicator that appears in the Agent Dashboard, Agent Stats, and Agent Reports.

Level	Indicator	Description	Examples
Critical	`!!`	Irreversible destructive operations that can cause catastrophic data loss or system damage	`rm -rf /`, `DROP TABLE`, `git push --force origin main`, `terraform destroy`, `DELETE FROM users` with no `WHERE`
High	`!!`	Potentially dangerous operations that modify permissions, install software, or overwrite configuration	`chmod 777`, `npm install express`, `pip install requests`, `kubectl delete pod web-1`, `git checkout .`, config file overwrites
Medium	`~`	Operations that modify state and may be difficult to undo	`git reset`, `docker run`, environment variable modifications
Low	`.`	Minor modifications that are generally safe and easy to undo	File writes, git branch operations, installing what the project already declares (`npm install`, `npm ci`, `pip install -r requirements.txt`)
Safe	`ok`	No configured risk pattern matched; this is not a guarantee of no side effects	`git status`, `ls`, `cargo test`, `grep`

Where Risk Levels Appear

Risk assessment data is surfaced throughout Suvadu's AI agent features:

Agent Dashboard — every command in the timeline shows its risk indicator. Press Ctrl+R to filter to Medium and above.
Agent Stats — each agent's analytics card includes a risk breakdown and a table of high-risk commands.
Agent Reports — every command in the report is annotated with its risk level, plus an aggregate risk summary.
Prompt Explorer — commands triggered by each prompt show their risk levels in the detail view.
MCP Server — the assess_risk tool lets AI agents check risk levels programmatically.

MCP Pre-Execution Risk Check

AI agents that connect to Suvadu's MCP server can call the assess_risk tool before executing a command to check its risk level. This enables a safety workflow where the agent:

Receives a task that requires running a command
Calls assess_risk with the command text
Gets back the risk level and a description of the potential impact
Decides whether to proceed, ask for confirmation, or choose a safer alternative

The MCP connection is configured by suv init claude-code, suv init cursor, or suv init codex. The client decides whether to request an assessment; MCP does not automatically block commands.

Since 0.5.1: Every Command of a Line

The rules used to look at a line as a whole, so a dangerous command after && or inside bash -c could slip past while a harmless one tripped a rule. Since 0.5.1 a line is split into its commands first — on ;, &&, ||, |, & and newlines outside quotes — and each is rated on its own, after wrappers such as sudo, env, VAR=x, nohup or xargs. The text handed to bash -c, ssh host, eval, su -c, find -exec, a here-doc and a $(…) substitution is checked as a command line too. The line's level is its riskiest command.

Every spelling of recursive rm (-rf, -fr, -Rf, -r) and of force push (-f, +branch, --force-with-lease) is caught.
New rules for kubectl delete, terraform destroy, find -delete, shred, truncate, docker system prune, git checkout . / git restore ., SQL TRUNCATE and DELETE without WHERE, crontab -r and diskutil erase*.
Fewer false alarms. chmod 755, pip install -r requirements.txt and ./build.sh are no longer rated high enough to block.
Mentions are not actions. The arguments of a program that only searches, prints or records strings (grep, rg, echo, printf, git commit -m, git log, man) are a mention. So in grep -r "rm -rf" . && rm -rf build the grep is fine and the second command is still flagged, as are bash -c "rm -rf /", ssh host 'rm -rf /srv' and psql -c "drop table users".

What a splitter cannot see stays unseen: an alias or function defined earlier, a command held in a variable, the contents of a script file. A command built at runtime (eval "$CMD", a decoded payload) can only be reported as indirection, never as what it will become.

New in 0.4.0: Obfuscation and Custom Rules

Risk checks now flag eval, base64 decoding piped to a shell, and command substitution around certain destructive or network commands. The classifier also considers agent.risk_extra_patterns: regex rules with a risk level and description. The highest matching risk is used.

[[agent.risk_extra_patterns]]
pattern = '^internal-deploy\s+production\b'
level = "critical"
description = "Production deployment needs review"

agent.risk_ignore_patterns suppresses findings for matching commands. Configure these rules globally or use a project overlay for CLI checks.

Check Before Execution with Guard

suv guard --block-at high 'npm install example-package'

Command Guard assesses the quoted text without executing it. It exits 2 at or above the chosen threshold (High by default), or 0 otherwise. Wire that result into a script, CI job, or Zsh widget to control execution.

Filtering by Risk

To quickly focus on potentially dangerous agent activity:

In the Agent Dashboard, press Ctrl+R to toggle the risk-only filter, which hides Safe and Low commands and shows only Medium, High, and Critical.
In Agent Stats, the high-risk commands table shows only High and Critical commands.
In Agent Reports, scan the risk summary at the top for a quick count of commands at each level.

Note: Risk assessment is a heuristic based on command patterns. It provides a useful signal for auditing but is not a security boundary. Always review agent activity with your own judgment, especially for Critical and High risk commands.