2026 Comparative Analysis: Human Approval and Elicitation Infrastructure for AI Agents — Applied Technology Index

Executive Summary

Human approval infrastructure is the control layer that pauses an AI agent before a consequential action, presents the exact proposed operation to an authorized reviewer, records a decision, and resumes only the action that was reviewed. It is not the same as authentication, authorization, elicitation, or durable execution. Authentication identifies an actor; authorization defines what that actor may do; elicitation requests missing input; durable execution preserves work across a wait; approval records a decision about a specific proposed action.

The reviewed systems are converging on a common request-response shape while differing in scope. MCP elicitation is a protocol-level mechanism for servers to request structured input or direct a user to a protected external interaction. OpenAI Responses API MCP approvals gate data disclosure to remote MCP tools, while the OpenAI Agents SDK extends approval to function tools, local MCP servers, shell commands, patches, delegated agents, and resumable runs. LangGraph interrupts provide a general checkpoint-and-resume primitive that applications can turn into approval, editing, validation, or escalation workflows. Google ADK tool confirmation attaches confirmation to a particular function call and validates the resumed request against session history. Microsoft Agent Framework models approval as typed request and response content that can cross local or remote agent boundaries and be correlated by ID.

The central finding is that a confirmation dialog is not an approval system. A production approval control needs at least six properties: immutable action identity, complete reviewer context, authenticated decision identity, durable pending state, single-use execution semantics, and an auditable result. Without those properties, a user can approve one set of arguments while a changed call executes, an old approval can be replayed, parallel calls can be misbound, or a paused run can resume under changed tools and policy.

The strongest architecture treats approval as a fail-closed capability lease for one canonical action. The lease should bind the reviewer, tenant, agent run, tool identity and provenance, normalized arguments, destination, authorization scope, policy version, expiry, and action digest. Execution should consume that lease once. Any material mutation after review—including changed arguments, destination, tool version, credentials, or policy—should invalidate the decision and create a new request.

MCP’s July 2026 protocol makes input requests and retries more explicit through multi-round-trip requests, InputRequiredResult, inputResponses, and requestState. That improves interoperability, especially for structured forms and sensitive URL-based interactions. It does not by itself define enterprise approver identity, separation of duties, quorum, expiry, or one-time consumption. Framework-level systems provide richer local execution control, but they also leave important product responsibilities to the application: reviewer authentication, policy evaluation, queue ownership, notifications, service-level objectives, audit retention, and safe deployment across code changes.

For operators, the recommended pattern is to place an approval broker outside the model-controlled process. The broker should receive canonical action envelopes from agents, evaluate risk policy, route high-risk requests to the correct reviewer, persist pending state, validate the response against the original envelope, issue a short-lived single-use execution grant, and write a tamper-evident receipt. Low-risk read operations may be auto-approved by policy; irreversible, externally visible, high-value, or privilege-changing operations should require explicit review.

Key Findings

• Approval and elicitation overlap but are not identical. MCP elicitation can collect structured data or consent to open a URL. An approval system must additionally bind a decision to the exact action that may execute.
• The action under review must be canonical and immutable. Tool name alone is insufficient. Reviewers need normalized arguments, destination, account or tenant, expected side effects, data leaving the boundary, and the tool version or digest.
• Resume integrity is a security boundary. Google ADK’s July 2026 continuation-forgery fix verifies that the tool is registered, still requires confirmation, exists in session history, and has matching name and arguments. Those checks generalize to every approval implementation.
• Durability is necessary but not sufficient. LangGraph checkpoints, OpenAI RunState, Microsoft sessions and workflows, and MCP request state can preserve a pause. They do not automatically solve approval expiry, code-version compatibility, reviewer authentication, or once-only execution.
• Rejection and cancellation are different operational states. MCP explicitly distinguishes decline from cancel. A denial should normally terminate or reroute the proposed action; a dismissal, timeout, or unavailable reviewer may permit later retry under policy.
• Parallel calls require call-level correlation. A batch-level “approve” control can accidentally authorize unrelated calls. Every requested action needs a stable ID and an independent decision, even if the UI offers grouped review.
• Approval defaults should be risk-based. OpenAI remote MCP calls default to approval before data is shared. Mature systems should combine secure defaults with explicit policy rather than training users to accept every prompt.
• Approval does not replace authorization. A reviewer cannot grant authority that neither the user nor workload possesses. OAuth scopes, role checks, transaction limits, resource policy, and downstream enforcement must still reject unauthorized execution.
• Approval does not neutralize prompt injection. The reviewer may be shown attacker-controlled text, incomplete context, or a misleading label. The approval UI must be rendered from trusted structured fields, not from model-generated summaries alone.
• Long-pending work needs version controls. OpenAI recommends storing an agent or SDK version with serialized state. More generally, resumed work should be rejected or re-reviewed when model, prompt, tool schema, code, policy, or authorization context has materially changed.

Methodology

This analysis reviewed public specifications, official technical documentation, source repositories, architecture decisions, samples, and commit history available on 6 August 2026. The Applied Technology Index live research index and local public content collection were checked first to avoid duplicate coverage. Current technical activity was used for topic discovery: MCP’s 28 July 2026 protocol release formalized multi-round-trip input requirements, OpenAI updated its Agents SDK human-in-the-loop documentation for the 0.19.0 release on 27 July, and Google ADK merged a continuation-forgery fix for tool confirmation on 24 July. Substantive claims are grounded in the primary and official sources listed in References; social chatter was not used as evidence.

The comparison applies nine criteria:

1. Scope: whether the primitive covers remote MCP calls, local functions, shell or patch actions, general graph execution, delegated agents, or arbitrary user input.
2. Action binding: whether the approval response is correlated to a specific call ID, tool, arguments, session, and original request.
3. Reviewer context: which trusted fields can be shown before a decision, including tool name, arguments, server, destination, requested data, and explanatory text.
4. Decision model: whether the system distinguishes approval, rejection, cancellation, editing, structured input, conditional rules, or sticky decisions.
5. Persistence and resume: how pending work survives process boundaries and how the runtime restores the correct state.
6. Parallelism: whether multiple pending tool calls can be independently approved or rejected.
7. Integrity controls: checks that prevent argument substitution, response forgery, stale approvals, or repeated execution.
8. Protocol portability: whether request and response objects can cross process, provider, framework, and remote-agent boundaries.
9. Operator responsibility: security and governance properties not supplied by the primitive, including approver authentication, routing, expiry, quorum, audit retention, and downstream authorization.

This is a documented-capability and architecture comparison, not a benchmark. No common agent workflow was executed across all systems, no hosted control plane was penetration-tested, and no latency, availability, adoption, or total-cost ranking is asserted. The systems operate at different layers: MCP is a protocol; OpenAI Responses is a managed API; OpenAI Agents SDK, LangGraph, Google ADK, and Microsoft Agent Framework are developer frameworks. The comparison asks how their primitives contribute to one governed approval architecture, not which product is universally best.

Comparative Analysis Table

Observed Profiles

MCP elicitation: interoperable input, consent, and out-of-band interaction

MCP 2026-07-28 defines elicitation as a way for a server to request information from a user through the client while the client retains control over interaction and data sharing. The protocol provides two modes. Form mode requests structured data under a restricted JSON Schema. URL mode sends the user to an external URL for interactions—such as third-party authorization—that must not pass through the MCP client.

That distinction is an important security property. The specification prohibits servers from using form mode to request passwords, API keys, access tokens, or payment credentials. For sensitive interactions, URL mode keeps secrets outside the client and model context. The client must show the target host, obtain explicit consent before navigation, avoid prefetching the URL, display the full URL for examination, and open it in a way that prevents the client or LLM from inspecting the user’s inputs.

The July protocol integrates elicitation into multi-round-trip requests. A tool call can return an InputRequiredResult containing one or more input requests. The client retries the original method with a different JSON-RPC request ID, keyed inputResponses, and the server-provided requestState when present. This is a retry of the operation with new input, not a continuation of the same JSON-RPC request.

MCP defines three response actions: accept, decline, and cancel. The distinction matters. decline records an explicit negative decision. cancel covers dismissal without a decision, such as closing a dialog, pressing Escape, or failing to load a browser. A server should not interpret cancellation as denial or acceptance, and it must handle failed, declined, and canceled requests rather than assuming input always arrives.

URL-mode acceptance also has a narrow meaning: the user consented to open or begin the external interaction. It does not prove that the external authorization, payment, verification, or enrollment completed. The server must determine completion from bound state and the out-of-band result when the client retries.

For approval architecture, MCP supplies useful protocol pieces: structured request payloads, explicit negative states, multi-step retry state, server attribution, and security rules for sensitive input. It intentionally does not define who inside an enterprise may approve a production deployment, whether two people must approve a wire transfer, how long consent remains valid, or how a downstream executor consumes approval exactly once. Those belong in the client, server, policy layer, or an approval broker.

Tool metadata should not silently decide the gate. MCP’s tools specification says clients should prompt for confirmation on sensitive operations and show tool inputs before calling a server, but it also warns that tool annotations are untrusted unless they come from trusted servers. A malicious tool cannot be allowed to classify itself as harmless and bypass review.

OpenAI Responses API: approval before remote MCP data disclosure

OpenAI’s Responses API exposes remote MCP tools and connectors as managed tools. Its documented default is to request approval before any data is shared with a connector or remote MCP server. The Response contains an mcp_approval_request with an ID, tool name, serialized arguments, and server label. The application continues by supplying an mcp_approval_response that references the approval request ID and sets approve to true or false.

This makes the immediate security boundary concrete: the model may propose a remote tool call, but the application decides whether the proposed arguments may leave the OpenAI-controlled workflow for that MCP server. The documentation recommends reviewing and optionally logging all data shared with remote servers. It also allows require_approval: "never" for trusted cases, trading review latency for automatic execution.

The system’s strength is a clear hosted gate with secure defaults and provider-managed correlation. It is narrower than a complete enterprise approval service. The API item does not establish that the person clicking approve is the correct business owner, that the destination account is within policy, or that a transaction complies with a separation-of-duties rule. Applications must authenticate the reviewer, render trustworthy context, retain business evidence, and preserve downstream authorization checks.

The approval is also a data-sharing gate, not a guarantee that a remote MCP server is trustworthy. OpenAI recommends using official servers hosted by the underlying service provider and warns about third-party aggregators. Approval should therefore include server identity and destination, not only the human-readable tool name and arguments.

OpenAI Agents SDK: a run-wide approval model across tool classes

The OpenAI Agents SDK for Python provides a broader framework-level human-in-the-loop model. Function tools and delegated agents can declare needs_approval; local MCP servers use require_approval; hosted MCP tools can require approval and optionally use an approval callback; shell and patch tools support manual or programmatic decisions. A conditional function can inspect parsed arguments and decide whether a particular call requires review.

When a call is gated, the runner pauses and returns one or more ToolApprovalItem interruptions with the agent name, tool name, and arguments. The application converts the result to RunState, approves or rejects individual interruptions, and resumes the original top-level agent. The same outer interruption flow applies when the proposed action occurs after a handoff or inside a nested Agent.as_tool() run.

Call-level binding is a significant property. A decision already stored for one call ID allows that call to proceed; it does not automatically authorize another call. The SDK can persist “always approve” or “always reject” decisions for future uses of that tool during the same run, but those sticky decisions should be treated as temporary policy, not universal consent. Their scope and lifetime need to be visible to the reviewer.

The SDK also handles partial resolution. If a run contains several pending approvals, an application may resolve only some and resume. Approved or rejected calls can progress while unresolved calls remain interrupted. This is safer than a single batch decision, provided the UI preserves each call’s identity and does not obscure independent arguments.

Malformed arguments fail closed for conditional approval functions. The documentation states that malformed JSON, non-object JSON values, and non-standard constants prevent the callable from being used and force manual approval. That is the correct direction: parsing ambiguity must not become an auto-approval path.

RunState can be serialized and stored in a database or queue for long-running decisions. The documentation recommends preserving an agent-definition or SDK version marker when approval may be delayed. It also warns that serialized state contains application context and SDK runtime metadata, potentially including tool input and trace settings. Pending-state storage therefore needs encryption, access control, retention, and data minimization.

The application remains responsible for expiry and mutation policy. If a serialized run resumes after a tool implementation, authorization scope, model, prompt, or policy changed, the technically valid SDK state may no longer represent a valid business decision. A production wrapper should compare version and action digests before resuming.

LangGraph interrupts: flexible pause-and-resume with application-defined semantics

LangGraph interrupts are a general control-flow primitive rather than a dedicated approval protocol. Calling interrupt() from a graph node saves state through the persistence layer and surfaces a JSON-serializable payload. The graph waits until the application invokes it again with a Command. A checkpointer stores the state, and thread_id identifies the persistent cursor to resume.

This flexibility supports several patterns beyond binary approval: approve or reject a critical action, review and edit model output, validate user input, interrupt a tool call, or route the graph to a different node. For workflows where a reviewer must modify an email, SQL statement, deployment plan, or transaction amount before execution, editable state is more useful than a yes-or-no button.

The flexibility also means that core approval semantics are not supplied automatically. The application chooses the interrupt payload, reviewer UI, authenticated identity, correlation ID, expiry, policy, and audit format. An interrupt that exposes only “Approve this action?” is technically valid but operationally weak.

LangGraph documents a crucial execution behavior: the node containing an interrupt restarts from the beginning when resumed. Code before the interrupt runs again. Side effects before the pause must therefore be idempotent, or they should be moved after the interrupt or into separate nodes. Otherwise, merely opening and approving a review can duplicate a database write, message, charge, or provisioning call.

The same principle applies outside LangGraph. Approval boundaries should be placed before all irreversible side effects. Preparation may calculate a plan and render a preview; execution should occur only after a valid decision is consumed. If the framework replays preparation, it should produce the same canonical action envelope without external mutation.

LangGraph’s checkpointer solves recoverability, not staleness. A production system still needs to decide what happens when the graph definition changes while work is paused, when the reviewer’s role is revoked, or when the target resource changed. Revalidation before resume is mandatory for long-lived requests.

Google ADK: tool confirmation and continuation integrity

Google ADK supports both static and dynamic tool confirmation. A FunctionTool can set require_confirmation=True, causing confirmation before the function body executes. A tool can also inspect its ToolContext and call request_confirmation() only for selected arguments—for example, transfers above a threshold. When the user responds, the tool is called again with tool_confirmation populated, including the confirmation decision and optional JSON-serializable payload.

Current source marks ToolConfirmation as experimental. The model includes a human-readable hint, a confirmed boolean, and an optional payload. Experimental status matters for procurement: teams should pin a compatible version and test serialized event behavior rather than assuming a permanent API contract.

The most instructive part of ADK’s current implementation is its continuation validation. A July 2026 security fix addressed forged continuation risk. Before re-executing a confirmed tool, the processor now checks that the original call exists in session history, the tool is registered, the tool actually requires confirmation, and the stored name and arguments exactly match the confirmation target. It also maps confirmation function-call IDs back to original function-call IDs and avoids re-consuming confirmations that already produced a response.

Those checks expose a general failure mode. If an attacker or corrupted client can inject a confirmation response that names a tool and arguments without binding it to an authentic pending call, “confirmation” becomes a new tool-invocation channel. The approval layer must never trust the response’s copy of the action by itself; it must retrieve the canonical pending action from trusted storage and compare the response correlation data against it.

ADK’s sample supports parallel tools in one model step. That makes call-level IDs and independent confirmation records essential. A UI may group several transfer and account-change calls, but the backend should still issue and consume separate decisions unless policy explicitly defines an atomic batch with its own digest.

Google’s broader workflow human-in-the-loop work also distinguishes resumable checkpoint mode from replay-oriented operation. For complex or multi-step approvals, checkpointed resumability is the safer foundation because it reduces ambiguous reconstruction. Regardless of mode, unique interrupt IDs are required when a review can repeat in a loop; reusing an old identifier risks binding a later review to an earlier response.

Microsoft Agent Framework: typed approval content across local and remote boundaries

Microsoft Agent Framework models approval as content exchanged with the caller. A tool can declare approval_mode="always_require". The resulting agent response contains user-input requests, including a function approval request with the function name and arguments. The caller converts that request to an approval or rejection response and runs the agent again on the same session.

The framework’s accepted architecture decision explains why typed content was preferred over an in-process callback. A callback works when the user and agent share an application process, but it does not fit a remote agent when the user may respond later. Returning a request object allows the run to finish for now, lets another application authenticate and collect the decision, and then lets the caller resume the agent with correlated response content.

The chosen model uses base user-input request and response types, with specialized function approval, text approval, and structured-data input forms. Each pair has an ID. A function approval can include the proposed function call, while other subclasses can carry explanatory text or a schema. This is conceptually close to a portable approval envelope and makes it possible to represent local tools, service-side MCP calls, custom remote agents, and non-binary input within one content system.

Microsoft’s design also addresses multiple calls. The approval flow can return several function approval requests and receive mixed outcomes. Approved functions execute; rejected functions become denied function results that are returned to the model. As with other frameworks, the application should make each decision explicit rather than collapsing parallel calls into one unscoped button.

The architecture decision identifies an audit gap: service-managed threads may not support long-term storage of framework-specific approval request and response content even when local threads do. It therefore calls for approval logging for debugging and auditing. Operators should treat framework thread history and compliance evidence as separate systems unless retention, immutability, export, and identity guarantees are explicitly verified.

The framework’s request-response content is a useful transport shape, but business controls remain external. The reviewer must be authenticated independently; the tool arguments need canonicalization; the pending request must expire; and the executor must reject mismatched, replayed, or already-consumed responses.

Control Architecture for Production Approval

1. Create a canonical action envelope

Before any side effect, convert the proposed operation into a deterministic envelope. At minimum it should contain:

• tenant, user, agent, run, thread, and call identifiers;
• tool namespace, tool name, server identity, package or image digest, and schema version;
• normalized arguments and destination resource;
• data classifications and fields that will leave the trust boundary;
• authorization scopes and credentials that execution will use;
• predicted side effects, reversibility, value, and risk class;
• model, prompt, workflow, tool-policy, and approval-policy versions;
• creation time, expiry, and a cryptographic digest of the envelope.

The UI can add a plain-language summary, but the structured envelope—not model-generated prose—must define what approval authorizes.

2. Evaluate policy before involving a person

A policy engine should classify the action. Read-only calls to approved internal systems may proceed automatically. Public posting, external messaging, payment, deletion, privilege changes, production deployment, customer-data export, or credential creation should usually require review. Policy may require the resource owner, budget owner, security team, or two independent approvers.

Auto-approval must produce the same kind of receipt as human approval, including the policy and rule that made the decision. Otherwise, the highest-volume path becomes the least auditable path.

3. Authenticate the reviewer and render trusted context

The approval application should authenticate the reviewer with the organization’s identity provider and evaluate current role, tenant, resource ownership, and conflicts of interest. The interface should show the exact action, arguments, destination, data disclosure, expected result, reversibility, and expiry. It should identify which agent and tool requested the action and whether any content originated from an untrusted webpage, document, email, or MCP server.

Do not let an agent write the only explanation. An attacker can inject text such as “already approved by finance” into retrieved content. Trusted fields should be rendered by the application from the canonical envelope, with untrusted context visually separated.

4. Persist a decision, not an ambient permission

The response should reference the pending request ID and action digest and record reviewer identity, decision, time, authentication strength, comments, and policy version. “Always approve” options should have explicit scope, such as one run, one tool on one tenant, a bounded argument pattern, and a short expiry. They should never silently become indefinite organization-wide authority.

Decline, cancel, timeout, superseded, and expired should remain distinct terminal or transitional states. A canceled request may be retried; a declined request should not be repeatedly re-presented without a material change or escalation policy.

5. Revalidate and consume once

Immediately before execution, the trusted executor should retrieve the original envelope, verify the decision signature or trusted database record, compare the digest, re-check authorization and policy, and atomically mark the grant consumed. If the destination, arguments, tool digest, identity, policy, or resource state changed materially, execution should stop and require a new review.

Idempotency keys and downstream transaction identifiers should protect against network retries after approval. The approval database’s “consumed” flag alone cannot prevent duplicate external effects if the executor crashes between the side effect and local state update.

6. Record the outcome

The final receipt should link proposal, decision, execution attempt, downstream result, and any compensation or rollback. Minimum fields include request and call IDs, action digest, reviewer, decision, timestamps, policy, executor identity, tool digest, downstream transaction ID, result, error, and evidence-retention location. Approval latency, timeout rate, rejection rate, stale-request rate, and incidents caused by misleading context should be monitored as operational metrics.

Deployment and Procurement Implications

Ask what exactly is bound to the decision. A vendor that says it supports human approval should demonstrate correlation among call ID, tool, normalized arguments, destination, tenant, and original session. Name-only confirmation is not enough.

Test response forgery and substitution. Attempt to approve a non-pending call, change one argument after approval, swap call IDs, replay a consumed response, approve a tool that no longer requires review, and resume under a different tenant. Every case should fail closed.

Test parallel and repeated calls. Generate two calls to the same tool with different arguments and mixed decisions. Then generate a later call with the same name. The earlier approval must not leak into the later call unless an explicit bounded policy permits it.

Verify pause durability and deployment compatibility. Stop the worker after producing a request, resume from another process, deploy a new workflow version, rotate credentials, revoke the reviewer, and let the request expire. Document which changes invalidate pending work.

Separate the approval queue from the agent runtime. The model-controlled process should not be able to write its own approved state, select an unauthorized reviewer, or modify the canonical envelope after routing. Use a control-plane service or trusted workflow component.

Preserve downstream enforcement. The executor should use least-privilege credentials and resource-side controls. If approval data disappears, the downstream API must still enforce transaction limits, tenant boundaries, and OAuth scopes.

Reduce approval fatigue. High prompt volume trains reviewers to click through. Use risk tiers, grouped presentation with call-level decisions, standing policies for low-risk patterns, clear consequences, and periodic review of auto-approval rules. Measure approvals per successful task and false-positive review rate.

Require exportable evidence. Confirm whether approval requests, responses, reviewer identity, and execution receipts can be exported independently of chat history. Service-managed threads and transient API responses are not automatically compliance-grade audit logs.

Treat edits as new actions. If a reviewer changes an argument, the system should generate a new canonical envelope and digest. The edited version can inherit context, but the final decision must bind to what will execute.

Define emergency and unattended behavior. Pending high-risk requests should not auto-approve because a reviewer is unavailable. Policy should specify timeout, escalation, cancellation, and safe rollback. Fail-open behavior should be exceptional, explicit, and separately audited.

Limitations

This analysis relies on public specifications, documentation, source repositories, samples, architecture decisions, and commit history available on 6 August 2026. Hosted features, enterprise controls, service-managed thread behavior, and private roadmaps may differ from what is publicly documented. Google ADK’s tool-confirmation API is marked experimental in current source, and fast-moving framework APIs may change.

The systems are not direct substitutes. MCP defines interoperable client-server behavior; OpenAI Responses provides managed remote-tool approvals; framework primitives execute inside application code; LangGraph interrupts are general control flow; and Microsoft approval content is a transport model. A complete production implementation may combine several—for example, MCP elicitation at the protocol edge, a durable workflow for pending state, an enterprise approval broker, and a least-privilege executor.

No hands-on interoperability suite was run. The analysis does not measure median approval latency, throughput, storage overhead, hosted availability, adoption, price, reviewer usability, false approval rates, or incident reduction. It also does not verify cryptographic protection of every framework’s serialized state or hosted audit log.

Documentation examples simplify identity and policy. Several samples automatically approve for demonstration purposes; that demonstrates the response path, not a recommended production control. Architecture claims in this article distinguish documented primitives from the additional controls an operator must build.

Human review itself is fallible. Reviewers can misunderstand arguments, approve attacker-influenced content, or suffer prompt fatigue. Approval should be one layer alongside strong authorization, data-loss prevention, sandboxing, destination controls, transaction limits, observability, provenance verification, and post-execution reconciliation.

References

1. Model Context Protocol 2026-07-28: Elicitation
2. Model Context Protocol 2026-07-28: Tools
3. OpenAI: MCP and connectors in the Responses API
4. OpenAI Agents SDK for Python: Human-in-the-loop
5. LangGraph: Interrupts
6. Google ADK Python: Tool confirmation sample
7. Google ADK Python: ToolConfirmation source
8. Google ADK Python: Confirmation request processor
9. Google ADK Python: continuation-forgery fix commit
10. Microsoft Agent Framework architecture decision: user approvals
11. Microsoft Agent Framework Python: function-tool approval with sessions
12. Microsoft Agent Framework Python: agents with approval requests in workflows

Changelog

• 2026-08-06: Initial publication.

Corrections

No corrections have been issued for this document.