Approval is one of the easiest agent controls to describe and one of the easiest to weaken in practice. A person says yes, the system treats that yes as permission, and the agent continues. The problem is that the work may keep changing after the approval. A draft may be revised. A target record may refresh. A tool may return a different result. A retry may happen later. A reviewer may have approved one action while the agent silently treats the approval as a wider license.
Approval scope is the discipline of making each yes describe exactly what was approved, what evidence supported it, when it expires, and what changes would make it invalid. It belongs beside AI Agent Permissions , because permission defines what the agent may do in general, while approval scope defines what it may do this time. It also belongs beside Human Review for AI Agents , because a review is only useful when the person understands the action being authorized.
The useful question is not whether a human was in the loop. Many broken workflows can honestly say that a human clicked approve. The useful question is whether the approval still meant what the human thought it meant by the time the agent acted.
Approval Should Attach To An Artifact
An approval should attach to a concrete artifact, not to a mood. The artifact may be a message draft, a proposed record update, a code patch, a generated report, a purchase request, a deletion plan, or a deployment step. It should be specific enough that a reviewer can inspect what will happen and specific enough that the system can tell whether the artifact changed afterward.
This sounds obvious until the workflow says something like “approve the agent to handle this ticket” or “approve the plan.” Those phrases may be fine for conversation, but they are weak as operating controls. Handling a ticket could mean drafting a reply, updating a status, issuing a credit, closing the case, or escalating it. A plan could change between approval and execution. If the approval does not bind to the version that was reviewed, it becomes a vague signal of trust rather than a usable boundary.
AI Agent Artifact Design is helpful here because it treats the output of a run as something meant to be reviewed. An approval-ready artifact should include the proposed action, the target, the evidence, the expected effect, and the remaining uncertainty. If the artifact cannot carry those details, the approval should not carry much authority.
The Reviewer Is Approving A Claim About The World
A person does not only approve an action. They approve an action under a set of facts. A support manager may approve a draft because the current policy says a replacement is allowed. An engineer may approve a patch because the failing test now passes. An operations lead may approve a record update because the target account matches the evidence. If those facts change, the approval may no longer apply.
That is why approval scope should preserve the facts that mattered. It should say which source governed the decision, which record version was inspected, which test result supported the patch, or which customer message was considered. It does not need to preserve every detail forever, especially when sensitive data is involved, but it should preserve enough for AI Agent Output Verification to compare the final action with the approved state.
Without that evidence, the approval becomes difficult to audit. A reviewer can remember clicking yes, but not which version they saw. An agent can report that approval existed, but not whether the final action still matched it. A later incident review can see a timestamp, but not the reasoning that made the timestamp meaningful. The approval record should be small, but it should not be empty.
Expiration Is A Safety Feature
Approvals should expire. They may expire after a time window, after a version change, after a target state changes, after a reviewer changes the artifact, or after the agent reaches the end of a run. Expiration is not an insult to the reviewer. It is a recognition that delegated work is dynamic.
Long-lived approvals are tempting because they reduce friction. A team does not want to approve the same kind of low-risk action every hour. Some standing approvals can be reasonable when the task is narrow, well tested, observable, and reversible. But a standing approval should be treated as a policy route, not as a casual click that accidentally lasts forever. It needs its own owner, review cadence, and stop condition.
Short-lived approvals are especially important when the agent depends on live state. A record can change after approval. A queue item can be handled by another person. A code branch can move. A price, slot, inventory count, or availability field can refresh. Even if the work is not financially or legally sensitive, acting on stale approval can produce embarrassing or confusing outcomes. AI Agent Concurrency explains the same risk from the angle of shared work. Approval scope adds the review boundary to that picture.
Scope Should Not Expand During Retries
Retries are a common place where approval drifts. An agent prepares an action, receives approval, attempts the action, and encounters a timeout or tool error. It retries. Maybe the first attempt actually succeeded. Maybe the target changed. Maybe the second attempt needs a slightly different payload. If the approval is treated as a general blessing, the retry can become a new action wearing an old permission.
The safer pattern is to bind approval to a stable action identity. AI Agent Retries and Idempotency covers the mechanics: an action should have an identifier, a target, a payload, and a way to detect repeated execution. Approval scope should attach to that same identity. A retry of the same action can proceed under the same approval if the system can prove it is the same action against the same state. A changed action needs fresh review or a rule that explicitly allows that kind of change.
This distinction matters in ordinary workflows. A message send retry should not send a different draft. A refund retry should not change the amount. A file update retry should not include new edits. A deployment retry should not quietly pick up an unreviewed commit. The agent may not intend to expand the scope, but systems change around it. The approval should make that expansion hard to miss.
Approvals Need A Refusal Shape
A good approval workflow also needs a clear refusal shape. Reviewers should be able to reject, request revision, narrow the action, approve only a draft, approve only a dry run, or send the work to a different route. If the interface offers only approve or cancel, people will use comments, chat messages, and informal instructions to express more precise intent. Agents are not good at preserving informal nuance unless the workflow gives that nuance a place to live.
This is where AI Agent Control Surfaces matter. The approval surface should show the artifact, the evidence, the target, the permission level, and the consequences in a form that supports an actual decision. It should not ask a person to approve a paragraph while hiding the action behind it. It should not show a giant transcript and call that transparency. The reviewer needs the right layer of detail.
Refusal should also be usable by the agent. A rejection that says only “no” may stop the run, but it may not improve the next attempt. A rejection that says the source is wrong, the action is too broad, the target is ambiguous, or the tone is not acceptable gives the workflow a repair path. AI Agent Feedback Loops become stronger when approval decisions carry structured reasons instead of disappearing into vague dissatisfaction.
Approval Records Should Be Reviewable Later
An approval record is part of the evidence trail. It should be possible to answer who approved what, when, under which facts, for which target, and whether the final action matched. The answer does not have to expose private data to everyone. It may point to restricted records. But the workflow should not depend on a person’s memory of a modal dialog.
This matters after incidents, but it also matters during normal operations. If reviewers keep approving actions that later need correction, the team can inspect whether the artifact was weak, the evidence was hidden, the approval copy was unclear, or the agent changed the work after approval. If approvals are logged only as yes or no, the team loses the repair signal.
Approval scope turns human review from a ceremonial gate into a usable contract. The agent brings a concrete artifact. The reviewer authorizes a bounded action under stated facts. The system preserves the boundary, expires it when conditions change, and refuses to stretch it across different work. That is less glamorous than saying a human is in the loop, but it is the part that makes the loop real.
