/ THE SHORT ANSWER
- 01Separate retrieval, drafting and transaction permissions.
- 02Treat supplier documents as information rather than instructions.
- 03Bind approval to the exact action and current values.
- 04Test revocation, duplicate execution and changed requests.
/ dotSuper point of view
A purchasing policy becomes dependable only when the integration enforces it independently of the model's interpretation.
Reading a quote and placing an order are different jobs
The next request often sounds modest: prepare the purchase order too.
Eventually, someone asks it to send the order automatically when the price looks acceptable.
Each step grants different authority.
ACSC's cyber-defence AI guidance highlights least privilege, restricted data exposure, output validation and auditability.[
1] Our procurement application of those principles is to define actions separately.
Reading a catalogue should not confer access to supplier bank details or permission to commit spend.
Create an action inventory before selecting tools.
Include reading approved specifications, comparing offers, drafting an order, editing supplier records and releasing a transaction.
For each action, identify the business owner and the system control that can enforce the agreed boundary.
Keep supplier text outside the approval mechanism
The agent needs to analyse the information, but the attachment must not be able to redefine purchasing limits or tell the integration to ignore a required review.
Use a policy layer outside the model to check permitted actions, fields and limits.
The model can propose an action, while the integration validates it against the current rule and identity.
A prompt saying 'always follow our policy' is insufficient as the only enforcement mechanism.
The secure AI development guidance considers security across design, development, deployment and operation.[
2] Applied here, the team should examine document ingestion, tool permissions and runtime behaviour together.
Improving the model's answer quality does not automatically secure the systems it can call.
Make approval specific enough to survive a change
If those values change, the integration should determine whether a new approval is required under the purchasing policy.
Do not rely on the agent remembering the earlier conversation.
Keep approval separate from execution credentials.
A reviewer approving one order should not accidentally grant the agent indefinite purchasing power.
Where the workflow allows bounded automated execution, define that authority explicitly and enforce its limits in the system performing the action.
Handle retries deliberately.
If a connection fails after an order is created, the agent should check the transaction state before attempting another creation.
Give the operation a stable reference and preserve the outcome, so a network problem does not quietly create duplicate commitments.
An original permission matrix for procurement
It is not a legal purchasing threshold or a claim about any particular ERP.
Adapt the authority levels to the business, but keep the distinction between proposing an action and executing it.
Review the matrix with finance and procurement together.
Technical restrictions that ignore how approvals work will produce workarounds.
Commercial permissions that cannot be enforced by the integration will leave the model making decisions the organisation intended to control.
| Action | Agent role | Enforced boundary |
|---|---|---|
| Retrieve specifications | Read approved sources | Document-level access scope |
| Compare supplier offers | Prepare cited comparison | No acceptance of supplier instructions |
| Draft purchase order | Create reviewable proposal | No external commitment |
| Release approved order | Execute exact authorised payload | Current approval and duplicate check |
| Change supplier bank data | Flag request only | Separate verified master-data process |
Hypothetical scenario: the revised quotation
The proposed goods value is AUD 4,200 because ten multiplied by 420 equals 4,200, before tax, freight and other charges.
The reviewer approves that specific proposal.
A revised supplier attachment changes the unit price to AUD 460.
The new goods value is AUD 4,600, an increase of AUD 400.
The agent may prepare an updated comparison, but the execution layer rejects use of the old approval because its payload no longer matches.
The scenario tests authority rather than price judgement.
It does not matter whether the model considers the increase reasonable.
The relevant question is whether an authorised person or rule approved the changed commitment, with enough context to understand the amount and terms.
Test the cases that reveal authority failures
Use harmless controlled test data.
A system that answers ordinary questions well may still fail when a document or tool response tries to change its instructions.
Measure blocked unauthorised actions, missing evidence and manual recovery effort alongside useful completed work.
Some blocked actions will be legitimate requests that need a better route.
Improve the workflow without weakening the boundary simply to raise an automation completion percentage.
Begin with quote comparison and reviewable drafts.
Make the approval and execution contract explicit before enabling any transaction capability.
Expansion should follow demonstrated control over the current actions, including a tested stop route and a responsible person who can investigate what happened.
What this page cannot conclude
- 01The procurement design is dotSuper analysis, not an ACSC-certified architecture.
- 02Cyber-defence guidance is used for its control principles, not as a procurement regulation.
- 03No agent, ERP or supplier integration was tested.
- 04This article was researched and drafted with AI assistance. Sources and limitations are provided for scrutiny; it is not an independent professional review or a compliance certification.
Sources
- 01Opportunities for AI in cyber defenceAustralian Signals Directorate, Australian Cyber Security Centre · accessed Sep 15, 2026
- 02Guidelines for secure AI system developmentAustralian Signals Directorate, Australian Cyber Security Centre and international partners · accessed Sep 15, 2026
This article was researched and drafted with AI assistance. Sources and limitations are provided for scrutiny; it is not an independent professional review or a compliance certification.
Our editorial standard · Found an error? Send a correction with its source.
/ CITE OR SHARE THIS GUIDE
Make the evidence easy to verify.
When you reference this guide, link to its canonical URL. That gives readers one stable place for the evidence, limitations and future updates.
dotSuper Research Desk. (September 15, 2026). Give Procurement Agents Boundaries Before Giving Them Tools. dotSuper. https://dotsuper.net/feeds/applied-systems/australia-procurement-ai-agent-permission-controls