How to govern autonomous procurement: six controls to require before you authorise execution

Start from accountability, not capability

The question that stalls most autonomous procurement proposals is not whether the software can perform the task. It is who is accountable when it does.

Reframing the assessment around accountability produces a much shorter and more useful list of requirements.

The six controls

These six turn autonomous execution into something a security and audit function can reasonably approve.

• Role-based access, scoped by entity, category and data, applying to agents as well as users.
• Agent permissioning: defined permitted actions, value limits and escalation paths for each agent.
• Executable policy and thresholds, so routine work proceeds and material exceptions stop.
• Human approval checkpoints that an agent cannot bypass.
• Explainability and override, with the reason for any override recorded.
• A complete audit trail linking observation, rule, action, approval and exception.

Apply segregation of duties to software

If your policy separates preparation from approval for people, apply the same separation to agents. An agent that prepares an award package should not hold the authority to approve it.

This is easy to configure and easy to overlook, and it is among the first questions an internal audit function asks.

Ask for demonstrations rather than descriptions

Governance descriptions are cheap to produce. Six specific demonstrations reveal more than a hundred-question security questionnaire.

Show a permission set in configuration. Show an action blocked at a threshold with the rule that blocked it. Show an escalation reaching a named approver. Show an authorised override and its record. Retrieve the full action history for one transaction. Show how a policy change is itself approved and recorded.

Sequence adoption around evidence

A practical route is to give agents coordination authority first — chasing, routing, preparing — then accumulate real action history, review it with security and audit, and widen execution rights on the basis of what the record shows.

Organisations that define authority carefully tend to expand automation faster, because each step becomes an evidenced decision rather than a fresh act of faith.

Why governance is the buying decision

In most software categories, capability decides the purchase and governance is a compliance formality afterwards. In autonomous procurement the order reverses. A platform that cannot demonstrate a boundary does not reach a contract, however capable it is, because a security function cannot authorise what it cannot describe.

This means the governance model is not a section of the evaluation. It is the evaluation, and it is worth involving security and internal audit far earlier than a procurement technology purchase normally would.

The six controls, and what each prevents

Each control exists because of a specific failure it prevents. Stated that way they are easier to test.

• Role-based access — prevents an actor operating outside the entity, plant or category they are responsible for.
• Agent permissioning — prevents an agent performing an action nobody authorised, by enumerating what it may do rather than describing what it can.
• Executable thresholds — prevents value-based judgement being made by software, by returning it to a person above a configured level.
• Non-bypassable checkpoints — prevents time pressure removing a control, because no configuration can route around it.
• Explainability with override — prevents an unexplained action standing, by allowing a person to reverse it and recording who did so and why.
• Complete audit trail — prevents an action being unreconstructable later, which is the failure that surfaces during audit rather than during operation.

What a good review actually looks like

A governance review that consists of a questionnaire and a policy document tells you very little. A useful one is performed live, in a session, on the vendor's system.

Ask them to attempt an action outside an agent's authority and observe the refusal. Ask them to block an action at a threshold and show what the approver then receives. Perform an override and retrieve it afterwards with its author and reason. Request the complete action history for a single transaction in the form an auditor would receive it. Each of those takes minutes and is difficult to fake.

Widening authority responsibly

The instinct to grant broad authority at the outset should be resisted, not because agents are unreliable but because authority granted before evidence is difficult to withdraw once teams depend on it.

A defensible sequence gives agents coordination authority first, accumulates real action history, reviews that history with security and audit, and widens execution rights on the basis of what the record shows. The record, rather than the business case, becomes the argument.