Step 1 of 4
Classify the toolset by risk
Reversibility and blast radius decide the tier.
Classify every tool. Tiers: SAFE (read-only, no side effects: file reads, searches, listings) - auto-allow; SESSION (mutating but contained and reversible: file edits in the workspace, git commits) - first use asks, approval covers the session; ASK (consequential or hard to reverse: shell commands by default, network calls, package installs) - every use asks unless a narrow rule says otherwise; NEVER (catastrophic or out of scope: credential file access, force-push, bulk deletion) - blocked outright. For parameterized tools, write argument rules: run_command with a read-only known-safe binary (ls, cat, git status) may drop to SAFE; anything matching destructive patterns (rm -rf, DROP TABLE, force flags) escalates to ASK or NEVER. Deliver the classification table with a one-line justification per tier assignment.
Expected after this step
A complete tiered classification with parameter rules.
Should not happen
- ✕All-or-nothing permissions: either everything asks or nothing does
- ✕Enforcement via prompt instructions the model can rationalize around
- ✕Session grants that never expire and quietly become permanent
- ✕No log, so nobody can answer 'what approved this?' after an incident
Verify before continuing
Do not move on until every check is true. The complete button stays locked until then.
Do not continue if…
- !All-or-nothing permissions: either everything asks or nothing does
- !Enforcement via prompt instructions the model can rationalize around
- !Session grants that never expire and quietly become permanent
- !No log, so nobody can answer 'what approved this?' after an incident
If the AI messes this up
Use this when the AI fakes progress or breaks the feature. It forces a real fix.
Everything landed in ASK, which users will not tolerate. Re-classify with the reversibility test: if git or a file restore undoes it in seconds, SESSION is usually right - reserve ASK for real consequence.