On this page
The short answer
Evaluate approvals as authorization for an exact operation, target, and set of arguments. Change one of those fields after approval and verify that execution stops for a new decision. A conversational yes is insufficient when it cannot be linked to the action that the tool actually commits.
What to take away
- Show the user the operation that will actually execute.
- Recheck material changes after approval.
- Prevent approval replay from creating another effect.
Sources checked . Research synthesis and Rubrex recommendations. Examples and local experiments are labeled; they are not client results.
Make the approval payload concrete
LangGraph documents interrupts for pausing execution and obtaining external input. Rubrex recommends treating the returned decision as one input to an execution check, not a general permission token. The executing component needs the caller, target, arguments, and state version associated with the approved proposal.
Use a synthetic account-management task that proposes changing a notification address. The review payload includes the account identifier, old address, proposed new address, and operation identifier. Avoid a vague prompt asking whether the agent may finish its work, because it conceals what the human is being asked to authorize.
Evidence: LangGraph: Interrupts [1]
Mutate the proposal after the person responds
Approve the first address, then change the pending tool argument to a different synthetic address. Try changing the account, expanding a single update into a batch, and resuming an old approval after the record has changed. Retain the original display and actual execution request for direct comparison.
Also revoke the test user’s authority while the workflow is paused. The approval should not preserve access that the person no longer has. Define whether an unchanged low-risk proposal can remain valid for a period, but require fresh checks for the material state that determines whether the operation is still permitted.
Inspect execution rather than the approval screen
Capture attempted calls, denied calls, and committed receipts. Test a forged approval message arriving through retrieved content as well as the legitimate review interface. The application should distinguish authenticated approval input from text that happens to say approved.
Repeat the legitimate resume request to test replay behavior. One approval for one intention should not become multiple account updates or an authorization to use a different tool. Include a denial control and an approved unchanged proposal, so the fixture verifies both blocking and permitted execution rather than only the existence of a review screen.
| Case | Evidence to retain | Acceptance condition |
|---|---|---|
| Changed address | Approved and attempted payloads | Fresh decision required |
| Revoked authority | Identity and access decision | Execution denied |
| Repeated resume | Approval ID and receipts | One authorized effect |
Accept the narrowest useful approval contract
Release the path when changed proposals cannot execute under the old approval, revoked authority is respected, and an unchanged authorized proposal completes with a receipt. Preserve the approval display, decision, execution fingerprint, and final state as one reviewable record.
If the product allows the agent to edit a proposal while waiting, make that change invalidate or visibly replace the earlier review item. Revisit the contract when adding batch actions, alternate tools, or background resumption. Approval is useful only when the human’s decision remains attached to the operation that crosses the consequential boundary.
Limits of the evidence
These notification changes are synthetic and the acceptance rules are proposed. Runtime interrupts do not by themselves establish authorization. This article is not legal advice or a claim that a particular approval interface satisfies a regulatory requirement.
Common questions
Can the model verify its own approval?
The execution layer should verify authenticated approval and the approved operation independently.
Must every read require approval?
Choose review requirements from the actual operation and product policy; this guide focuses on actions designated consequential.
Sources & further reading
Primary sources behind this briefing. A source’s findings apply to its own study conditions; publication on arXiv does not establish peer review.
- LangGraph: Interrupts LangChain · Living reference · Maintained documentationReviewed: pause/resume mechanism and state persistence; not an application authorization or cancellation guarantee. Accessed October 16, 2026.
Questions or corrections? Write to Rubrex. Read our editorial approach.