An approval inbox can look reassuring while providing almost no security. If an engineer must approve every directory read, test run, and temporary file, the important request eventually looks like one more interruption. The problem is structural: the system has delegated too many routine decisions to a person and has provided too little context for the decisions that matter.
The goal is useful autonomy within a clearly bounded grant. A coding agent may edit a disposable checkout and run local tests. It may still need a separate decision before pushing to a protected branch, accessing production credentials, or sending source code to a new destination. Those boundaries should survive changes in the agent's wording, model, and tool selection.
Start with consequences, then choose controls
Classifying tools as read or write is an incomplete starting point. Reading a public document differs from reading a signing key. Writing a scratch file differs from changing a payroll account. The effect depends on the resource, destination, environment, and reversibility as much as the method name.
Create an action vocabulary that reflects those effects. For each action, derive the actual target from validated arguments and trusted connection metadata. A function called run_report can still execute SQL that mutates data. A development-labeled request that targets the production account must inherit the production boundary. Client declarations may add context; they must not lower the minimum control required by the observed operation.
OWASP's Excessive Agency guidance identifies excessive functionality, permissions, and autonomy as contributors to damaging agent behavior [1]. Applying that distinction is more useful than adding another generic confirmation dialog. Remove unnecessary capability first. Reserve human judgment for requests that remain consequential after the permitted scope is made precise.
Describe the grant as a contract
An enduring grant should answer who, what, where, for how long, and under which ceilings. Bind it to an authenticated principal and tenant, name the connection and resource set, constrain operations and destinations, and specify expiry. Make the ceilings visible: maximum records, cumulative spend, permitted environment, and excluded actions.
For example, a support agent could retrieve orders for the current customer's account and draft replies in the support workspace. That grant need not permit sending messages, changing payment destinations, or issuing refunds. A second grant could allow refunds below an agreed ceiling for verified eligible orders, with a cumulative daily budget. These are illustrative policies, not universal safe thresholds.
The implementation must enforce the same contract at execution. A human-readable policy that becomes a broad tool wildcard after compilation is a documentation defect and a security defect. Keep the rendered scope, normalized policy, and enforcement result linked by a stable revision identifier.
| Action | Standing grant | Escalation trigger |
|---|---|---|
| Edit local checkout | Named repository and worktree | Protected path or credential access |
| Read support order | Current authenticated customer | Cross-customer lookup or bulk export |
| Draft response | Approved workspace | External send or new destination |
| Issue refund | Verified eligibility and explicit ceilings | Amount, aggregate budget, or beneficiary change |
Make exceptions narrower than the problem
Approve once should mean this action under these conditions. Remember a decision only when the system can derive a defensible scope from the approved request. Include the connection, target class, operation, environment, and consequence ceiling. A person should see what the remembered grant never covers, including credential changes, external destinations, and actions above the approved tier.
Plan approval can reduce interruptions for a bounded sequence. It must not become a blank check for whatever the agent later decides is necessary. Tie the plan to the agent and session, enumerate allowed steps or constraints, and re-evaluate new targets and higher-impact operations. An approval for a staging migration cannot silently cover a production migration because both use the same database tool.
Treat every exception as an expiring policy object with an owner and reason. Emergency access should be shorter, more attributable, and easier to revoke than ordinary access. A workflow that requires a permanent exception to run normally is signaling that the base policy needs redesign.
Give the reviewer a decision, not a transcript
An approval screen should present the proposed effect: the exact recipient, resource, material argument changes, cumulative exposure, and why the request falls outside existing authority. Show the authentic initiating task separately from the agent's explanation. Retrieved text and model-generated justifications remain untrusted evidence.
For outbound actions, show the actual content or a protected review path to it. For destructive actions, show the affected object set and recovery assumptions. Resolve ambiguous aliases before asking. A reviewer cannot meaningfully approve sending to the finance team when the underlying address is a newly introduced external mailbox.
Bind the approval to the request the reviewer saw. If material arguments change after approval, ask again or deny according to policy. The server should reject approval links from unauthorized reviewers and record the identity, scope, policy revision, and decision time. OWASP recommends validating permissions on every request [2]; approving a plan does not remove that obligation at the point of execution.
Measure the cost of asking
Track approvals by originating rule and consequence, rather than counting only the total inbox volume. Useful measures include interruption rate per completed task, wait time, repeated approvals for equivalent actions, abandonment, and the share of denied requests that later proved legitimate. Segment them by environment and workflow.
A high approval rate is evidence for investigation, not permission to automatically grant access. Review whether requests were understood, whether the same person repeatedly approved under time pressure, and whether the proposed broader scope would have covered unrelated actions. Replay candidate rules against both ordinary traffic and adversarial examples before activation.
Also measure outcomes beyond the approval service. A denied gateway request followed by a successful direct API call is a bypass, even if the inbox dashboard looks perfect. A policy that prevents all work has excellent refusal coverage and poor operational value. Security and task completion must be assessed together.
Roll out without teaching people to ignore the system
Begin with one workflow and document its legitimate execution path. Remove unused tools and give the agent the narrowest connection that can finish the task. Observe routine calls, but keep hard boundaries on production changes, sensitive exports, and privileged access during the learning period.
Review the proposed standing grants with the workflow owner. Test them using benign tasks, denied actions, changed arguments, expired approvals, and unavailable policy infrastructure. Expand only after the team can explain both why ordinary work succeeds and why a realistic boundary crossing fails.
The operating objective is straightforward: most routine work should complete inside explicit authority, and the few requests that reach a person should deserve their attention. That is how approval becomes a scarce, useful security control rather than a repetitive gesture.