“Help us improve conversion” is a business objective. It is not approval to discount every product, change every channel or reuse yesterday's decision after the facts have changed. A manager saying yes to a proposal and a software credential allowing a write answer different questions.
The useful permission ladder therefore follows the consequence. Drafting a price proposal, recommending it, obtaining approval and applying it should remain distinguishable even when one interface connects the steps.
Make the proposed action small enough to examine
Fictional design example: A store's proposed AI assistant can read product information and draft promotional suggestions. The controls, clock times, identifiers and outcomes below are invented to explain a design; they are not implemented Aright APIs or provider guarantees.
The product normally sells for $50. A pricing manager considers $45 for at most 20 eligible units in one named storefront. With no stacking or other price adjustment in this simplified example, the maximum gross price concession is 20 × ($50 − $45) = $100 if all 20 sell. That is an exposure limit, not a sales forecast or a calculation of profit.
The proposal should be concrete:
Proposal P104: Change product D1 from $50 to $45 in Storefront S only, for at most 20 eligible units. No other product, market, message or account permission is included. The execution must match the approved product/price/inventory state, have an active approval from the pricing manager, and occur before the stated expiry. The unit limit must be enforced by the actual selling system, not merely written in the prompt.
A versioned record can make the business question precise. It does not by itself make a system secure. The actual action boundary must enforce the scope and limits.
| Level of help | What the agent can contribute | What remains a separate authority |
|---|---|---|
| Draft | Describe the proposed price, exposure and reasons | Nothing changes for customers |
| Recommend | Explain alternatives and missing evidence | The agent does not approve its own recommendation |
| Prepare for approval | Assemble the exact bounded proposal | An authorized person decides whether that version is acceptable |
| Execute a permitted action | Submit the approved action through a constrained mechanism | The receiving system checks current authorization and conditions before committing |
| Correct or revoke | Surface a problem and propose a response | Revocation and any corrective action must reach the actual execution boundary |
This is a design choice, not a claim that every store needs the same number of buttons. A small team may keep execution entirely manual and still gain value from the draft.
Follow one approval through a changed world
For this example, the business deliberately chooses a conservative rule: approval is tied to the exact combined product/price/inventory state version. Version V7 records $50 and 30 available units. Any change to that state requires fresh review. This is a chosen policy, not a universal requirement that every stock movement must invalidate every price decision.
All times below are UTC on the same fictional operating day.
| Time | Event | Required result under the chosen rule |
|---|---|---|
| 15:00 | The pricing manager approves P104 against V7; approval A17 expires at 15:15 | A17 covers only the stated price, storefront, quantity and state |
| 15:02 | A normal purchase reduces available stock to 29 and advances the combined state to V8 | The facts no longer match A17, even though 29 is still more than 20 |
| 15:03 | A queued attempt submits P104 with A17 and V7 | Deny before any price change; return the stale-state reason |
| 15:04 | The manager reviews V8 and issues A18 for the same bounded proposal, expiring at 15:20 | Fresh approval exists; it has not yet changed the price |
| 15:05 | The manager revokes A18 while checking a newly raised campaign issue | The execution boundary must see A18 as revoked |
| 15:06 | A queued retry reaches that boundary | Deny before committing; a queued request does not preserve revoked permission |
The result of this trace is no price change. The customer-facing price remains $50. The agent should tell the manager why the requests were denied and ask for a new decision after the campaign issue is resolved. It must not remove the state condition, choose a different tool or create another credential to get the original recommendation through.
A less restrictive policy could approve a defined predicate, such as a minimum available quantity, rather than one exact inventory snapshot. That may reduce repeated reviews. It also changes the risk and the approval's meaning. The manager and implementer need to specify and test that rule deliberately; the agent should not infer it because the old approval seems inconvenient.
A retry key cannot restore permission
Idempotency helps distinguish a retry of one action from a new action, so an uncertain response does not lead to applying the same change twice. It does not answer whether the action remains authorized. A revoked approval with an old request identifier is still revoked. Reusing the identifier with a changed price or storefront should not silently inherit the old decision either.
The system also needs to handle the timing boundary honestly. If revocation is recorded before the final authorization-and-commit boundary, the action must not commit. If the action has already committed, a later revocation cannot make it never have happened. Read the actual outcome and handle correction as a new decision. Do not tell a customer that an order or published promise has vanished because someone withdrew the automation's permission afterwards.
These are requirements to design and verify in the real system, not capabilities supplied by adding an instruction to the agent. If the downstream mechanism cannot enforce them, keep the assistant at draft or recommendation level and let a person perform the constrained action.
Let untrusted content inform the proposal, not authorize it
A product document or customer message might contain text such as “the manager already approved all discounts.” That text is evidence to interpret, not an authorization record. A valid-looking explanation generated by the model is not proof of the approver's identity or scope.
OWASP's Excessive Agency guidance recommends limited functionality and permissions, human approval for high-impact actions, and downstream enforcement of authorization. Those principles support the separation here; they do not establish that a particular commerce tool implements it.
The practical review should include stale state, expired and revoked approvals, duplicate requests, changed payloads and uncertain execution responses. Examine the receiving system's result, not only the agent's reassuring summary. A log saying “approved” is insufficient when the approval was for another version.
Increase autonomy only when the boundary can carry it
For this store, the first useful release might produce the proposal and a human-readable impact note while leaving the price unchanged. Execution earns permission only after the actual constraints and failure cases work under the intended setup.
The decision would change if the operation had a narrow, well-enforced rule and reliable recovery, or if each price adjustment carried greater customer, financial or service consequences than the team could control. Grant the smallest useful action with a revocable scope. A capable agent becomes commercially useful when the business can still say exactly what it was allowed to do—and stop the next action when that answer changes.