Build a procurement AI approval matrix around specific actions, not a single autonomy setting. For each action, define the permitted scope, required evidence, spending or quantity limits, decision owner, and conditions that stop execution. Permission to ask a supplier for a date does not imply permission to accept that date, change the PO, or buy a replacement.
Start with the approval matrix working template (Excel). Use it jointly with procurement operations, the relevant system owner, and the people accountable for commercial, quality, and financial decisions. The examples below are proposed operating rules to adapt; they are not an assertion that a particular AI product implements every control.
Separate the work from the authority to perform it
Take a familiar delayed order and list its actions. Reading the supplier message, comparing dates, asking a clarification, requesting an alternative quote, selecting an alternative, placing an order, cancelling the old line, and updating the ERP are separate actions. They have different consequences and may need different owners.
A workflow can therefore run partly automatically. The agent might gather complete alternatives without committing the company to any of them. The buyer can then decide with the facts assembled. After approval, only the authorized follow-through proceeds.
Do not equate an employee's system permissions with the authority an agent should receive. A buyer may possess broad purchasing access because their job includes judgment across many situations. An agent assigned to chase acknowledgements needs a narrower scope.
OWASP’s excessive-agency guidance recommends limiting functionality and permissions, enforcing authorization in downstream systems, and requiring approval for high-impact actions. Translate those principles into observable procurement behavior rather than a promise that the model will remember a policy.
Choose clear action categories
For a first workflow, classify actions into three operating modes:
- Prepare: read approved sources, investigate, calculate, draft, and assemble a decision. The output does not itself commit the company.
- Execute within a defined rule: carry out a named routine action when its stated conditions hold. An example is requesting a missing confirmation from an existing supplier contact for a specific open PO.
- Request approval: pause before an action that exceeds the delegated scope or requires judgment. Show the evidence and exact proposed action to the accountable owner.
Keep a separate list of excluded actions. A missing integration, forbidden dataset, or decision reserved to another team is not an approval request waiting to become automatic. State whether the agent can assist with preparation or must leave that work entirely outside scope.
These categories are operational labels. Your actual permission model may be more detailed, and a software setting with the same name may behave differently. Verify behavior on the connected systems.
Write a rule that someone else could test
An action rule needs more than “low-risk emails are allowed.” Define the action and its boundary in fields:
Action: Request a missing PO acknowledgement
Scope: Existing supplier contacts, approved site, listed open POs
Required evidence: Current issued PO revision; no usable reply recorded
Permitted content: Ask for quantity, date, and stated differences
Not permitted: Accept a changed price, substitute, date, or cancellation
Before sending: Recheck for a newer reply or superseding PO revision
Owner: Procurement operations lead
Escalation: Named buyer if supplier cannot meet the requirement
Completion: Reply reconciled; remaining differences assigned
Notice that the rule identifies what must be checked immediately before execution. A reminder can become wrong after it is drafted. A supplier reply, a PO amendment, or a buyer intervention can remove its purpose.
Include the allowed supplier identities, buying entity, destination system, fields that may change, rule version, and expiry or review date. Avoid a permission that quietly expands when someone adds a new supplier or connects another mailbox.
Distinguish a record update from accepting new terms
An ERP update can be routine or commercially consequential. Copying a verified supplier reference to a designated field is different from changing the ordered quantity or accepting a new unit price.
Describe updates by field and meaning. If a supplier proposes a later date, preserve the requested date and record the proposal in the appropriate place for your process. Do not let a generic “keep dates current” rule turn a proposal into an approved commitment.
Require a known source, a matching order and line, and a current record version. If the field changed after the investigation, re-evaluate the update instead of overwriting someone else's work. Ask the vendor to demonstrate what happens when a write fails, is retried, or partly succeeds.
Use the PO change guide to define the full follow-through. An internal approval and supplier acceptance are distinct milestones, even when the same system stores them.
Make approval requests specific enough to decide
A useful request presents the current situation, feasible options, the exact proposed commitment, incremental cost, deadline, and unresolved assumptions. Link the evidence that establishes supplier eligibility, material specification, quantity, and arrival feasibility.
The approver should be able to tell what approving changes. “Resolve this order” is too broad. “After the original supplier accepts cancellation of its 300-unit line, place 300 units with approved Supplier B at $12.40 each for receipt on 18 October, provided that offer remains valid” identifies two linked actions and their order. If securing the replacement requires ordering before cancellation is accepted, return to the buyer for explicit approval of the temporary double commitment, its total exposure, and what happens if cancellation is refused.
Do not hide a second commitment in follow-through. If cancellation fees are unknown, the buyer cannot assess the total cost. Obtain that information or explicitly return for a decision before accepting the fee.
An approval should apply to the displayed supplier, items, quantities, prices, dates, and rule version. If those facts change materially, the old approval should not authorize the new proposal.
Worked example: a freight approval that stops at its boundary
In this illustrative scenario, a supplier has 240 approved components ready for collection. The existing delivery service would make them usable after the production requirement. Logistics verifies that express transport can make them usable on time for an additional $360.
The team's example rule permits the agent to request transport quotes but requires the assigned buyer to approve incremental freight. It does not permit the agent to change the material specification or supplier.
The approval packet contains the affected PO line, required usable date, supplier release confirmation, transport quote validity, receiving availability, and $360 incremental charge. The buyer approves that exact proposal. Before booking, the agent checks that the release and quote remain valid.
The carrier then quotes $425 because the original collection slot expired. The agent returns for approval rather than treating the earlier yes as permission for any reasonable increase. The new request identifies the $65 change and whether the revised service still meets the requirement.
If the buyer is unavailable, a named deputy may decide only if the delegation covers this action. Silence is not approval. If the deadline passes, the workflow records the missed option and brings planning the remaining choices. It does not disguise an unavailable service as an active recovery plan.
Define limits across the whole decision
Set limits in the unit that reflects exposure: total order value, cumulative incremental spend, quantity, a defined period, or a particular supplier agreement. A per-action cap alone can be defeated accidentally by splitting one decision into several smaller actions.
For example, three $400 expedites for the same delayed order represent $1,200 of additional cost. If the policy intends an order-level cap, show the accumulated amount before approving another shipment. Account for already approved but not yet invoiced charges as well as posted costs.
Specify currency and conversion treatment for a limit. An amount expressed in dollars is not directly comparable to a supplier quote in euros. Finance should define the applicable evaluation basis; the agent should not invent a rate or silently change the contractual currency.
Limits can also concern contact frequency and document scope. Repeatedly chasing a supplier after they have provided a clear next update time may damage the working relationship without progressing the order.
Give blocked work an owner and a next step
A stopped action must remain visible. Record what cannot proceed, why, who can resolve it, and the next review time. Separate waiting for supplier evidence from waiting for an internal decision and from a technical failure.
Define absence cover through the buyer handover process. A backup owner must receive the same decision packet and know what the first owner already approved. Reassignment should not trigger duplicate supplier messages or reset the decision history.
Agree how an operator pauses the workflow, revokes permission, and identifies actions already in progress. Reversal is not always possible: an email cannot be unsent reliably and a supplier may already have acted on an order. Recovery requires an explicit follow-up process, not just a software undo label.
Test the boundaries before widening access
Build test cases around the edges: an unknown contact, changed PO revision, expired quote, ambiguous quantity unit, out-of-scope site, missing approval, duplicate retry, and a supplier attachment asking the agent to ignore purchasing rules.
Supplier documents provide evidence about an order. They do not grant authority to change company policies. Test that a supplier's request for broader access, different payment details, or an unauthorized commitment is routed through the appropriate owner rather than treated as an instruction the agent may follow.
Record expected and observed behavior for each scenario. Require evidence of the action actually attempted, the permission checked, and any system change. A reassuring explanation after an unauthorized action is a failed boundary test.
Review the matrix against real work
Track unauthorized actions separately from ordinary processing errors. Also measure unnecessary approval requests, unresolved work age, duplicate actions, and how often a human reverses the agent's proposal. Use a defined reviewed population for every rate.
Review rules when suppliers, integrations, operating procedures, or business scope change. Expand one action class at a time when evidence supports it. Keep the old rule version and the reason for the change so the next reviewer can reconstruct which authority applied.
Mandel's operating approach is to perform sourcing and ordering work inside the authority granted and bring people the decisions that require them. Bring this matrix to an evaluation on your own orders and ask to see each important boundary exercised, including the point where the system must stop.
