Human-in-the-loop design is most useful when it changes who has authority to create a consequence. In a low-risk assistant, a person may simply review generated text. In an agentic system, approval can stand between a model proposal and an action that sends money, changes access, publishes content, deletes data, contacts a customer, or modifies infrastructure.
The strongest connection to AI-103 is agent oversight: Microsoft Foundry candidates are expected to understand approval flows, constrained tool access, risk instrumentation, and semiautonomous workflows. AIP-C01 addresses a related AWS concern through secure agent and API integrations, operational validation, and security controls. The platforms do not grant authorization merely because a model asks for a human decision. An approval process must determine exactly who can approve a change, what evidence that person sees, when the decision expires, and how the backend ensures that the operation executed is the one the person actually authorized.
Approval belongs at consequence boundaries
Not every model call deserves a human decision. Requiring approval for harmless retrieval or formatting creates friction without materially reducing risk. The strongest candidates are operations where an error is expensive, difficult to reverse, externally visible, legally significant, or capable of changing another person’s rights or data.
Examples include issuing a refund above a threshold, changing a security group, sending a regulated communication, deleting a production record, granting elevated access, or executing code against a sensitive environment. In those cases the model can assemble a proposal, but the application holds the actual capability until an authorized person approves.
With Microsoft Foundry remote MCP tools, tool-call approval can be configured so a proposed invocation produces an approval request that includes the server, tool, and arguments. A reviewer should compare those arguments with the original business request and the permitted scope before allowing execution. Approval still belongs in a wider identity and authorization system: a confirmation for “update ticket 123” should not become approval to change a different ticket or to execute a more privileged action after the agent revises its parameters. The platform’s tool-approval feature is a point of control, not a substitute for validating the target and principal in the business API.
An Amazon Bedrock Agent can use an action group configured to return control to the application rather than invoke a backend function directly. The application receives an invocation identifier and proposed inputs, can enforce a human-approval workflow, and can return the execution result to the agent when authorized. The human gate in this pattern is an application design responsibility, not an automatic permission supplied by the agent. Reject or expire an approval if its inputs, actor, record version, or risk classification have changed; otherwise a perfectly legitimate approval interface can still execute an unauthorized or stale operation.
Agentic AI engineering decomposes autonomy into governed decisions with separate authentication, authorization, validation, transaction limits, approval, and audit controls. A human gate changes who authorizes a sensitive transition; it does not replace the controls that determine whether the requested action is valid or permitted.
The reviewer needs a decision packet, not a raw chain of text
A useful approval screen should explain what will happen if the person agrees. It should identify the target, action, important parameters, source data, policy-relevant risk, and any irreversible effect. Dumping a long conversation or tool trace onto the reviewer makes the human responsible for reconstructing the system’s intent under time pressure.
The decision packet can include a concise rationale and links to source evidence, but the actionable fields should be explicit. If an agent proposes sending an email, the reviewer should receive the recipient, subject, key content, and attachment list in the decision packet. If it proposes changing infrastructure, the resource, before/after values, environment, and expected blast radius matter more than a paragraph saying the change seems safe.
Human approval requires an application contract that freezes or revalidates the proposed operation. The reviewer should see the target, parameters, expected effect, relevant evidence, and risk, while the execution layer must reject any materially different action after approval. A confirmation screen without that binding can approve one proposal and execute another.
Approval should bind to the action that is actually executed
A serious failure occurs when the user approves one thing and the system later executes another. Parameters may change because the model replans, data is refreshed, a tool returns a new identifier, or an attacker modifies state between review and execution. Approval should therefore bind to a concrete operation or an immutable representation of it.
The execution layer can compare the approved action identifier, target, arguments, and version with the action it is about to perform. If material fields have changed, the old approval should no longer authorize the new operation. This is the AI-workflow version of protecting against time-of-check/time-of-use problems.
High-risk operations may also need fresh authorization at execution time. A reviewer who had permission ten minutes ago may have lost that role, the target resource may have changed state, or the transaction may now exceed a policy limit. Human approval records intent; deterministic authorization still decides whether the action is permitted now.
Escalation rules should be based on risk and uncertainty
Some applications can define approval with fixed rules: transactions above an amount, actions against production, requests involving protected data, or tools marked as destructive. Others need a combination of rules and confidence signals. A low-confidence classification, conflicting retrieved evidence, missing required fields, or an unusual action sequence can push an otherwise automatic workflow into review.
These escalation rules should be testable and conservative about what the model itself is allowed to decide. If the model can simply label its own proposed action “low risk” to bypass review, the control is circular. Risk tiers, tool metadata, resource classifications, and organizational policy should live outside the model’s discretionary text.
Approval fatigue is a control failure
A workflow that asks people to approve dozens of predictable, low-value actions teaches them to click through. The visible presence of a human does not provide meaningful oversight if the interface, frequency, or time pressure prevents thoughtful review.
Teams can reduce fatigue by narrowing approval to material boundaries, grouping closely related low-risk changes where policy allows, making differences obvious, and routing requests to the right role. They should also measure approval behavior: review time, rejection rate, repeated reversals, escalations, and users who approve unusually quickly can reveal whether the control is functioning as intended.
Automation can expand as evidence improves. If a class of action has stable validation, strong rollback, low impact, and a history of uncontroversial approvals, policy may permit it to move to automatic execution within limits. The reverse should also be possible when incidents reveal that a supposedly routine action carries more risk than expected.
Human review should preserve separation of duties
Approval is weakest when the same identity designs the request, benefits from the result, and authorizes the action. Sensitive workflows may require a reviewer from a different role or a second approval above a threshold. The design should also prevent the agent from choosing any convenient person as an approver simply to get a positive response.
Identity, role, and scope should be validated by the application. A finance approver may authorize a refund but not a production deployment; an infrastructure administrator may approve a firewall change but not a data-disclosure exception. Role-aware routing turns “a human approved” into evidence that the right human had authority for the specific decision.
AI governance defines the ownership and decision rights around those approval boundaries: who may approve which action class, which evidence must be retained, how exceptions expire, and who reviews repeated overrides. That accountability makes human involvement auditable instead of treating the presence of a person as proof that a decision was controlled.
Rejected actions need a safe continuation path
A rejection should not send the agent into an uncontrolled loop where it keeps proposing variations until one slips through. The workflow needs defined behavior: stop, ask for corrected inputs, propose a lower-risk alternative, or escalate to another process. Rejection reasons can improve the next proposal, but they should not become instructions that let the model bypass the boundary.
For example, a reviewer might reject a request because the destination is external. The safe continuation could constrain the next proposal to approved internal destinations rather than letting the model rewrite the action repeatedly while preserving the external transfer through another tool.
Audit evidence should reconstruct the entire decision
A useful record includes the triggering request, relevant identity, model or workflow version, proposed action, evidence shown to the reviewer, approver identity, decision, timestamps, final executed arguments, execution result, and any later rollback. This allows investigators to determine whether the human saw the same operation that the system performed.
The audit trail should also capture cases where approval was required but never reached execution. Those records help teams distinguish abandoned work from blocked attacks, user cancellations, and operational failures. They can also expose systematic friction—for example, a tool that repeatedly generates incomplete proposals and wastes reviewer time.
Timeouts, unavailable reviewers, and emergencies need explicit policy
An approval workflow eventually encounters an absent reviewer, a network failure, or an urgent operation. The system should not invent a fallback at runtime. Some actions should fail closed and wait; some may route to an alternate authorized role; a narrow set may have a documented break-glass path with stronger logging and retrospective review. The permitted behavior belongs in policy before the incident occurs.
Expiry matters as well. An approval that remains valid indefinitely can authorize an action after the surrounding conditions have changed. High-impact approvals can carry a short validity window or be invalidated when the target state changes. That forces the execution decision to remain connected to the facts the reviewer actually saw rather than treating approval as a reusable token of authority.
Human-in-the-loop is a designed authority transition
The strongest pattern is not “AI does the work and a person watches.” The model performs bounded analysis, produces a concrete proposal, and then control passes to an authorized decision maker at a deliberate boundary. Once approved, the execution layer validates that the operation still matches the approval and that current policy permits it.
Post-execution review is also distinct from pre-action approval. For reversible, lower-risk automation, organizations may permit execution within tight limits and sample outcomes afterward. That pattern can provide useful operational feedback without pretending that retrospective review can undo every consequence. The control model should make clear which actions require permission first and which can be monitored after the fact.
That makes human oversight useful even as agent capabilities grow. The person is not expected to inspect every token or understand every internal model decision. The system gives the reviewer the information needed to own a consequential choice, while deterministic controls ensure that approval cannot be stretched beyond the action that was actually reviewed.
