Shell Execution Safety
The three-tier command classification system, explained.
TRCAA can execute diagnostic commands directly — kubectl, Proxmox tools, general shell — so the AI can gather evidence without you copy-pasting commands by hand. Every command is classified into one of three safety tiers before it ever runs.
- Tier 1 — Auto-execute
kubectl get/describe/logs, cat, grep, ls
- Tier 2 — User approval
kubectl apply/delete/scale, ssh, systemctl restart
- Tier 3 — Always denied
rm -rf, shutdown, mkfs
Tier 1 — auto-execute
Read-only commands run immediately, no approval needed:
kubectl get / describe / logs cat, grep, ls, ps aux, df -h, uptime pvecm status, pvesh get /cluster/status
Tier 2 — requires your approval
Anything that mutates state pauses and shows an approval modal — full command text, tier badge, and the specific reason it needs a human:
kubectl apply / delete / scale / exec / patch ssh, scp, chmod, chown, systemctl restart/stop/start qm start / stop / restart
Three responses are available: Deny, Allow Once, or Allow for Session.
Tier 3 — always denied
Destructive operations never run, full stop — no approval flow, immediate denial with the reasoning shown:
rm -rf, mkfs, dd, fdisk, shutdown, halt, poweroff, wipefs
Pipes and chains inherit the highest tier
A command isn't judged in isolation — piped and chained commands escalate to the most dangerous operation found anywhere in the chain:
kubectl get pods | grep nginx → Tier 1 (both read-only) kubectl get pods | kubectl delete -f - → Tier 2 (escalates) cat list.txt | xargs rm -rf → Tier 3 (denied entirely)
Additional guardrails
- 30-second command timeout, 60-second approval timeout
- Command text scanned for PII before execution
- No shell interpretation of arguments — passed directly to the process, not through a shell
- Kubeconfig files encrypted at rest (AES-256-GCM)