A procurement agent has compared quotations and prepared an order. The supplier is already approved. The price looks reasonable. Then someone asks whether the agent can actually commit the company to the purchase.
If that question reaches the steering committee during a live transaction, the team has left an operating decision unfinished.
AI agent governance defines which actions an agent may take, who approves exceptions and how the organisation checks its work. It puts an enterprise AI governance framework into the decisions managers face during a live workflow. Which actions are allowed? Who can approve an exception? What stops the next transaction if something goes wrong?
For an enterprise rolling the same workflow across business units, those answers need to survive different approval limits, systems and working hours. A single permission copied across the group can quietly expand the financial exposure.
Set AI agent permissions for procurement
Consider an illustrative procurement workflow. An agent reads approved supplier records, compares quotations and drafts purchase orders under an existing purchasing policy. This is a worked example, not a client case.
The procurement owner wants shorter handling times. Finance needs existing approval limits to hold. Security needs to know which identity can access supplier records. The purchasing team needs someone to answer when an order gets stuck.
Write the boundaries together before handing the requirements to engineering.
| Action | Boundary for this example | Evidence to retain |
|---|---|---|
| Read supplier information | Approved records relevant to the request | Source reference and access-policy version |
| Recommend a supplier | Rank eligible suppliers and explain the choice | Current eligibility and quotation references |
| Draft an order | Prepare a draft with no financial commitment | Request, budget code and supporting quotation |
| Release an order | Require the existing authorised human approval | Approver identity and recorded decision |
| Change bank details | Exclude this from the agent's permissions | Reference to the separate controlled supplier-change process |
Illustrative procurement boundaries. Adapt them to the company's purchasing policy and operating risks.
Attach an owner and review date to this record. Specify the business units and systems it covers. Contract terms, fraud exposure and applicable obligations may require tighter controls.
The record should be usable by someone who missed the project launch. If “approved supplier” means something different in two subsidiaries, settle that difference before sharing the agent between them.
Use established guidance for the review
The NIST AI Risk Management Framework provides a voluntary foundation for managing AI risks. Its Playbook groups suggested actions under Govern, Map, Measure and Manage. NIST describes those suggestions as something organisations can select for their circumstances, rather than a checklist to complete in full. Both pages currently note that AI RMF 1.0 is being revised.
Use the relevant guidance to challenge the proposed workflow. Mapping controls to it does not amount to certification or settle the company's legal obligations.
For this procurement example, ask how the system handles stale eligibility records, conflicting quotations and instructions embedded in supplier documents. A quotation is input to assess. Its contents must not acquire authority to change tool permissions or override purchasing rules.
Our guide to moving enterprise AI into production covers the wider implementation sequence. This decision record supplies the boundaries the implementation team needs.
Give the agent an identity you can withdraw
An agent using an employee's credentials makes automated activity harder to distinguish from that person's actions. In its August 2026 article on agent identity, NIST highlights shared credentials, long-lived credentials and overly broad access as recurring security problems.
For our example, I would require a traceable service identity with access restricted to the approved workflow. Record who granted that access and when it needs review. Enforce the boundary in the connected systems, where an unauthorised action can actually be refused.
Before release, run a withdrawal test. Pause the agent and check whether new tool actions are denied. Inspect queued work and credentials that may remain valid. Define what happens to transactions already accepted by downstream systems, because withdrawing access cannot undo a completed order.
Keep the audit record proportionate. Retain the action, relevant evidence references, policy version and approval. Set access and retention rules for those records. Copying every supplier document into another log creates another store of sensitive information to manage.
Assign responsibility for human review
“Human review required” is easy to put in a design. It becomes a staffing commitment when the first exception arrives.
Give each exception a named receiving role, the evidence needed for a decision and a response target based on the workflow. Identify an authorised deputy. When neither is available, hold the action or use an approved manual route. Silence must not turn into approval.
An unavailable reviewer leaves the action on hold. A deputy must have the same relevant authority and review the evidence before deciding.
A supplier-eligibility check and a budget approval may belong to different people. Show each reviewer the evidence for their own decision. A universal approval button hides that distinction.
Then measure how the route behaves. Track the proportion of cases sent for review, time spent waiting, reviewer effort and repeated reasons for referral. Separate routine escalations from failures that should stop the workflow.
If nearly every order needs senior review, revisit the process design and feed the observed workload into the enterprise AI ROI calculation. Removing the approval just to make the forecast work would change the risk decision as well as the economics.
Reopen approval when the workflow changes
A release decision covers a defined configuration and operating scope. Adding a business unit may introduce different transaction values or supplier rules. A model update may change behaviour even if the interface stays the same.
Agree which changes require review. In this example, that includes a new write permission, a new data classification, expansion into another supplier region or a sustained increase in exceptions. Assign the evidence required and the person who can authorise each change.
The operational team also needs a tested suspension route. Specify who can stop the workflow, how affected work is identified and who can permit resumption. The resumption record should explain the failure, the correction and the evidence supporting the decision.
Your AI operating model determines whether those owners can change staffing, service levels and spending. Check those powers against the responsibility chart. Naming someone accountable does not give them a budget.
Amalgama's enterprise AI consulting connects process design with implementation and operational ownership. Bring one live workflow, its approval rules and a difficult exception to an AI workflow assessment. We can work through what the agent may do and who needs to own the decisions around it.