Why an approval must bind one exact call

Humans authorize. Policy enforces. Evidence proves. The first of those only means something if the authorization is specific. An approval that grants “requests like this one” instead of “this exact request” has quietly turned a human decision into a standing exception, and standing exceptions are how narrow, deliberate access turns into broad, accidental access.

Inside Govna’s default-deny pipeline, a policy can deny a call outright, allow it, or route it to a human for approval before it proceeds (GRD-001). When a policy routes a call to approval, the decision that results is bound to the requester, the session, the tool, and a hash of the exact arguments — not a description of the call, but the call itself. That decision authorizes dispatch of that one request and nothing else; it does not widen the session’s grant, and it does not pre-authorize a later call that merely resembles it (APR-001).

The alternative — approving a pattern instead of an instance — is tempting because it is more convenient. It also defeats the purpose of asking a human in the first place. A reviewer who is shown “delete a record” once and then finds that decision silently reused for every subsequent delete has not actually reviewed anything past the first call; they have issued a blanket exemption while believing they made a considered judgment. The exact-call binding exists so that a person’s “yes” means yes to the thing they actually saw, not to a category they can no longer inspect.

This is what the binding is for: a real decision on a real request, bound to that request’s exact requester, session, tool, and argument hash (APR-001), rather than resolved from a pattern. See approvals for how the binding itself is enforced.