The allowlist was too generous
Two routine blog handoffs expose a less routine problem: broad agent permissions were approving destructive commands without review.
The agent permission allowlist had become too broad. It was meant to keep ordinary development work moving without repeated prompts, but several wildcard rules also approved mutating and destructive forms of the same tools. The fix removed those broad grants and kept only the narrow commands that recent work had shown to be both useful and safe.
Convenience is not the boundary#
The problem was not that agents needed fewer tools. They needed a more accurate boundary between inspection, routine verification, and an action that changes state. A wildcard for a version-control or repository command does not express that distinction. It treats reading a pull request and merging it as the same capability, or checking a branch and discarding work as equivalent operations. That saved a prompt, but it also removed the point where I should be deciding whether the action may proceed.
The repository supplied its own evidence for the smaller policy. While the blog backfill continued through explicit draft and publish handoffs, a transcript scan showed which prompts were ordinary verification rather than consequential actions. That let the allowlist grow from observed needs instead of imagined convenience. Not every command from a trusted tool is trusted; the exact operation is what matters.
Keep the friction where the decision is#
The resulting configuration is less symmetrical and more useful. Read-only inspection remains easy, builds and tests can run without interruption, and commands that can alter history, publish work, change dependencies, or open a remote shell return to an explicit approval step. The next adjustment should follow the same rule: start with the smallest operation the work actually needs, then widen it only when repeated evidence shows that the wider boundary is safe.