When Should an AI Action Approval Expire?

Bind AI action approval to significant inputs, a revision and current authority. Use a worked purchase-order example to define expiry and dispatch checks.

Expire approval when its authorized meaning changes

An AI action approval should expire when significant inputs change, the agreed time window closes, required evidence becomes stale, or the approver loses the necessary authority. Recheck those conditions at dispatch. A click recorded earlier in a conversation is insufficient if the application later executes a different action.

There is no universal five-minute or one-day expiry that fits every workflow. A low-consequence internal draft and a purchase-order amendment have different costs of delay and different consequences of stale authority. Choose a time window alongside revision checks and current permissions, then test what happens when work waits in a queue.

The design below is a proposed application policy for engineering teams. Its purchase-order example is illustrative and does not represent an Ampity customer outcome. It explains how to bind a human approval to an action; it does not decide your company's purchasing limits, legal authority or sector-specific obligations.

Follow the purchase order through a delayed approval

Suppose an assistant proposes changing an order from 100 units to 120 units. The buyer approves the supplier, quantity, unit price and delivery date shown on screen. The application queues the amendment because the destination is temporarily unavailable. Before dispatch, another employee changes the delivery location and the supplier updates the price.

The assistant may still have a message saying “Approved.” That message does not establish approval for the new destination or price. The application needs an immutable proposed action revision and an approval tied to that revision. A worker should refuse to execute a changed proposal under the earlier grant.

Define significant fields with the business owner. Quantity, price, recipient, destination and external communication content are often consequential, but the set depends on the tool. Do not infer it only from which fields appear in the model's arguments. A connector default, such as currency or account, can change the meaning even if the model never mentions it.

Show those effective values before approval. If a connector resolves “the usual supplier” to a specific account, the reader should see that resolved target. Prevent later default changes from silently altering the approved action. Keep presentation formatting separate from the canonical values the executor validates.

Store the grant outside the conversation

A proposed approval record includes the action identifier, immutable revision, tenant, acting principal, approver, significant input digest, permitted effect, expiry and policy reference. Store the underlying significant values securely so the digest remains explainable. A hash detects a mismatch; it does not prove that the approver saw a correct summary.

Protect the record from client tampering and enforce it in the execution service. OWASP's Transaction Authorization guidance recommends server-side enforcement, confirmation of significant transaction data, constrained validity and a final authorization control before execution. Applying those principles to an agent's action record is the design recommendation here.

Separate approval from general login. An authenticated buyer may be allowed to inspect many orders while approving only one defined amendment. Session access should not transform a narrow approval into permission for every action the agent proposes during the session.

Record the policy under which the grant was issued, but decide how a policy change affects pending grants. A current prohibition may need to block an old grant immediately. Do not freeze permissive policy indefinitely merely because it was valid at proposal time. Document which changes invalidate pending work and how readers receive the replacement approval request.

| Approval condition | Dispatch question | If the condition fails | | --- | --- | --- | | Action revision | Are the effective significant values unchanged? | Hold and present the revised action | | Time window | Is execution still within the permitted period? | Request renewed approval | | Approver authority | Does this person still have the required scope? | Route to a currently authorized approver | | Acting identity | Is the executor still permitted to perform this effect? | Deny dispatch and investigate policy | | Evidence freshness | Is the price, availability or decision evidence still usable? | Refresh evidence and reassess the proposal | | Prior execution | Has this authorized effect already been dispatched or completed? | Recover the same operation instead of creating a new one |

Choose a time window from the workflow's exposure

Ask how quickly the facts supporting the action can change. A proposed inventory transfer depends on current availability; a reviewed document publication depends on a specific revision. A shorter lifetime can reduce stale execution, but it can also create repeated approval requests if the system spends most of its time waiting for a worker.

Measure approval-to-dispatch delay before choosing the window. Separate normal queue delay from exceptional outages. If most actions expire before dispatch, increasing the lifetime may hide a capacity problem. Holding admission or improving scheduling may be a better response than allowing old decisions to execute long after the reader expects them.

Where exact timing is consequential, define the authoritative clock, boundary comparison and allowed skew. An illustrative contract could require the server's dispatch decision to occur before the stored expiry. That still leaves a remote-processing interval. If the business requires the destination to commit before expiry, obtain a provider-supported mechanism or explicitly reject actions whose deadline cannot be enforced.

Avoid displaying a countdown that implies a stronger guarantee than the integration supplies. Tell the reader whether approval permits submission within a window or guarantees completion by a deadline. These are different contracts, and an agent cannot supply the stronger one through wording alone.

Recheck permissions without reopening the approved action

The approval check and current access check answer different questions. The first asks whether the defined action received the necessary consent. The second asks whether the identities involved are presently permitted to act on the target. Both can fail independently.

OWASP's Authorization guidance recommends least privilege, default denial and checking permissions on each request. For a queued agent workflow, the application should make that check at execution rather than relying on access observed when the proposal was created. This is especially relevant after a role change or account suspension.

Prevent a timing gap from turning validation into a promise the executor cannot honor. Within your own database, conditional updates and revision checks can bind a state transition to the expected version. Across an independent provider, inspect whether conditional writes or equivalent preconditions exist. If they do not, document the residual race and choose the permitted consequences with the business owner.

Do not grant the model permission to bypass a failed check by choosing another identity, splitting an amount or altering the target. A legitimate revised proposal follows the approval path again. The executor should return a bounded reason and permitted next step, not a generic error that invites repeated improvisation.

Preserve approval meaning during recovery

A timeout after dispatch creates uncertainty about the original operation. It does not automatically create a new action requiring a new identifier. Keep the approved revision and stable operation reference while investigating the destination's result. Status investigation may have a different permission scope from another business write.

If the original approval expires while that investigation runs, decide which recovery steps remain allowed. Reading a receipt for work already dispatched may be necessary. Reissuing a write after expiry needs a documented contract, current permission and the provider's verified retry semantics. Never use the word “retry” to bypass a policy that prohibits further effects.

If the destination confirms the amendment completed, record that fact even if the local approval has since expired. Expiry is not retroactive erasure. A correction or cancellation then needs its own applicable authority, target and evidence. This preserves a truthful history for operations staff and avoids a misleading cancelled label on a committed order.

Test stale approvals as ordinary release cases

Create fixtures for a changed amount, changed recipient, changed connector default, expired approval, revoked approver role and a policy change during queue delay. Assert that no prohibited write reaches the controlled destination. Inspect the effective dispatched values rather than checking only the dialog text.

Also test legitimate unchanged work. A valid approval should not repeatedly prompt the reader because harmless rendering or whitespace changed. Decide how values are normalized, then test that normalization without weakening the significant-field boundary. An equivalent display is not necessarily an equivalent account identifier or monetary value.

Run two workers against one grant and restart a worker after dispatch. The acceptance evidence should show the business effect count, approved revision and any unknown outcome. Audit whether a delayed replay can use a consumed grant to create another effect. These tests connect authorization with recovery rather than treating them as unrelated controls.

Limitations and the next useful step

Human approval can still authorize a bad recommendation. Revision binding does not validate supplier quality, detect every misleading summary or make an external provider transactional with your database. An expiry policy also cannot replace current access control, accurate evidence or clear responsibility for unresolved actions.

Start by selecting one consequential write and listing its significant fields, current permissions, evidence lifetime, queue delay and remote preconditions. Have the workflow owner approve that contract. Then implement the invalidation fixtures and compare the proposed values with the actual destination write before broadening the agent's authority.

For related failure handling, read AI tool timeouts and duplicate actions and AI Agent Architecture in Production. Ampity's agentic workflow engineering is the related service for designing and testing these execution controls around a real business action.