A company can name an owner for an AI agent and still leave that person unable to change what the agent can do. The name solves a reporting question. The operating problem begins when the owner says no.
Suppose an assistant reads supplier correspondence and prepares changes to existing orders. A person approves each proposed change before an established process submits it. Management now proposes letting the agent submit a defined class of amendments itself. That may improve the service. It also changes the company's exposure: interpreting a request and committing the company to its terms are different permissions.
The useful question is therefore narrower than whether the company has responsible AI policies. What exact action would the new grant permit, and what evidence would show that an authorized decision to withdraw it had taken effect?
The supplier example is hypothetical and supplies no company results. Management still has to decide whether the proposed operating authority is supported well enough to grant, retain or narrow it.
The permission has to reach the action
An owner can accept responsibility for the service while depending on other people to exercise important powers. Touch Stone's existing Accountability Contract Model makes the clarity conversation explicit: the expected outcome, granted authority, success criteria and timeline are stated before results are judged. That is ordinary management. A procurement director does not need to administer every identity or maintain the order system. The director does need an accepted route through which a decision about the service becomes an effective change.
Imagine the director withdraws permission to submit amendments after a disputed order change. The technical team changes a credential and confirms that the requested work is complete. A delegated tool path has not yet been checked. The business decision and the credential change are separate entries in this hypothetical record; neither entry establishes that the relevant submission capability is unavailable through the unexamined path.
There is no need to turn that gap into a claim that every delegated path fails. The evidence supports a more precise conclusion: the company has not yet demonstrated the capability loss on which the proposed operating posture depends. Management can identify the next proof and decide how the service will operate while it remains missing.
NIST's AI Risk Management Framework 1.0 addresses executive responsibility for AI risk decisions and differentiated human and AI roles. Its Core is voluntary guidance, not an ordered compliance checklist or a certification of this service. Those distinctions matter here. Naming the executive responsibility gives the inquiry a destination; the framework does not supply evidence that this company's submission control works.[1]
The director's practical dependency is on a technical owner who can implement the decision and show what the result establishes. If that route is unavailable, attaching a more senior name to the approval does not repair it. The next management decision concerns the missing power, the accepted support or the permitted scope.
Keep the business grant distinct from the credential
A valid credential can help explain who acted through a tool. The business grant concerns what that actor was permitted to commit the company to. A credential change is relevant evidence, but its significance depends on the capability the business owner intended to remove.
In the supplier example, the grant could permit amendments for one eligible order class and leave other requests in preparation-only mode. The test needs to follow that actual boundary. Demonstrating that a permitted amendment succeeds does not answer whether an amendment outside the grant would be denied. Testing the parent route does not settle a relied-on child route that was not examined.
NIST and the NCCoE's September 2026 consultation summary reports stakeholder preferences for task-sensitive authority, revocable short-lived credentials and narrowed subdelegation. It also reports disagreement about identity mechanisms. These are attributed consultation findings, not final implementation requirements. They support asking which authority the chosen mechanism represents; they do not authorize a claim that a particular token design settles the company's business boundary.[2]
This distinction can make the proposal easier to decide. The team can identify the action, the permitted request population and the approval condition it expects to enforce. It can then describe a scoped exercise whose result could contradict the proposal. That is a stronger basis for management judgment than a general assurance that the agent is authenticated.
The board's role in this hypothetical arrangement follows the company's actual mandate. Touch Stone's existing Governance Boundary Principle names the risk of oversight drifting into operational control. Directors can ask which consequential action management proposes to permit, what evidence supports the boundary and which material uncertainty changes their oversight posture. Subject to that mandate and any reserved Board decision, the proposed operating arrangement places credential selection and test execution with management and its authorized specialists. A board instruction that accidentally chooses the implementation can make later correction harder, because the operating owner may feel obliged to return for permission to narrow a service the board appeared to mandate.
What would make the owner withhold the next commitment?
At this point the proposal needs a question that can change the answer: who could demonstrate that the relevant capability had been removed before the next external commitment, and which important route would that demonstration leave unverified?
An answer such as “we have an emergency stop policy” leaves the operating question open. An answer identifying the responsible technical route, the tested configuration and the external evidence gives management something it can use. The limits belong beside the conclusion. A demonstration concerning one route supports a statement about that route; the service summary should not silently turn it into a claim about every way the company could become committed.
Withdrawing future permission also leaves a second obligation. An amendment already submitted may have changed an external order, even if its acknowledgment never reached the agent. Restricting another submission does not reconcile that earlier business state. Someone needs to accept the unresolved request, obtain the relevant external record and decide which recovery action is permitted.
That receiving service has its own requirements. A named person without access to the order evidence cannot settle the state by accepting an alert. A technically capable person without commercial authority may need a different decision owner. Management can expose those dependencies before relying on the fallback, rather than discovering them after the agent stops.
Less autonomy remains an operating choice
The strongest objection is that this approach could turn a useful service into a control project. A team may be asked for a growing file of permissions and tests while ordinary work waits. Some order changes already pass through an established process that handles the relevant authorization and produces an adequate receipt. Adding a new governance layer may contribute little.
That objection deserves a comparison, not a dismissal. If the existing process meets the same service need with workable effort and a reliable receiving route, management has a live alternative. The agent can retain useful interpretation and drafting while the established process commits the change. A broader grant earns its place through the service improvement it can support, together with the additional responsibilities it creates.
The narrower option also needs scrutiny. Moving submission back to a person does not automatically make the service adequate. The person still needs a clear approval subject, relevant evidence and enough capacity to handle the work. Otherwise the apparent reduction in technical discretion merely transfers an unresolved obligation to a crowded queue.
The comparison is useful when it keeps the business need constant. Which option can deliver an accepted amendment, or an intelligible refusal, while carrying the supervision and unresolved cases it creates? That inquiry permits a bounded grant where the evidence supports one. It also permits management to keep a simpler design without treating lower autonomy as a failure to modernize.
Leave a reason the next owner can challenge
An approval can outlive the configuration and working relationships that justified it. A provider may change the execution path. The person who accepted difficult referrals may leave. A new owner may inherit a green service summary without the qualification that made the original decision defensible.
The useful inheritance is the reason for the current scope, together with the power to reconsider it. A successor should be able to see which action remains withheld, what evidence would support changing that posture and which operating owner can make the decision. Unaffected findings can remain useful. A material change reopens the premise it actually affects, rather than requiring either a complete restart or an unchanged approval by habit.
For a board, that is a more consequential legacy than evidence that the project once passed a meeting. Management retains the ability to correct the service, and oversight retains a reason to ask whether the current boundary still deserves support.
If the next owner inherits this approval, will they also inherit the authority and evidence needed to change it?
Sources
[1] NIST, AI Risk Management Framework 1.0 Core (2023), GOVERN 2.3 and 3.2; Core introduction. The inspected page notes revision in progress. Source checked 16 October 2026. https://airc.nist.gov/airmf-resources/airmf/5-sec-core/
[2] NIST, Comments on Software and Agentic AI Identity Concept Paper (29 September 2026), https://www.nist.gov/news-events/news/2026/09/comments-software-and-agentic-ai-identity-concept-paper; NCCoE Summary of Comments on Software and Agentic AI Identity, https://pages.nist.gov/nccoe-ai-identity/summary-of-comments.html, particularly Agentic Identity, Task Scoped & Contextual Authorization, and Delegation and Accountability. These are attributed consultation findings, not final requirements. Source checked 16 October 2026.
Discuss the decision in front of your organization
If your team is deciding how much authority to give an AI agent, explore ways to work with Touch Stone Publishers. Bring a brief, nonconfidential description of the decision, the result you need and the timing. Any company-specific work is separately scoped.