Designing approval boundaries for agentic systems

An approval button does not automatically make an agent safe. If a person cannot tell what will change, where it will happen, or which input the agent will use, the approval is little more than a confirmation dialog.

Good boundaries begin with a small set of actions that the system can describe before execution.

Classify actions by consequence

A tool registry can label operations by capability: inspect a file, search a workspace, write a file, execute a command, call an external service, or publish a change. The application can then define which actions are allowed in a mode and which require a decision.

Avoid one global boolean such as safe: true. Risk depends on more than whether a tool writes data. A read can expose private source to a hosted provider; a search can scan a larger scope than intended; a terminal command may delete files even if the tool wrapper calls it “run.”

Ask at the boundary, not after

The approval prompt should be built from the validated action that will actually run. Include the target, a concise explanation, relevant arguments, and whether the operation can be reversed. For code changes, a diff preview is more useful than a generic notice that the agent wants to edit a file.

Approval must bind to the proposed operation. If the agent changes the command, path, or payload after the person approves, the old approval should not silently authorize the new action. Revalidate the operation and ask again when the meaningful details changed.

Scope the grant

An approval can be one-time, one tool call, one file, one session, or a broader policy. The user should be able to tell which scope they are granting. “Allow all” has different implications from “allow this read-only search,” and a trusted workspace may deserve a different policy from an unfamiliar repository.

Prefer narrow, temporary grants for consequential operations. Record the actor, decision, operation identity, and timestamp so a later review can distinguish the model proposal from the human authorization.

Make denial a normal outcome

The workflow needs a typed “needs approval” or “denied” result, not a generic tool failure. The agent can then explain the blocked action or continue with a safe alternative. A denied action should not be retried under a different tool name or reconstructed argument without another policy check.

This is also a product design decision. The interface should make it easy to inspect a request, decline it, and understand what the agent will do next. Repeated ambiguous prompts train people to approve without reading.

Approval for distributed work

When an agent works across a runner, repository, or hosted control plane, the same identity and scope must follow the action. A human approving a verified commit is not necessarily approving an agent to publish any future commit. Bind the review to the commit, verification results, and publication action.

If verification runs again and produces a different artifact, invalidate the old approval or show exactly why it remains applicable. An approval system should not create a race where a check passes one version while another version is published.

Keep evidence beside the decision

For a meaningful decision, show the request and the context needed to evaluate it: file diff, target repository, source excerpt, command, outbound destination, or verification report. Minimize the view to relevant evidence, but do not ask the user to trust an unexplained summary.

A practical review

• Is the action described after schema validation?
• Does approval bind to the exact target and payload?
• Is the grant scope visible and limited?
• Can the user deny without breaking the whole session?
• Does a changed request require a new decision?
• Are approvals and execution results connected in the audit trail?

An approval boundary is part of the system's execution contract. It is useful when a person can understand the choice and when the application enforces that choice after the interface closes.