Human approval for AI agents: designing the enterprise execution boundary

AI agents become operationally useful when they can do more than answer questions. They need to call tools, change records, trigger workflows, send messages, edit systems, and sometimes operate browsers or devices.

That is also the point where the risk model changes.

A model can be wrong in a chat response and create confusion. A model can be wrong in a production write and create an incident.

The practical design question is therefore not whether an agent should be autonomous. It is which actions should be autonomous, which should be constrained, and which should pause for explicit approval before execution.

The strongest enterprise agent systems treat approval as part of the execution protocol—not as a confirmation dialog added at the end of the UI.

In 2026, the industry is converging on a clearer architecture for agent actions.

NIST’s AI Agent Standards Initiative explicitly focuses on secure interoperability for agents that can take autonomous actions on behalf of users. NIST’s separate work on software and AI agent identity and authorization also highlights the need for appropriate identification and authorization controls when agents access data, tools, and applications.

Current agent frameworks are moving in the same direction. OpenAI’s guidance distinguishes automatic guardrails from human review, recommending approvals around side effects such as cancellations, edits, shell commands, and sensitive MCP actions.

The pattern is simple:

• low-risk work should remain fast;
• policy should block known-bad actions automatically;
• ambiguous or high-impact changes should pause;
• the reviewer should see the exact proposed action;
• the approved action should be the action that executes;
• the result should remain auditable.

That last point is where many implementations break down.

Permission answers:

“Is this agent allowed to use this capability?”

Approval answers:

“Should this specific proposed action execute now?”

They are different controls.

An employee may be authorized to use a CRM. An agent working for that employee may be authorized to call a CRM connector. That still does not mean every destructive or irreversible CRM write should run without review.

A robust agent system needs both layers.

Control	What it answers	Typical scope
Identity	Who is making or delegating the request?	user, service, agent
Permission	What capabilities may this identity access?	application, tool, record, environment
Policy	What rules apply to this action?	risk class, target, time, data type
Approval	Should this exact proposal proceed?	concrete action + parameters
Execution	What actually happened?	provider call, browser action, system mutation
Evidence	Can the organization reconstruct the event?	request, decision, approver, result

Treating these as one checkbox creates hidden authority.

A useful approval object is more precise than “Allow this agent?”

It should contain enough information for a reviewer to understand the actual side effect.

At minimum:

• actor — the user, service, or agent requesting the action;
• tool — the exact capability that will execute;
• target — the object, system, environment, account, or resource;
• operation — create, update, delete, send, publish, deploy, restart, etc.;
• parameters — the values that materially change the result;
• risk reason — why approval is required;
• scope — whether approval applies once or to a tightly bounded class of actions;
• expiry — how long the approval remains valid;
• evidence link — the context that produced the recommendation.

The more consequential the action, the less useful a vague confirmation becomes.

This is one of the most important implementation details.

Imagine an agent proposes:

Restart service A in staging.

A person approves it.

If the runtime later executes:

Restart service B in production.

the system did not actually enforce approval. It merely collected consent around an earlier description.

The approval should therefore bind to the canonical proposed action, including the target and material parameters.

A practical design is:

The execution service should verify that the approved proposal still matches what is about to run.

A production approval system is not a button. It is a state machine.

The lifecycle usually looks like this:

1. Intent — the user asks for an outcome.
2. Plan — the agent decides which systems and actions are needed.
3. Proposal — the runtime materializes one exact action or action bundle.
4. Policy evaluation — deterministic controls decide whether the proposal can proceed automatically, must be denied, or requires review.
5. Approval request — the review object is created with context, risk reason, expiry, and proposal digest.
6. Human decision — an authorized reviewer approves, rejects, modifies, or escalates.
7. Pre-execution verification — the execution layer confirms that the proposal, identity, target, and authorization are still valid.
8. Execution — the tool, API, browser, device, or workflow action runs.
9. Reconciliation — the platform verifies what actually happened.
10. Evidence — request, decision, execution, and outcome are linked for later inspection.

This model matters because many “human-in-the-loop” designs implement only steps 5 and 6. The difficult parts are steps 7 through 10: proving that what was approved is still what will execute, handling uncertain outcomes, and preserving the chain of evidence.

Some approvals happen while the user is actively watching the agent. Others happen hours later.

A synchronous approval might look like:

The agent wants to send this email to 42 customers. Review recipients and message, then approve.

An asynchronous approval might arrive in a governance inbox after the original user has left the session:

Production database index change proposed by Database Optimization Agent. Approval expires in 45 minutes.

The execution model must support both without turning asynchronous review into a new, unrelated agent turn.

OpenAI’s current agent runtime guidance treats approval as a paused run that should resume from the same state rather than starting over. That is a useful design principle beyond one framework: approval should pause execution, not erase execution context.

For asynchronous approval, preserve:

• serialized run or workflow state;
• proposal ID and hash;
• model/tool version where relevant;
• policy decision;
• evidence snapshot;
• requesting identity;
• approver eligibility;
• expiry;
• continuation pointer;
• final execution result.

If the underlying state changes materially while waiting, the system should invalidate the old approval and generate a new proposal.

“Human approval” is incomplete unless the system defines which human.

The reviewer should be authorized for both the business action and the execution scope.

Proposed action	Eligible approver	Additional condition
Send customer email	campaign owner	audience under approved segment
Refund under threshold	support supervisor	verified customer + case
Refund over threshold	finance approver	second approver above limit
Restart staging service	service owner	active incident or change ticket
Deploy production change	production owner	passing checks + release reference
Grant privileged access	security administrator	expiry + reason required
Delete regulated data	data owner / privacy role	legal basis + retention check

The approval service should evaluate approver eligibility at decision time, not only when the request is created.

Some actions justify multi-party approval.

This is common where organizations already use four-eyes controls, segregation of duties, or dual authorization.

Examples include:

• large financial transfers;
• production credential rotation;
• privileged identity changes;
• deletion of regulated records;
• changes to agent governance policy itself;
• actions that alter audit or logging systems.

A multi-party approval model should define:

• number of required approvers;
• whether approvers must hold distinct roles;
• whether the requester may approve;
• whether order matters;
• whether any rejection terminates the request;
• expiry and re-approval rules;
• what happens if the proposal changes after the first approval.

Do not implement multi-party approval as “two people clicked yes.” The policy should make the separation of authority explicit.

The best approval interface is not the one with the fewest pixels. It is the one that helps a qualified person make the right decision quickly.

A useful approval card should usually show:

A plain-language goal:

Restore checkout availability after the latest deployment.

The concrete proposal:

Rollback service checkout-api in production from release 8f92 to 8e71.

Evidence:

• error rate increased after release;
• database health remains normal;
• previous release is currently healthy in another region;
• rollback is reversible.

Policy:

Production deployment changes require a service owner.

Scope:

• service: checkout-api;
• environment: production;
• region: ap-southeast;
• expected impact: temporary connection drain;
• rollback plan: redeploy current release if health degrades.

If approved, Agent Connect executes the rollback and monitors health for five minutes.

This is far more useful than a dialog saying “Allow tool use?”

Real work is rarely binary.

A reviewer may agree with the plan but want to change one parameter.

Examples:

• send to 20 customers instead of 2,000;
• deploy to one region first;
• reduce refund amount;
• shorten access expiry;
• use a staging environment;
• redact one field from an export.

When a reviewer modifies a proposal, the platform should create a new canonical proposal and evaluate it again. The modification itself should be visible in the evidence chain.

Some systems let users approve a class of repeated actions to reduce friction.

Examples:

• approve this command once;
• approve this tool for the rest of the session;
• approve writes to this project for one hour;
• approve access to this domain today.

This can be useful, but scope expansion is one of the easiest ways to turn a safe approval model into ambient authority.

A reusable approval should therefore be explicit about:

• action class;
• target boundary;
• parameter constraints;
• identity;
• time window;
• environment;
• maximum count or value;
• revocation.

Approval is strongest when paired with technical containment.

OpenAI’s current Codex deployment guidance describes this relationship clearly: the sandbox defines what the agent can do without crossing a boundary, and the approval policy determines what happens when the agent attempts to cross it.

This generalizes well.

For an enterprise agent:

• the sandbox or tool scope defines the default execution envelope;
• policy determines allowed and denied classes;
• approval handles selected boundary crossings;
• telemetry records what occurred.

That is safer than using approval as the only control around an otherwise unrestricted runtime.

Approval does not eliminate prompt injection.

An attacker may attempt to manipulate the agent into proposing a harmful action that still looks plausible to a reviewer.

For example, a malicious web page might tell a browser agent to:

• upload internal files;
• send credentials;
• change account recovery settings;
• approve an unexpected OAuth scope;
• create a hidden forwarding rule.

The approval system should therefore surface the source of the proposal and separate untrusted content from trusted policy.

Good patterns include:

• show which page, message, document, or API result influenced the action;
• label untrusted external content;
• validate structured tool arguments;
• apply domain and target restrictions before review;
• never let webpage text change approval policy;
• require stronger review for credential, identity, and security actions.

A human cannot review what the interface hides.

MCP makes tools easier to expose to agents, but the approval question remains local to the action.

A platform should know:

• which MCP server supplied the tool;
• who owns or operates that server;
• how the server authenticated;
• which tool was selected;
• what arguments were passed;
• whether the tool is read-only or mutating;
• whether the server can call downstream systems;
• what response came back.

For high-impact tools, the approval object should include the resolved server and tool identity—not only a friendly display name.

Browser and trusted-device actions are harder to summarize than a typed API call.

A browser action may include:

• current URL;
• target origin;
• page state;
• selected element;
• typed text;
• file upload;
• download;
• navigation;
• authentication state.

A desktop action may include:

• device identity;
• active window;
• application;
• process;
• filesystem path;
• keyboard shortcut;
• clipboard use.

For these surfaces, a useful approval may need a screenshot, window title, target URL, or proposed sequence of actions.

The goal is not to show every mouse coordinate. It is to summarize enough context to understand the intended side effect.

The system performs the write and then asks for confirmation.

That is not approval. It is notification.

The user approves “update CRM” while the actual record IDs and fields remain unknown.

The approval is too broad.

The reviewer approves one set of parameters, but the model is called again and produces different parameters before execution.

The approval is no longer bound to the action.

The provider times out, and the platform runs the approved action again without checking whether it already succeeded.

This can duplicate emails, payments, tickets, or destructive writes.

A user approves an action during one incident, and the system converts that into a durable capability grant.

The scope has silently expanded.

Any logged-in user can approve a privileged action.

Human review exists, but authorization does not.

The audit record says “approved” but cannot reconstruct the proposed parameters or execution outcome.

The organization cannot verify what the approval meant.

A practical architecture can separate six responsibilities.

Component	Responsibility
Agent runtime	reason, plan, prepare proposals
Policy engine	classify and constrain actions
Approval service	create, route, expire and resolve review requests
Execution service	verify proposal and perform the action
Identity service	authenticate user, agent and approver
Evidence store	link intent, policy, approval, execution and outcome

A simplified data model might include:

ActionProposal
  proposal_id
  requesting_user_id
  agent_id
  tool_id
  target
  operation
  parameters_hash
  parameters
  risk_class
  policy_version
  created_at
  expires_at

ApprovalDecision
  proposal_id
  approver_id
  decision
  reason
  approved_parameters_hash
  decided_at

ExecutionRecord
  proposal_id
  execution_id
  credential_reference
  started_at
  completed_at
  status
  provider_receipt
  result_summary

The important property is the join key: the same proposal should connect the request, approval, and execution.

A buyer or platform team should test more than whether an approval dialog appears.

Use a scenario with real state changes.

1. Ask the agent to read a system.
2. Ask for a low-risk write.
3. Ask for a high-risk write.
4. Change the target after the proposal is generated.
5. Let the approval expire.
6. Revoke the requester’s permission before approval.
7. Approve with a reviewer who lacks the required role.
8. Simulate a provider timeout after execution.
9. Retry the run.
10. Inspect the audit trail.
11. Modify the proposal and approve the modification.
12. Attempt to replay an old approval.

A strong platform should fail safely in each case.

When evaluating an agent platform, MCP gateway, or action layer, ask:

• Can approvals be required by policy rather than hard-coded UI?
• Can the platform distinguish reads, writes, destructive actions, and security-sensitive operations?
• Is the approver identity verified?
• Can approval rules depend on target, environment, amount, record count, or data classification?
• Is approval bound structurally to the exact proposal?
• What invalidates an approval?
• Can approvals expire?
• Can reviewers modify proposals?
• Are delayed approvals resumable?
• How are retries reconciled?
• Can the platform support dual approval?
• Are browser/device actions represented clearly?
• What audit evidence is retained?
• Can approval data export to SIEM, GRC, or compliance systems?
• What happens when policy or identity services are unavailable?

These questions expose the difference between a demo workflow and an enterprise execution control.

A system that asks for permission every few seconds is technically controlled but practically unusable.

The goal is not maximum friction. The goal is risk-sensitive friction.

A useful model is to classify actions.

Risk class	Example	Default treatment
Read-only	retrieve records, search documents	allow if authorized
Low-impact write	add an internal note, draft content	allow or lightweight policy
Reversible write	update a non-critical field	policy-based, optional approval
External communication	send email, post message	often approval-sensitive
Financial / legal	issue refund, change billing, submit contract	explicit approval
Destructive	delete data, terminate process, revoke access	explicit approval
Production / security	deploy, restart, modify policy, change credentials	explicit approval or stronger multi-party control

The exact classification depends on the organization, but the architecture should make the distinction explicit.

Approval should not become a substitute for good system design.

A reviewer should not have to catch everything that could have been prevented automatically.

Use policy and guardrails first.

Examples:

• prevent production writes from a development agent;
• prevent a finance agent from accessing HR records;
• restrict which domains a browser agent may open;
• prevent a device agent from launching prohibited applications;
• constrain monetary values or record counts;
• limit tools to the current workspace or organization;
• deny actions outside business hours where appropriate;
• require stronger controls when sensitive data is involved.

Then use human approval for the smaller set of consequential decisions that remain.

This mirrors current agent guidance: automated guardrails handle deterministic checks, while human review handles sensitive or ambiguous actions.

A good approval system does not force the user to reconstruct the task.

The reviewer should see:

1. what the agent is trying to accomplish;
2. what evidence informed the proposal;
3. exactly what will change;
4. the expected impact;
5. the risk reason;
6. the action buttons;
7. an option to modify or reject;
8. what will happen after approval.

The user should not have to reopen six tabs just to understand a confirmation card.

Not every approval belongs in chat.

Some are better in:

• a deployment review panel;
• an admin console;
• a finance approval queue;
• a mobile notification;
• a Slack workflow;
• an incident channel;
• a dedicated governance inbox.

The approval object should therefore be portable across channels.

That requires the approval state to live in the platform—not only inside the current UI component.

An enterprise reviewer may approve a change ten minutes or two hours later.

The agent run must be able to pause and continue safely.

That means the system needs durable state around:

• the proposal;
• relevant evidence;
• tool arguments;
• policy outcome;
• approval request;
• approver decision;
• expiry;
• resumed execution.

A delayed approval should not force the agent to regenerate the action from scratch unless the context has materially changed.

If it does need to regenerate, the system should require a new approval when the resulting proposal differs.

Retries are another common failure point.

Suppose an approved action times out after reaching the provider. The runtime cannot assume it is safe to run again.

The action may have succeeded remotely even though the local system did not receive confirmation.

The execution layer therefore needs:

• idempotency where possible;
• provider-specific reconciliation;
• explicit retry policy;
• outcome verification;
• a distinction between “failed,” “unknown,” and “confirmed not executed.”

An approval to execute once should not accidentally become permission to execute repeatedly.

NIST’s 2026 work on agent identity and authorization reflects a larger shift: organizations increasingly need to know not only which human logged in, but also which software agent acted, under whose authority, with which delegated rights.

That leads to a more complete execution record:

Human:        [email protected]
Agent:        deployment-review-agent
Workspace:    production-operations
Tool:         railway.deploy
Target:       service/api-production
Proposal:     deploy commit 4e21…
Policy:       production_write_requires_approval
Approver:     [email protected]
Decision:     approved
Execution:    success
Evidence:     incident-882 / trace-1731

This is much more useful than a generic activity log saying “AI changed deployment.”

Outborn Agent Platform is being designed around the separation between reasoning and authority.

The product family divides responsibilities:

• Outborn Agent Platform — reasoning, analysis, orchestration and agent experience;
• Outborn Agent Connect — credentials, providers, MCP, browsers, devices and execution;
• Outborn Governance — policy, approvals, risk and durable evidence;
• Outborn Account — human identity, organization and application access.

The important principle is that the model does not need unrestricted access simply because it can reason about an action.

A deployment agent may be able to:

1. inspect the incident;
2. analyze logs;
3. identify the likely cause;
4. prepare a remediation;
5. create a canonical proposed action;
6. submit it for approval;
7. execute only after approval;
8. record the result.

That is a stronger boundary than embedding credentials directly inside the reasoning runtime.

This three-path model keeps normal work fast while preserving explicit control over consequential actions.

Approval systems need product metrics too.

Useful metrics include:

• approval rate by action type;
• rejection rate;
• modification rate;
• time to approval;
• abandoned approvals;
• duplicate requests;
• expired approvals;
• false-positive approval prompts;
• actions later rolled back;
• execution failures after approval;
• approval bypass incidents;
• percentage of actions handled automatically by policy.

A mature system should reduce unnecessary approvals over time without weakening control.

If users approve almost everything automatically, the system has stopped creating meaningful human oversight.

Approval fatigue usually means one of three things:

1. too many low-risk actions are being escalated;
2. approval cards lack enough context to make a real decision;
3. the organization has not defined risk classes precisely enough.

The answer is not to remove approval entirely.

The answer is to make policy more precise.

Before allowing an agent to perform consequential writes, verify:

• human and agent identities are both known;
• credentials are stored outside the model runtime;
• tool access is scoped;
• action risk is classified;
• deterministic policy runs before human review;
• the approval contains the exact target and parameters;
• approval is bound to the proposal;
• approval can expire;
• changed proposals require re-approval;
• retries are idempotent or reconciled;
• execution outcome is recorded;
• approval and execution evidence are linked;
• permission revocation takes effect without rebuilding the agent.

A strong approval system does not slow every agent action. It makes the dangerous boundary explicit while letting routine work remain fast.

Enterprise agent systems need to move beyond the binary choice between “ask the human for everything” and “let the agent do anything.”

The better architecture is risk-sensitive:

• identity establishes who is acting;
• permissions limit available capabilities;
• policy handles deterministic rules;
• human approval covers consequential or ambiguous actions;
• execution verifies the approved proposal;
• evidence connects the request, decision and result.

As agents become more autonomous, approval will matter less as a UI pattern and more as an execution primitive.

That is the level at which enterprise platforms should design it.

No. Requiring approval for every tool call creates unnecessary friction and encourages users to approve reflexively. Use identity, permissions, sandboxing, and deterministic policy to let safe actions proceed automatically. Reserve explicit approval for actions whose risk, ambiguity, or impact justifies human judgment.

No. Reads can expose sensitive data, secrets, personal information, or regulated records. A read may need authorization or even approval when the information is highly sensitive. Risk classification should consider confidentiality as well as side effects.

A guardrail applies an automatic rule or check. An approval asks an authorized reviewer to make a decision about a specific proposed action. Good systems use both: automated controls for deterministic boundaries and human review for sensitive or ambiguous decisions.

The runtime may select a tool before approval, but approval should happen before the side effect occurs. The reviewer should see the resolved tool, target, and material parameters.

A review agent can help classify risk or auto-review low-risk boundary crossings, but organizations should be explicit about which decisions require a human. OpenAI’s 2026 Auto-review work is an example of using a separate agent to reduce synchronous human interruptions while keeping higher-risk cases reviewable. This is a policy choice, not a universal replacement for human approval.

The execution service should re-check authorization immediately before execution. An old approval should not override a new revocation or policy change.

As short as practical for the action. A production deployment approval may expire quickly; approval for a low-risk recurring workflow may have a longer bounded scope. Expiry should reflect how fast the underlying state can change.

At minimum: requester identity, agent identity, proposal, tool and target, policy result, approver identity, decision, timestamps, credential reference, execution status, and relevant outcome evidence.

• NIST AI Agent Standards Initiative
• NIST concept paper on software and AI agent identity and authorization
• OpenAI — Guardrails and human review
• OpenAI — Running Codex safely
• OpenAI — Managing app permissions

Platform capabilities and standards evolve quickly. Validate the current documentation and the controls required by your own risk model before deploying approval-sensitive agent workflows.