Red Hat's developer preview for guarded command execution in the RHEL MCP Server moves AI operations beyond diagnosis. An assistant can propose a command, a gatekeeper evaluates it, a human remains in the approval path, and systemd-run provides runtime isolation. The interesting part is not that a model can type shell commands. It is the layered control model around that capability.
Why it matters in production
A second model is not an independent security boundary by itself. It can misunderstand the same context, approve a syntactically safe command with unsafe business impact, or miss how several harmless steps combine. Policy checks therefore need deterministic constraints: allowed tools, paths, users, resource limits, timeouts, network access, and commands that are never delegated.
Human approval also has to be meaningful. An operator cannot review a long generated pipeline under incident pressure and be expected to notice every side effect. The system should present the exact command, target, required privilege, expected change, and rollback before execution. Approval fatigue is a design failure, not a user-training problem.
Runtime isolation is the third layer. systemd-run can constrain CPU, memory, duration, identity, and process lifetime, but teams must test what the proposed sandbox actually blocks. Start with diagnostic commands on non-production systems, retain full input and output, and compare the assistant's proposal with a known runbook. Remediation should remain deterministic automation until evidence supports a narrower delegated scope.
Practical takeaway
The practical takeaway is that safe AI operations require three distinct controls: deterministic policy, informed human approval, and enforceable runtime isolation. Remove any one and the design depends too heavily on model judgment. The goal is not autonomous root access. It is a bounded path from evidence to action that remains understandable during and after an incident.