Tool Permission Management — Patterns

Bind the approval to the exact payload

Problem. A person approves a described action and the system executes a constructed one. Between the description and the dispatch there is usually a re-serialisation, a default being filled in, or a model being asked to produce the final arguments — and any of those can change what actually happens.

Approach. Freeze the fully constructed invocation before showing it, hash it, and present the approval against that frozen payload. Execution takes the stored payload and verifies the hash; a mismatch is a failure, not a re-prompt. Render the approval from the frozen payload itself rather than from a separately generated summary, so what the person reads and what runs have one source.

Trade-off. Rendering raw payloads is worse for comprehension than a well-written summary, so the pattern trades readability for fidelity and usually needs a careful presentation layer that formats without re-deriving. Freezing also forbids last-moment enrichment, which some pipelines depend on.

Decide on the intersection of the two identities

Problem. An agent runs with its own identity so it can reach the systems it needs, and acts for a user who has narrower rights. Checking only the agent lets any user reach anything the agent can; checking only the user leaves the agent's own constraints unenforced.

Approach. Make every decision take both subjects and require both to permit the action. The agent identity bounds the capability envelope — what this kind of agent may ever do — and the user identity bounds the data — whose records are in scope. Record both on the decision so an audit can answer which of the two denied a call.

Trade-off. Two entitlement sources must both be current, and the intersection produces denials that are confusing to explain, because neither subject alone looks insufficient. It also rules out legitimate elevation cases, which then need an explicit, separately audited mechanism rather than being quietly permitted.

Standing permission with a scope and a clock

Problem. Per-call confirmation is unworkable for repetitive tasks, and the usual remedy — approving for the session — grants an envelope nobody described, covering actions that had not been conceived of when the approval was given.

Approach. Make the grant an explicit object with a stated scope, a counter, and an expiry: this tool, against this resource set, up to this many times, until this time. Show the scope at the moment of granting, enforce every one of its bounds on use, decrement visibly, and let the user inspect and revoke outstanding grants. A request outside any held grant returns to normal confirmation rather than being denied.

Trade-off. It is substantially more machinery than a session flag, and the scope language has to be understandable to a non-expert user or the display is theatre. Counters and expiries also produce interruptions at awkward moments, mid-task, which is exactly when a user is most inclined to grant something broader.

Enforce at dispatch, not at planning

Problem. Checking permissions while a plan is being assembled feels efficient and is unsound: the plan is a proposal, the arguments are frequently placeholders, and the gap between approval of a plan and execution of its steps is where conditions change.

Approach. Treat planning-time checks as advisory filtering only — useful to avoid proposing things that will be refused — and place the authoritative decision immediately before dispatch, on the final payload, with no code path that reaches an effectful call without passing through it. Where a plan was approved as a whole, re-evaluate each step on its own as it comes up, and fail the plan rather than the step when a later check denies.

Trade-off. A plan can be approved and then partially fail, leaving the task half-complete and the user with a worse experience than an upfront refusal. That is the correct outcome, but it needs compensation handling for whatever already executed, which is real work.