An agent that reads a catalogue, prepares a purchase request and places an order crosses three different boundaries. Treating those steps as one “procurement assistant” permission hides the decision that matters: when does a suggestion become a business action?
Separate drafts from approved actions
In an illustrative procurement workflow, the agent can find an approved item and assemble a draft request. The draft contains the item, supplier, quantity and delivery destination. A person with purchasing authority can review that proposal before any order is placed.
This arrangement gives the agent useful work without forcing a broad decision about autonomy. It also makes the approval inspectable. The approver is accepting a particular order, rather than endorsing whatever the agent decides to do for the rest of the session. The purchasing service must enforce that boundary when the order is submitted.
Review changes to an approved proposal
Suppose the supplier changes after review. Or the delivery destination is replaced by information found in an email. The new request is no longer the request the person approved. Bind authorization to the relevant proposal fields or revision, and require a new decision when a consequential field changes.
There is another awkward case: the tool times out after placing the order. Repeating the action may create a duplicate. The workflow needs a stable operation identifier and a way to discover the result before deciding whether to retry. A permission design that ignores uncertain outcomes leaves an important path ungoverned.
- Who may read the underlying records?
- Which fields may the agent propose changing?
- Who approves the final action, and how long is that approval valid?
- What result proves the action happened exactly as approved?
Check the controls your tools provide
GitHub’s September 2026 announcement adds centrally managed permissions for specified Copilot enterprise offerings and supported clients. Those controls distinguish blocked, human-approved and permitted operations across files, commands and network access. Product-level controls are useful evidence to examine; they do not replace the business authorization in a purchasing application.
For your own workflow, test a denied target, a changed proposal and an expired approval. Verify the destination after each attempt. The useful question is whether the action boundary survives a plausible mistake, including one made by an otherwise capable agent.