An agent should request fresh approval when an action is hard to reverse, affects people or systems outside the current task, exposes sensitive data, or increases privilege. Everything else should proceed under a clearly bounded task grant. The goal is to make approval a security control at meaningful boundaries, rather than a reflex before every tool call.
Classify the action, not the tool
A tool name is a poor proxy for risk. An HTTP client might read public documentation or delete a production tenant. Classify the concrete action on four axes: reversibility, external effect, data sensitivity, and privilege change. Reading a local configuration is low on all four. Sending an email has an external human effect. Rotating a production key changes privilege and may be difficult to undo. Exporting customer records involves sensitive data even if the export itself is reversible.
Use three policy outcomes. Low-risk actions run under the task grant. Medium-risk actions run only when a previous approval receipt matches the action. High-risk actions require step-up approval immediately before execution. Hard prohibitions remain prohibitions; an approval dialog must not turn an invalid action into a valid one. NIST’s AI Risk Management Framework profile for generative AI frames risk across design, development, deployment, operation, and decommissioning, which supports treating approval as one control within a larger system of accountability and monitoring.
Make consent machine-readable
An approval receipt should bind who approved, which agent may act, the operation, the target, important parameters, the maximum effect, and an expiry time. A receipt for refund invoice 418 up to $50 must not authorize a refund for another invoice or a larger amount. Include a nonce and mark one-shot approvals as consumed so a captured receipt cannot be replayed. Sign the receipt or store it in a tamper-evident service, then attach its identifier to the action log.
Fine-grained authorization benefits from structured details. RFC 9396 defines machine-readable authorization details with fields such as actions, locations, data types, identifiers, and privileges. An internal approval schema can borrow that shape without pretending an approval receipt is an OAuth token. The useful idea is parameter binding: consent should describe the intended transaction precisely enough for an enforcement point to compare it with the actual call.
A task-level grant can cover repeated safe operations: read these repositories, edit files under this path, and run these tests until the task ends. Its boundary should be explicit and inspectable. Do not infer that approval to draft a message includes approval to send it, or that approval to deploy staging includes production.
Trigger step-up at changed circumstances
Re-evaluate consent when the target changes, the estimated effect crosses a threshold, new sensitive fields appear, an operation moves from preview to execution, or the receipt expires. Also step up when the agent’s plan diverges materially from what the approver saw. A deterministic policy engine should make this decision; free-form model reasoning can explain the request but should not be the sole enforcement mechanism.
Present the user with a compact diff: intended action, target, irreversible effects, data leaving the boundary, and why existing consent does not cover it. Batch truly atomic operations into one approval, but never hide unrelated effects in a bundle.
Implement the smallest useful gate
Start with an action registry. For each action, record its risk axes, allowed task-grant scope, step-up conditions, and enforcement point. Add receipts with exact parameter matching, expiry, nonce consumption, and audit linkage. Test mismatched targets, increased amounts, expired receipts, and duplicate execution. Finally, sample approval prompts: if users approve mechanically, the boundary is too noisy.
The next step is to inventory the ten agent actions with the largest external effect and write one concrete approval predicate for each.
Sources are linked throughout this guide. Product capabilities can change; consult the linked documentation for your deployment.
Read our editorial approach ↗