Say your purchasing team uses an AI agent to compare suppliers and prepare orders. It works well. Then someone asks the obvious next question: why not let it place the order too?
That sounds like a small step. It isn't. Preparing an order and spending the company's money require different authority. Purchasing departments settled this for people long ago: signing limits, approved-supplier lists, a second signature above a threshold. The agent needs the same answers before it gets the same power.
NIST is working on the identity side of this problem. On September 29, 2026, its National Cybersecurity Center of Excellence summarized public feedback on a concept paper about identifying and authorizing software and AI agents, and named software development as its first implementation use case. It's early work, not a finished standard. But it points at the question leadership has to answer: which agent may act, and on whose authority?1
Define the commitment before granting access
Start with the permitted action. May the agent compare prices, prepare an order, send it for approval or submit it to the supplier? Set the spending limit, the approved suppliers and the conditions that require a human. "Manage purchasing" isn't a permission. It's a wish.
Then name the business owner who can grant that authority. The technology team can build the access controls. Whether the company accepts the commitments those controls allow is an operating decision, and it belongs to the business.
Try this: ask the business owner to describe the most consequential action the agent can take without another approval. If they can't, the delegation isn't finished.
Make the boundary visible
Keep an action record scaled to the consequence. A reviewer should be able to trace each action back to the agent, the task and the permission that allowed it. Decide who reviews exceptions and who can switch the agent off.
Switching it off is not the same as undoing what it did. Disabling access won't cancel an order the supplier has already accepted or recall a message already delivered. Your response plan has to cover the business consequence, not just the technical account.
Test the boundary before the next demo
Ask the team to show you two things: a permitted action, and an attempt to act outside the agreed boundary. Look at the refusal, the escalation and the record. Treat the result as evidence about the conditions you tested, not proof that every misuse is impossible.
An agent's ability to act is not its authority to act. Define the commitment first.
Related Reading
Read Beyond Approval: Where Operational Resilience and AI Governance Converge for what happens after an AI system is approved and then gets something wrong.
