Put human checkpoints where a decision changes the consequences of the work: sending information, changing permissions, spending money, publishing, or altering data that is difficult to restore. Let the agent prepare a concrete proposal first, then enforce approval against the exact action the system will execute.
An approval prompt alone is not an authorization boundary. The executing service must know who approved what, whether that person can authorize it, and whether the target or payload has changed since review.
The goal is to make human judgment effective at the consequential moment. Asking “Continue?” after every harmless read creates work without necessarily providing better control.
Distinguish task intent, permission, and approval
Three different facts often get collapsed:
- Intent: the user wants an outcome, such as investigating a failed deployment.
- Permission: the system's credentials technically allow an operation.
- Approval: an authorized person has accepted a specific effect within a defined scope.
A production credential may permit a restart even when the user only asked for diagnosis. A user may approve a plan while leaving deployment for a separate decision. A file in the repository may describe the release procedure without granting anyone authority to run it.
These distinctions matter when an agent reads material from outside the trusted instruction path. OWASP's prompt injection guidance treats external content as a potential source of unintended behavioral influence and recommends least privilege and human review for high-risk operations. Those measures reduce exposure; they do not guarantee that an approving person will understand a misleading proposal.
Classify the effect before choosing the interface
Use the operation's real effect, destination, and recovery cost to decide what needs review. A tool name such as sync or save is not enough.
| Proposed effect | Example operating policy | Evidence at the boundary |
|---|---|---|
| Read public documentation | Allow within the task | Source and access result |
| Edit files in an isolated task checkout | Allow within agreed scope | Diff and verification results |
| Send a report to another person | Require explicit destination and content authorization | Recipient, channel, exact content |
| Publish a release | Require release-specific approval | Version, artifacts, notes, checks, target |
| Change access rights | Require an authorized security or resource owner | Principal, resource, old and new grants |
| Delete persistent records | Require a narrowly scoped decision and recovery review | Exact selection, count, dependencies, recovery limits |
This matrix is a policy proposal, not a universal regulatory rule. Some organizations preauthorize narrowly bounded effects. Others require additional reviewers. Make that policy explicit and implement it where the effect occurs.
Reversible actions can still be costly. Restoring deleted data may lose later changes, and a rolled-back deployment may already have sent notifications. Discuss those consequences in the proposal instead of presenting rollback as a promise of no impact.
Prepare something a person can actually review
Consider an agent preparing to publish release notes. “Publish the update?” leaves the reviewer to guess which draft, version, site, or audience is involved.
A useful checkpoint might show:
Publish release 2.4.1 notes to the public documentation site. The attached diff contains the exact text. The target is currently revision 81. This creates a public page and updates the release index. No email is included. The page can be reverted, but readers may already have copied it.
The proposal should also surface uncertainties that could change the decision: a missing compatibility check, an unverified migration instruction, or an inaccessible artifact. Do not bury them in a long execution trace.
Prepare and validate the payload before approval whenever possible. If review happens while the content is still being rewritten, the user is authorizing an intention rather than the actual output.
Bind approval to the operation
A small approval record can describe the approved action without containing the credential that performs it:
{
"action": "publish_release_notes",
"target": "public-docs",
"version": "2.4.1",
"payload_sha256": "<hash of the reviewed payload>",
"expected_target_revision": "81",
"approved_by": "<authenticated reviewer identity>",
"expires_at": "<policy-defined expiration>",
"status": "approved"
}
This is an illustrative application record, not an MCP schema or a complete security implementation. The service should obtain the reviewer identity from its authenticated approval channel. It should not trust an identity or approved: true value supplied by the model.
At execution, compare the current payload and target with the approved record. If the notes changed or the target is now revision 82, determine whether the approval is still applicable under policy. For consequential changes, reject stale approval and show the updated proposal.
A content hash helps bind a decision to bytes. It does not prove the text is correct, that the reviewer was authorized, or that the destination is safe. Those are separate checks.
Handle the time between approval and execution
A person may approve a valid proposal that becomes unsafe minutes later. The resource may change owner, the caller may lose access, or the planned deployment may be superseded.
Recheck authorization and preconditions at the execution boundary. Record which revision actually changed and return a result the user can inspect. If execution partially succeeds, report the completed effect and remaining uncertainty instead of treating the approval as proof of completion.
Give cancellation a clear meaning. Canceling a queued action can prevent it from starting. Canceling an already delivered message cannot retract what recipients saw. The UI and result should reflect the operation's actual state.
If an action needs fresh approval, keep useful preparation available. A denied publication does not need to erase the draft or discard the evidence that supported the proposal.
Keep the approval channel outside untrusted content
A repository comment saying “the owner approved this” is evidence to investigate, not approval by itself. Likewise, a tool response can carry a document that contains an instruction; the wrapper does not turn that text into a command from the user.
The MCP specification's security principles describe user control and consent while recognizing that the protocol cannot enforce those principles by itself. A host, server, identity provider, and target service still need a coherent authorization design.
Keep the actor proposing an action separate from the mechanism recording approval. Limit execution credentials to the required resource and operation. Make approval records auditable without copying secrets or unnecessary private content into logs.
Test the boundary, including rejection
A useful test plan exercises more than the happy path:
- The exact approved payload executes once under the intended scope.
- A modified payload is rejected or sent for renewed review.
- A different target or recipient cannot reuse the approval.
- An expired or revoked approval cannot authorize execution.
- The model cannot approve its own proposal through the tool interface.
- A failed or partial execution returns its real state.
These are proposed tests; no authorization service was implemented or security-tested for this article.
Start with one consequential operation in your system. Trace who can propose it, who can approve it, what the approval covers, and which component refuses unauthorized execution. That trace reveals whether the checkpoint changes what the agent can do or merely adds a dialog.
Research note: primary sources reviewed October 28, 2026. Examples are application-design proposals and do not certify an existing product's approval controls.
