Set Execution Boundaries for AI in the Shell

Tier: Core · Workflow area: Scripting & automation · ~30 minutes

This playbook produces a one-page execution policy for AI in your shell — what the assistant may run unprompted, what it may only suggest, and what it must never touch — then wires that policy into the tools' actual permission mechanisms so it is enforced by configuration, not intention.

When to use

• Before first serious use of any terminal AI on a machine that can reach production — which, with admin workstations, is every machine.
• Team adoption momentstwo techs already use Warp AI ad hoc; the desk is about to standardize. The policy turns individual habits into a shared, auditable boundary.
• After a near-missan AI-suggested command was run without reading and did something surprising; the retro action is this playbook.

When NOT to use

• As a ban in disguise. A policy whose every row is "never" just drives usage underground; if the real decision is "not yet", say that and revisit quarterly.
• On isolated lab machinesa sandboxed VM with no production reach is exactly where unrestricted AI experimentation should happen; scope the policy to machines that matter.
• As a substitute for identity controlsthe policy governs the AI's latitude, not yours; least-privilege accounts, PIM/JIT elevation and jump hosts still do the heavy lifting.

The recipe

1. 1.

   Draft the three-tier policy. One page, three lists, written for your estate. Have the model draft it from your context and then edit:

   Copy

   Draft a terminal-AI execution policy for an IT ops team. Three tiers:
   
   AUTO-ALLOWED (AI may execute without per-command approval):
   read-only diagnostics — get/list/show/test commands, log reads,
   status queries. Nothing that writes.
   
   SUGGEST-ONLY (AI proposes; human reads, edits, runs manually):
   anything that changes state on a single object; anything piping to
   a shell; installs; service restarts on non-critical hosts.
   
   NEVER (AI neither runs nor is asked to compose against live targets):
   bulk/destructive ops (mass delete, format, forced moves), identity
   and security-config changes, production database writes, firewall
   rules, anything touching backup infrastructure, certificate ops.
   
   Context: Windows-heavy estate, M365 + on-prem AD, RMM-managed.
   Format as a table: operation class | tier | example commands | why.
   

   Edit ruthlessly — the model's draft is generic; your NEVER list must name your crown jewels (the backup server, the PAM vault, the domain controllers).

2. 2.

   Wire the policy into Claude Code. Permission rules live in settings; encode the tiers directly:

   Copy

   {
     "permissions": {
       "allow": [
         "Bash(Get-*)", "Bash(kubectl get *)", "Bash(git status)",
         "Bash(Test-NetConnection *)"
       ],
       "deny": [
         "Bash(Remove-Item * -Recurse *)", "Bash(rm -rf *)",
         "Bash(Set-ADUser *)", "Bash(New-NetFirewallRule *)"
       ]
     }
   }
   

   Everything not allowed prompts for approval — which is your suggest-only tier. Deny rules are the NEVER list's hard backstop.

3. 3.

   Wire it into AI Shell and Warp. Microsoft AI Shell keeps suggestion and execution separate by design — the assistant proposes into the prompt line; your policy rule is "read before Enter, always, no exceptions for long commands." In Warp, review the AI settings: disable any autonomous-execution features beyond your AUTO-ALLOWED comfort, and turn off sharing/telemetry options your data policy requires. Document the exact settings per tool in the policy page.

4. 4.

   Add the two behavioral rules no config can enforce. Rule one: read the whole command before it runs — especially generated one-liners with pipes into sh, Invoke-Expression, or redirects; these are the suggest-tier's escape hatches. Rule two: never paste secrets into the AI pane — the shell assistant sees your terminal context; credentials go through the secret store, not the conversation.

5. 5.

   Trial the boundary for two weeks with a log. Each tech notes near-misses: commands the AI ran that surprised them, suggest-tier commands they wish were auto-allowed, NEVER-tier requests that felt legitimate. A real log entry:

   Copy

   08-04 | Claude Code proposed "Restart-Service spooler" during print
   triage — prompted for approval as designed. Fine. But it batched it
   with a Get- command in one line, so approval covered both. Rule
   added: no compound commands mixing tiers.
   

6. 6.

   Review and ratify. Adjust tiers from the log, fix the config to match, and have the team lead sign the page. The signed policy goes next to the AI-usage policy (pb-49); new starters get it in the enablement pack (pb-20).

7. 7.

   Re-review on every tool update. Terminal-AI capabilities move fast; a tool update that adds autonomous features silently expands your AUTO tier. Diff the settings after each significant update — put it on the patch-cycle checklist.

Make it yours

• Locked-down enterpriseroute all terminal-AI use through a designated admin workstation profile where the config is centrally managed; the policy file ships via Intune, not goodwill.
• MSPone policy, per-client NEVER lists: client A's untouchables differ from client B's. The AI tool's per-project config (Claude Code's project settings) maps neatly to per-client boundaries.
• Linux-first teamsame tiers; auto-allow systemctl status, journalctl, df, deny dd, mkfs, iptables -F, and treat curl | bash as NEVER-tier composition regardless of target.

Quality check

• Config matches paper. Someone other than the author reads the policy page and checks each tool's actual settings against it; drift between the two is the failure mode.
• The NEVER list is concrete. "Be careful with destructive commands" is not a policy; "no AI-composed commands against DC01/DC02, the Veeam server, or the PAM appliance" is.
• Approval fatigue is monitored. If techs approve every prompt reflexively by week three, the suggest tier has failed — promote the genuinely-safe frequent commands to AUTO so approval stays meaningful.
• Compound commands split by tier. One approval covers one tier; mixed read/write one-liners are rewritten before approval.