Context

Relates to PR #249 (trust context and audience policy) and the runaway tool loop
fix in #350 / PR #351.

Current security model is grant/deny per tool category — shell_execute either
has a grant or it doesn't. This is too coarse. In the incident from #350, the bot
ran git remote remove, git push, re-created files, and ignored user corrections
— all auto-approved because shell_execute has a blanket grant.

Proposal

Add command-level approval within tool grants, similar to Claude Code's permission
model:

Three tiers

Tier 1 — Auto-approve (read-only, no side effects):
file_read, web_search, web_fetch, search_tools, list_reminders

Tier 2 — Approve-on-first-use (side effects):
shell_execute per command pattern, file_write per path prefix, set_reminder.
In default mode: ask on first use, cache approval for the session. In permissive
mode: auto-approve.

Tier 3 — Always confirm (destructive / external-facing):
rm -rf, git push --force, git remote remove, creating repos, sending
external messages. Confirm even in permissive mode (unless policy override).

Approval cache

• Per-session (default): approvals reset each Slack thread
• Per-user persistent (opt-in): stored in policy config
• Pattern-based: command prefix matching, not exact string (git * approved,
  not just git push -u origin master)

Policy-level override

Users can configure approval mode in ACL config:

{
  "tool_approval_mode": "default"  // "default" | "permissive" | "strict"
}

Or issue in-conversation: "you have full permission" → session-level override.

Slack UX

Bot pauses mid-turn and asks inline before executing:

I'd like to run: git push -u origin master
Approve or deny?

Waits for user text response before proceeding.

Prerequisites

• Mid-loop buffer drain (PR fix(sessions): mid-loop user message injection and duplicate tool call detection #351) — required so the bot can pause mid-turn,
  ask for approval, and hear the response before the next iteration
• Trust context spec (PR spec(security): plan trust context and audience policy #249) — defines the policy framework this plugs into

Beta testing approach

Deploy with default posture and run the eval suite (evals/run-evals.sh) to
measure impact. Key metrics:

• Eval pass rate before vs after (should not degrade significantly)
• Number of approval prompts per eval run (should be minimal for read-only cases)
• Complex multi-step cases must still complete without excessive interruption

If the posture degrades eval scores significantly, it's too strict. The eval
suite's per-version trend tracking (SQLite results DB) provides the comparison
baseline.

Related

• PR spec(security): plan trust context and audience policy #249 — trust context and audience policy spec
• bug: runaway tool loop — model repeats completed work, ignores user corrections #350 / PR fix(sessions): mid-loop user message injection and duplicate tool call detection #351 — runaway tool loop fix (mid-loop buffer drain enables this)
• feature: formal eval suite for identity, skills, memory, and compaction quality #319 / PR feat(evals): behavioral eval suite for session pipeline regressions #347 — eval suite for regression testing