The mid-run grant gap
A task can legitimately need a tool it wasn't granted. Today the answer is just 'no' — the missing piece is a pause-and-ask-operator flow.
Fail-closed registries have a sharp edge, and it's worth naming honestly. Before a run, someone decides what tools the agent may touch. But real tasks are unpredictable: halfway through, the agent legitimately needs a tool it wasn't granted. Maybe the task expanded. Maybe the plan changed. Maybe the operator just didn't think of it. The registry says no — correctly, by its rules — and the run is stuck.
This isn't a flaw in the blocking. The block is doing its job. It's a gap in the workflow around the block: there is no path from 'refused' to 'approved' that doesn't involve killing the run, issuing a new grant out of band, and starting over.
Why it matters
Without a grant-request path, operators face a bad choice every time this happens. Kill the run and lose the work, or preemptively over-grant the next run 'just in case' — which quietly rebuilds the ungoverned system the registry was built to replace. Every over-grant is a small defeat for least privilege, and they accumulate.
It also punishes the exact behavior you want. An agent that discovers it needs a new tool mid-task is doing its job — adapting to reality. A system that answers adaptation with a dead end teaches operators to grant broadly up front, which is the opposite of governance.
What the fix looks like
A pause-and-ask flow, built on the pieces that already exist. The refusal is already fast and audited. What's missing: the run pauses instead of dying, the refusal becomes a grant request carrying the context (which agent, which tool, which version, why — the agent's own stated reason), and the request is delivered to the operator through the alert path. The operator approves or denies; approval issues a scoped, expiring grant; the run resumes.
Three properties matter. First, the request must carry the reason — 'agent needs X because Y' — or the operator is approving blind. Second, the grant from an approval is narrow and short-lived, not a standing permission. Third, denial must be a clean outcome, not a crash: the agent gets 'denied,' adapts or stops, and the whole exchange is in the audit log.
This is the honest version of fail-closed: the default is still deny, but deny comes with a door. A locked door with a doorbell beats a locked door with a wall.
Until the pause-and-ask flow exists, the practical discipline is: grant for the task you have, and treat every mid-run refusal as a planning signal. If the same tool gets refused across many runs, it belongs in the default grant set for that task type. The refusals are data — let them teach the grant policy.