Agent permission scoping

As of: 2026-08

The capability model

• Read — broad by default (repo, docs, logs). Low risk, high value.
• Write-repo — allowed, gated on review (diff before merge). Files excluded: CI workflows, hooks, dependency manifests, permission configs themselves — changes there are how agents escalate.
• Execute — allowlisted commands (build/test/lint), deny-by-default for package installs, curl-pipe-sh, anything network-egress.
• Credentials — never in agent context; vault handles at the boundary.

Where the config lives

Versioned in-repo (AGENTS.md + permission config per harness): reviewed in PRs like code — because an agent editing its own permission file is the escalation path. The file is in its own deny-list.

Operational hygiene

• Per-project settings, not global: the side-project sandbox shouldn't trust like the production repo.
• Session logs retained (commands + outputs) — postmortem input when something goes sideways.
• Audit what the permissions actually grant quarterly; harnesses add new tool surfaces fast.