Designing selective approval gates for agent actions

Use three policy outcomes for agent actions: automatically allow explicitly authorized, bounded work; request human approval for permitted exceptions; and deny prohibited actions outright.

In the proposed architecture below, the application—not the model—enforces those outcomes. Each approval applies to a specific operation or fixed batch. The objective is to reserve human attention for meaningful decisions without weakening authorization.

Classify the action, not just the tool

Start with an application policy that distinguishes routine work from exceptions and prohibitions. For example:

Outcome	Illustrative policy	Required execution behavior
Allow	Update labels in a named collection within an existing delegation’s count and time limits	Execute only after validation and permission checks
Require approval	Delete specified production records, where policy permits an authorized reviewer to approve	Hold the action pending a valid decision
Deny	Export restricted data to a prohibited destination	Reject, regardless of an approval click

Evaluate the affected resources, data sensitivity, destination, reversibility, and aggregate impact. Include disclosure scope even when the proposed operation uses a read-oriented tool.

Keep human approval inside the authorization policy: it should satisfy a required condition, not override a prohibition.

Put the gate on the trusted execution path

Design the agent to propose actions, not grant itself permission to execute them. Route proposals through a trusted service that:

1. Establishes the acting principal, delegating principal, and tenant from authenticated server-side context.
2. Validates the operation and arguments against an explicit tool schema.
3. Resolves targets and evaluates permissions, limits, and policy.
4. Executes an allowed action, creates a pending review, or rejects the request.

Keep execution credentials in this layer. Remove alternate tool or credential paths that would bypass the gate. Treat schema validation and authorization as separate requirements.

Treat retrieved pages, documents, and tool responses as untrusted data. Instructions inside them must not change policy, select an authorized reviewer, or stand in for approval.

Make pending review asynchronous and non-executing. Reviewer unavailability, expiry, or failure of a required authorization check must not become implicit approval. Escalation should select another authorized reviewer without expanding the proposed action’s permissions.

Bind approval to an immutable action record

Avoid approvals such as “let the agent finish this task.” Create a versioned action record that identifies the operation under review.

Include:

• Acting and delegating principals, plus the tenant.
• Tool, operation, and stable identifiers for affected resources.
• Resolved destination, recipient, or account—not only a mutable alias.
• Normalized consequential arguments, including the exact content to be sent or changed, or an immutable reference to that content.
• Maximum cost, resource count, and other applicable limits.
• Relevant resource versions or state preconditions.
• Policy version, expiry, and permitted use count.

For a batch, record its fixed membership rather than only a query that will select targets later.

Store the reviewer’s decision against that action version. Generate both the review screen and the execution request from the same validated record; do not ask the model to reconstruct the approved operation afterward.

If an alias changes after approval, do not silently follow it to a different destination. Require a new decision for changes outside the explicitly approved scope. Treat a reviewer’s edit as a new proposal that must pass validation and policy evaluation again.

Specify concurrency, retries, and state changes

At execution time, require a fresh evaluation of current policy and the acting principal’s and reviewer’s required permissions. Do not use an earlier approval to preserve authority that has since been revoked.

Use this sequence as a design starting point, then verify that the chosen storage and destination APIs can enforce it:

1. Confirm the approved action version, tenant, expiry, permissions, and state preconditions.
2. Atomically claim the action and reserve its applicable cumulative budget. Require competing workers to use the same coordination mechanism.
3. Execute the stored operation using conditional writes against approved resource versions where the destination supports the required conditions.
4. Use a stable downstream idempotency key for retries where the destination API documents suitable support.
5. Record the result. Distinguish a confirmed success or failure from an uncertain remote outcome that requires reconciliation.

Specify approval consumption, local worker coordination, and downstream duplicate handling separately. A single-use approval is a requirement to authorize one logical action—not a claim that the entire execution path delivers exactly-once effects.

For a timed-out remote request, use the destination’s documented status lookup, reconciliation, or idempotent retry procedure. Do not create a new action or idempotency key merely because the response was lost. Keep the action unresolved, and retain the relevant budget reservation, until its outcome is established or an explicit reconciliation process resolves it.

Define what happens if authority or resource state changes between the final check and the remote effect. If the design requires a precondition to hold at the moment of the write, require destination-side enforcement or an equivalent transactional mechanism. Where that requirement cannot be met, narrow the operation or use a controlled manual process; do not promise atomic enforcement based on a preliminary check alone.

Show reviewers the actual consequences

Build the review screen from validated action data. A model-written explanation may provide context, but it should not be the authoritative description of what will execute.

Show the reviewer:

• Who is acting: agent identity, delegating user, and tenant.
• What will happen: exact operation, targets, destination, and affected resource count.
• What will change: a before-and-after view or meaningful diff.
• What the limits are: aggregate spending, disclosure scope, and other applicable bounds.
• What approval covers: expiry and the exact action version or fixed batch.
• What recovery involves: rollback options verified for the operation, including their limitations—or an explicit statement that no rollback is available.

Separate untrusted source content from trusted action details. Exclude credentials and unnecessary sensitive payloads while making consequential information available to an authorized reviewer.

Offer explicit approve, reject, and revise paths. For especially consequential operations, consider requiring an independent reviewer rather than allowing the requesting principal to approve their own request.

Replace repetitive prompts with bounded delegation

For recurring work, offer a narrow delegation rather than a blanket “trust this agent” setting.

An illustrative delegation might permit at most 25 label-update operations in one named collection over the next hour, while excluding deletion, external export, and permission changes. Define whether limits count operations, distinct resources, or both. Continue validating every proposed action against those constraints.

Anything outside the delegation needs a fresh policy decision—not necessarily human approval, because some actions should be denied.

Enforce cumulative limits across the relevant delegation, tenant, and principal, including concurrent runs. Make budget reservation part of the shared coordination mechanism rather than an independent check performed by each worker.

Distinguish delegation from batch approval in the application’s data model:

• Delegation authorizes future actions within explicit constraints.
• Batch approval authorizes a fixed set of actions.

Use batch review only when the shared constraints are understandable and the screen shows both individual changes and aggregate effects.

Separate identity, API authorization, and action approval

For a stack using Ory, the documented services provide components that can be assigned distinct roles in this design:

• Reviewer authentication: Ory describes its Kratos-based identity service in Ory Network as an API-first identity and user-management system, with login, registration, recovery, and custom authentication interfaces. Use this layer to authenticate reviewers; define their approval authority separately. Ory Kratos documentation
• Delegated API access: Ory documents OAuth 2.0 and OpenID Connect in Ory Network as built on Hydra. It describes the service as a headless API that does not require a particular user-management system. Use OAuth where appropriate for delegated API access, while requiring a separate action-specific decision when application policy calls for approval. Ory Hydra documentation
• Operation and reviewer permissions: Ory documents Keto’s fine-grained permissions and permission inheritance through groups, roles, and hierarchies. Define application-specific operation and reviewer permissions, then check them at the relevant decision points. Ory Keto documentation

In this architecture, assign the approval queue, immutable action records, expiry handling, cumulative budgets, and execution enforcement to the application. Do not treat successful login, an OAuth grant, or resource-access permission as satisfying the application’s separate action-approval requirement.

Test the boundaries, not just the prompt count

Use the following as proposed acceptance criteria, not as evidence of behavior already achieved:

Test scenario	Required behavior
Arguments, aliases, or relevant resource state change after approval	Block execution outside the approved scope and obtain a new decision where required
Reviewer authority is revoked, the tenant differs, approval expires, or a required policy check cannot complete	Do not dispatch the action
Approval is replayed, callbacks are duplicated, or workers race	Enforce approval-use limits and the specified downstream duplicate-handling procedure
Spending is split across small requests or concurrent runs	Enforce the aggregate budget
Tool output contains instructions to approve or bypass checks	Treat the instructions as data, without changing authority
A remote outcome is ambiguous	Keep the action unresolved and follow the documented reconciliation or safe-retry procedure

Track approval requests per completed task alongside queue age, review latency, rejection and revision rates, expirations, unauthorized execution attempts, and unintended outcomes. Investigate unusually rapid approvals as a possible review-quality signal, not proof of inattentiveness.

Retain access-controlled, tamper-evident decision records linking policy evaluation, action version, reviewer decision, and execution result. Exclude secrets and minimize retained sensitive content.

Treat fewer prompts as one design objective, not evidence that approval fatigue has been solved. The acceptance target is more specific: every interruption should present a meaningful decision, and every dispatched action should remain within the authority, scope, and limits established for it.