Tool Permissioning Tiers

PROJECT CONTEXT:
Every tool in my agent runs with the same authority: reading a file and deleting a directory are one keystroke apart. Analyses of production harness permission models show tiered systems - risk-classed tools with different approval requirements.

GOAL:
Implement permission tiers across my toolset: risk classification, tier enforcement in the dispatch path, session grants, and a complete decision log.

REQUIREMENTS:
- Every tool (and risky parameter pattern) classified into tiers: safe, session, ask, never
- Tier enforcement in the tool dispatch path - not in tool code, not in the prompt
- Session grants: approved once, allowed for the session, revocable
- Parameter-sensitive rules: the same tool can be safe or dangerous by arguments
- An append-only decision log of every permission check and outcome

CONSTRAINTS:
- Deny-by-default: unclassified tools land in 'ask' until reviewed
- The model must never be the enforcement point - it can request, not grant

DEFINITION OF DONE:
- A read-only tool runs without friction; a destructive command requires approval
- The same shell tool is auto-allowed for ls and gated for rm - parameter rules work
- A denied request returns a clean explanation to the model, and the loop continues
- The decision log reconstructs every grant and denial with context

COMMON FAILURES TO AVOID:
- 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