An agent approval is a decision that authorizes an AI agent to take a particular action within a stated scope. It is useful when the agent can prepare an action, but a person needs to decide whether it should happen. The approval should occur before the consequential action, while there is still a meaningful choice.
For a developer, the important question is not simply “Should this tool ask?” It is “What exactly is being authorized, by whom, and under what conditions?” A button labeled Approve is only the visible part of that decision.
This guide offers an original allow / ask / deny worksheet for answering those questions. It is a design proposal, not a tested enforcement system or a guarantee of safe behavior. The examples are hypothetical; no email was sent and no vendor implementation was benchmarked.
Three meanings of approval
“Agent approvals” can describe different tasks. Distinguishing them avoids choosing the wrong kind of control.
| Meaning | Decision being made | Example |
|---|---|---|
| Approval of an agent’s action | May this agent perform this operation now? | Send a prepared message to a named recipient. |
| Approval to deploy an agent | Is this system ready for a particular environment? | Permit a support agent to enter a production trial. |
| Business approval assisted by an agent | Should a business record or request be accepted? | Review a submitted expense entry. |
This guide concerns the first meaning. Microsoft’s Approvals Agent overview describes assistance with time, expense, and material-entry approvals in Project Operations. That is a different reader task from authorizing an agent’s next tool call. Deployment review, meanwhile, cannot establish that every later runtime action is appropriate.
Permission, clarification, and approval
A permission gives an actor access to a capability or resource. An approval answers a more specific decision inside a workflow. Giving an application access to an email API does not, by itself, express a person’s decision to send a particular message.
Clarification supplies missing information: “Which recipient did you mean?” Approval supplies authority: “May I send this exact message to this recipient?” Asking someone to choose a recipient should not silently authorize the eventual send.
Mastra’s discussion of approval and suspension makes a similar distinction between gatekeeping and gathering human input. That source describes its own framework patterns; our worksheet below is a framework-neutral proposal.
The MCP tools specification dated 2025-06-18 recommends a human ability to deny tool invocations and clear confirmation interfaces. It does not mean every MCP client implements the same review experience. Check the client and server you actually use, including the scope of any remembered approval.
Use the allow / ask / deny worksheet
Start by naming the real operation, its destination, and its potential effects. A tool named search may still transmit confidential text to an external service. A tool named update may modify one temporary file or thousands of production records. Classify the operation and its context, not its friendly label.
The table below is our proposed starting policy for a small team’s agent. Replace its example boundaries with your own explicit permissions and review requirements.
| Decision | Use it when | Hypothetical example | Evidence to keep |
|---|---|---|---|
| Allow | The operation fits a narrow, current permission, and the permitted effects are understood. | Read a designated public documentation page without submitting private query data. | Operation, target, policy version, and result. |
| Ask | The operation is permitted in principle, but a specific decision is required before acting. | Send a prepared message to one authorized customer contact. | Exact proposed content and recipient, authorized reviewer, decision, expiry, and result. |
| Deny | The operation crosses a prohibited boundary or the requester lacks authority. | Upload repository credentials to an external endpoint. | Reason and a minimal record of the attempted operation, without copying secrets into the log. |
Missing information means pause. Do not turn an incomplete request into an automatic allow. Gather the missing details first, then evaluate it again. A reviewer saying “yes” should not override a hard prohibition through an ordinary approval button. Changing the underlying policy is a separate authorized process.
Download the editable decision worksheet. It contains the questions to fill in before a proposed action reaches a reviewer. The examples above are policy suggestions, not findings that all reads are safe or all writes must require a click.
Work through one email request
Consider a hypothetical support agent that has prepared a message about a corrected delivery date. The team allows drafting without review and requires approval before sending externally.
A useful request makes the decision concrete:
Proposed action: Send the displayed delivery update from the support mailbox to one customer contact.
Recipient: The contact already verified on the support case; show the full address to the reviewer.
Content: Show the complete subject and body. No attachments.
Scope: One send for this case, not permission for future messages.
Expiry: Ten minutes after the request is created, as an illustrative policy choice.
Reviewer: A support operator authorized for this mailbox and case.
If declined or expired: Keep the draft. Do not send.
The agent’s ability to call the email API is only one prerequisite. The application also needs to associate the decision with the prepared action, verify the reviewer’s authority, and check that the action still fits policy when execution starts.
If the agent changes the recipient, body, attachment set, or sending identity, the previous decision no longer authorizes the changed request under this proposed policy. Return the revised request for review. A displayed summary is not enough if it conceals details that would change the decision.
The ten-minute window is deliberately illustrative. Pick a duration that reflects the consequence and how quickly relevant state changes; this guide has not established a universal expiry value.
Keep approval separate from execution
Record at least three distinct facts: what was proposed, what was decided, and what was observed after the attempted action. An approval says that an operation may proceed under its conditions. It does not prove that the operation succeeded.
For our hypothetical email, an approval could be followed by an API rejection, a timeout, or a provider acknowledgement. Even a provider accepting a message is not proof that a person received or read it. Name the observed state precisely.
A useful proposed event sequence is:
- Proposed: Store the action identifier and the exact parameters to be reviewed.
- Decided: Record approval or denial, the authenticated reviewer, the authorized scope, and the expiry condition.
- Revalidated: Before execution, check for changed parameters, expired authority, revocation, or changed policy.
- Attempted: Associate the attempt with the approved action and a stable deduplication key where the downstream service supports it.
- Observed: Record the provider’s acknowledgement, failure, or an unknown outcome that requires reconciliation.
Do not blindly retry an external action after an ambiguous timeout. It may already have happened. Reconcile with the downstream system or use its documented idempotency mechanism before deciding whether a retry is appropriate. A local “approved” flag alone does not prevent duplicate sends.
This is not an abstract concern in resumable workflows. LangGraph’s interrupt documentation explains that an interrupted node restarts from its beginning on resume and warns that preceding side effects may run again. Its guidance includes idempotent operations and separating side effects. That documents one framework’s behavior, not a test result for every agent runtime.
Test the boundary before relying on it
The following is a proposed acceptance plan. We have not executed it against a production integration. Use synthetic data and a non-delivering test destination first.
| Scenario | Expected behavior under our proposed policy |
|---|---|
| Authorized reviewer approves the unchanged, unexpired request | Permit one execution attempt and record its outcome. |
| Reviewer declines, or no response arrives before expiry | Do not perform the action. Preserve an honest denied or expired state. |
| Recipient or message changes after approval | Invalidate that approval for the changed action and request a new decision. |
| A user without authority clicks approve | Reject the decision; do not elevate their access. |
| Two workers pick up the same approved request | Prevent duplicate external effects using an appropriate concurrency and downstream idempotency strategy. |
| The provider times out after submission | Record the result as unknown until reconciled; do not report success or retry blindly. |
| Policy or authority changes while the request waits | Revalidate before execution; stop if the operation is no longer permitted. |
An application must enforce these conditions at the execution boundary. A chat instruction asking the agent to behave carefully is not evidence that the boundary exists. A durable implementation also needs authenticated decisions, tamper-resistant records, concurrency handling, and tests of what happens when processes fail. This worksheet does not implement those controls.
Make the next decision smaller
Choose one consequential action in your agent’s workflow. Fill in the worksheet with its actor, exact operation, target, limits, reviewer, expiry, and expected outcome evidence. If a reviewer cannot tell what will happen from that request, narrow the operation or improve the request before adding an approval button.
The useful outcome is a reviewable decision with a clear boundary. The number of prompts shown is a poor substitute for that clarity.
Sources and change notes
Sources checked on 9 October 2026:
- MCP tools specification, 2025-06-18: human control and tool invocation interfaces; this is the named specification revision, not a claim about the latest revision.
- Mastra: When to use agent approval: approval versus clarification and framework-specific patterns.
- LangGraph: Interrupts: resumable execution and replay of code before an interrupt.
- Microsoft: Approvals Agent overview: business-record approval intent.
9 October 2026: Initial edition. Original worksheet and hypothetical email example; no real sends, performance benchmarks, or security certification claimed.