DocsSecurityCommand Safety & Risk Classification
Back to Docs
Security

Command Safety & Risk Classification

Understand YeePilot's risk labels, review flow, security modes, and the settings that keep execution under control.

Last updated: May 15, 2026

The Main Idea

Before YeePilot executes a command, it evaluates what kind of action it is and how risky it looks. This is separate from the AI's wording. Even if a prompt is confusing or malicious, the safety layer still checks the actual command.

Risk Levels

SAFE

Read-only inspection commands such as:

  • ls
  • cat
  • df
  • ps
  • systemctl status

MODERATE

Routine changes that still deserve review, for example:

  • creating directories
  • moving files
  • restarting a service
  • package installation

DANGEROUS

High-impact changes such as:

  • destructive deletes
  • critical permission changes
  • firewall rewrites
  • filesystem or disk tools
  • risky edits to sensitive config

BLOCKED

Patterns YeePilot refuses to run at all, such as catastrophic filesystem wipes or obviously abusive shell patterns.

What Controls Safety For End Users

Three settings matter most:

security.mode

yaml
security:
  mode: strict

Available values:

  • strict
  • moderate
  • permissive

This changes how cautious the safety layer is about risky operations.

security.require_confirmation

yaml
security:
  require_confirmation: true

This is the user-facing "always ask me before running things" switch.

ai.autonomy_profile

yaml
ai:
  autonomy_profile: guarded

Available values:

  • high
  • guarded
  • strict_review
  • ultra

Autonomy does not replace safety mode. It works with it.

Production or sensitive work

yaml
security:
  mode: strict
  require_confirmation: true
 
ai:
  autonomy_profile: strict_review

Normal daily work

yaml
security:
  mode: moderate
  require_confirmation: true
 
ai:
  autonomy_profile: guarded

Custom Blocked Patterns

You can add your own hard blocks:

yaml
security:
  blocked_patterns:
    - "shutdown"
    - "reboot"
    - "DROP DATABASE"

Use this when your environment has commands that should never be run through YeePilot.

Audit Logging

YeePilot can keep a tamper-aware local audit log of what happened:

yaml
security:
  audit_log_path: ~/.yeepilot/audit.log
  audit_max_size_mb: 10
  audit_max_archives: 50

The Neural HUD Audit tab is the easiest way to inspect this activity during normal use.

Password-Processing Commands And Sandbox

If a command needs password input while sandboxing is active, YeePilot may refuse it. In practice, that means:

  • prefer SSH keys over passwords
  • keep credentials in the Vault where appropriate
  • temporarily adjust sandbox behavior only when you understand why the task needs it

Best End-User Advice

  • use strict plus strict_review for anything important
  • read command proposals before approving them
  • keep audit logging enabled
  • use custom blocked patterns for your own environment-specific no-go actions