UNPKG

aiwg

Version:

Deployment tool and support utility for AI context. Copies agents, skills, commands, rules, and behaviors into the paths each AI platform reads (Claude Code, Codex, Copilot, Cursor, Warp, OpenClaw, and 6 more) so one source of truth works across 10 platfo

221 lines (166 loc) 7.88 kB
# Ops Safety Rules **Enforcement Level**: CRITICAL **Scope**: All operational commands, agent-executed procedures, and infrastructure changes ## Principle Operational safety is non-negotiable. Agents must detect interactive commands they cannot handle, gate destructive operations behind human confirmation, assess blast radius before execution, and never cross host boundaries without explicit authorization. A single unguarded `rm -rf` or silent `fdisk` can destroy production data in seconds. ## Mandatory Rules ### Rule 1: Detect Interactive Commands Commands that require interactive input (password prompts, confirmation dialogs, TUI interfaces) MUST be flagged for human execution. Agents cannot type passwords or respond to interactive prompts safely. **Commands requiring human execution**: ```bash # Password/authentication prompts sudo <anything> # May prompt for password cryptsetup luksOpen # Requires passphrase passwd # Interactive password entry ssh-keygen # Prompts for passphrase mysql -p # Password prompt # Interactive editors/TUIs fdisk /dev/sdX # Interactive partitioning cfdisk, parted # Interactive disk tools visudo # Opens editor systemctl edit # Opens editor nmtui # TUI network config ``` **Required agent behavior**: ```markdown INTERACTIVE COMMAND DETECTED The following command requires human execution: sudo cryptsetup luksOpen /dev/sda2 vault Reason: Requires LUKS passphrase entry Action: Please run this command manually, then confirm completion. ``` **Non-interactive alternatives when available**: ```bash # Instead of interactive sudo, use pre-authorized patterns: # If already root or passwordless sudo configured: sudo -n systemctl restart nginx # -n = non-interactive, fails instead of prompting # Instead of interactive fdisk, use scriptable sfdisk: sfdisk /dev/sdX < partition-layout.dump ``` ### Rule 2: Gate Destructive Operations Destructive operations MUST NOT be executed without explicit human confirmation. Present the command, its effects, and blast radius assessment before proceeding. **Always-gated commands**: ```bash # Filesystem destruction rm -rf <path> # Recursive forced delete shred # Secure file destruction mkfs.* # Filesystem creation (destroys existing data) dd if=* of=/dev/* # Raw disk write # Partition/disk operations fdisk, parted, gdisk # Partition table changes lvremove, vgremove # LVM destruction mdadm --stop, --remove # RAID destruction # Network/firewall iptables -F # Flush all firewall rules ufw reset # Reset firewall to defaults ip link delete # Remove network interface nmcli con delete # Remove network connection # Service/system systemctl disable <svc> # Disable service at boot systemctl mask <svc> # Prevent service from starting systemctl stop <critical># Stop critical services (defined per host) reboot, shutdown, poweroff update-grub, grub-install# Bootloader changes # Package management (destructive) apt purge, apt autoremove dnf remove, rpm -e # Database DROP DATABASE, DROP TABLE TRUNCATE TABLE ``` **Required gate format**: ```markdown DESTRUCTIVE OPERATION HUMAN CONFIRMATION REQUIRED Command: rm -rf /var/lib/postgresql/14/ Effect: Permanently deletes all PostgreSQL 14 data Blast radius: CRITICAL all databases on this host Reversible: NO (unless backup exists) Backup status: [Check: ls -la /backup/pg/latest/] Proceed? (requires explicit "yes" from human) ``` ### Rule 3: Assess Blast Radius Every operation must be classified by blast radius BEFORE execution: | Level | Scope | Examples | Gate | |-------|-------|----------|------| | **CRITICAL** | Multi-host, data loss, unrecoverable | `rm -rf /`, firewall flush on gateway, DNS record deletion | Human approval + dry-run + backup verification | | **HIGH** | Single host, service outage, recoverable | Service restart, package upgrade, config change | Human approval + dry-run | | **MEDIUM** | Single service, brief disruption | Log rotation, cache clear, temp file cleanup | Human notification | | **LOW** | No disruption, read-only, monitoring | Status checks, log reads, disk usage | No gate | **Classification rules**: - Affects more than one host minimum CRITICAL - Destroys data without backup CRITICAL - Causes service outage minimum HIGH - Modifies boot/network/auth config minimum HIGH - Read-only or informational LOW ### Rule 4: Dry-Run First for High/Critical Operations Operations classified HIGH or CRITICAL MUST attempt a dry-run before actual execution when the tool supports it. **Dry-run patterns**: ```bash # rsync rsync -avz --dry-run source/ dest/ # apt apt install --dry-run package-name # rm (list instead of delete) find /path -name "*.tmp" -print # Review before -delete # iptables iptables -L -n # List before -F # systemctl systemctl list-dependencies svc # Check deps before stop # Ansible ansible-playbook --check playbook.yml # Terraform terraform plan # Before apply ``` ### Rule 5: Never Cross Host Boundaries Without Confirmation Configuration from one host MUST NOT be applied to another host without explicit human confirmation. Hosts have unique hardware, network configurations, disk layouts, and service assignments. **FORBIDDEN**: ```bash # NEVER copy one host's config to another without review scp gateway-01:/etc/network/interfaces compute-03:/etc/network/interfaces ansible-playbook site.yml -l "all" # Applying broad changes silently ``` **REQUIRED**: ```markdown CROSS-HOST OPERATION DETECTED Source host: gateway-01 Target host: compute-03 File: /etc/network/interfaces These hosts have different: - Network interfaces (gateway-01: eno1,eno2; compute-03: enp0s31f6) - IP assignments (gateway-01: 10.0.0.1; compute-03: 10.0.0.42) - Roles (gateway vs compute) Applying gateway-01's network config to compute-03 will likely cause network loss on compute-03. Proceed only with explicit human confirmation. ``` ### Rule 6: Token Security in Ops Contexts Follows the core token-security rule with ops-specific additions: ```bash # REQUIRED: Heredoc pattern for scoped token lifetime bash <<'EOF' TOKEN=$(cat ~/.config/gitea/token) curl -s -H "Authorization: token ${TOKEN}" \ "https://git.integrolabs.net/api/v1/repos/roctinam/sysops/issues" EOF # Token variable does not persist after heredoc # FORBIDDEN: Tokens in command history export GITEA_TOKEN="abc123..." # Persists in shell history curl -H "Authorization: token abc123" ... # Visible in history ``` **Ops-specific additions**: - Never store tokens in operational documents or runbooks - Never include tokens in issue bodies or commit messages - SSH keys and certificates follow the same rules as API tokens - Secrets in systemd unit files must use `LoadCredential=` or `EnvironmentFile=` ## Detection - Agent executing a command from the interactive list without flagging - Destructive command executed without human confirmation gate - Missing blast radius classification in operation plan - High/critical operations without preceding dry-run - Cross-host config application without human confirmation - Tokens appearing in procedure documents, issue bodies, or commit messages ## Enforcement - **On violation**: IMMEDIATE HALT stop execution, report the violation, await human instruction - **Severity**: CRITICAL violations can cause data loss, outages, or security breaches - **Recovery**: Review what was executed, assess damage, restore from backup if needed, add missing gates to the procedure - **Escalation**: Any CRITICAL blast radius operation that was executed without approval must be reported as an incident