At a glance
- The risk: Connecting an AI agent to a system can quietly turn technical access into authority to act for the business.
- The governance implication: Define which actions are permitted, who owns the workflow, and where human approval or intervention is required.
- The leadership takeaway: Decide what the agent may read, recommend, change, and communicate before it touches a live workflow.
An AI agent that drafts a response and an AI agent that sends it are doing different jobs. The second has authority to act on the business’s behalf. That distinction should shape the adoption decision before anyone connects the agent to a live workflow.
The useful question is not only whether the tool works. It is whether the business has decided what the tool is allowed to do—and who can change that authorization.
Access Does Not Explain Authority
A system connection answers a technical question: can this agent reach a mailbox, document store, or application? It does not, by itself, explain which business actions leadership intended to authorize.
Permission to read a folder is not the same as permission to send a message, update a client record, or make a commitment. Those actions can carry different consequences even when they happen through the same system connection.
Access describes what a system can reach. Authority describes what the business has decided it may do.
What the Identity Work Signals
On 29 September 2026, NIST’s National Cybersecurity Center of Excellence announced a summary of feedback on software and AI agent identity and authorization. Its first implementation use case will examine agent identity, authentication, and authorization in software development. This is developing technical work, not a new insurance compliance requirement. Read the NCCoE announcement.
NIST’s August discussion of agent identity highlights risks from shared credentials, long-lived credentials, and excessive access. Its focus is applying identity and authorization practices to agents. Read NIST’s discussion.
Those technical controls matter, but leadership still needs to set the business boundary: permitted actions, an accountable owner, and the point where human approval is required. Technical controls should enforce those choices.
A Small Insurance Firm’s Decision
Consider an illustrative insurance intermediary using an agent to summarize client documents and prepare follow-up emails. This is a hypothetical workflow, not a reported client engagement.
A sensible pilot might let the agent read a limited set of approved documents and create an internal draft. Sending that draft to a client would remain a separate, human-approved action. Updating a client record or communicating a coverage interpretation would need its own assessment rather than inheriting permission from the drafting task.
This boundary helps prevent a narrow productivity experiment from quietly becoming a much wider delegation. It also lets useful adoption proceed without treating every action as equally consequential.
Three Decisions to Make Before Launch
1. Define the authority boundary
Write down what the agent may read, recommend, change, and communicate. Include prohibited actions. Test whether the tool’s permissions and workflow actually reflect that boundary.
2. Name the accountable business owner
Identify who approves the use, who reviews exceptions, and who can pause it. A vendor’s responsibility for its product does not replace the firm’s ownership of the workflow.
3. Make intervention practical
Establish where human review happens, what information the reviewer receives, and how access can be withdrawn. An approval step has little value if the reviewer cannot understand the proposed action or has no realistic opportunity to stop it.
Judge the Pilot by More Than Productivity
Time saved is worth measuring. So are unexpected actions, incorrect outputs, approval overrides, and the effort required to supervise the workflow. A pilot should show whether its authority boundary holds under realistic conditions.
Start with a limited use case and explicit conditions for expansion. Additional permissions should follow a fresh business decision supported by evidence, rather than becoming the default reward for a successful demonstration.
Questions for the Leadership Team
- Which actions may the agent take on its own, and which require a person’s approval?
- Who owns the workflow and can pause the agent when the boundary is crossed?
- What evidence would justify expanding the agent’s authority?
Closing Thought
Before an AI agent acts for your business, make its authority explicit. If you cannot explain what it is allowed to do—and who can change that—you have not finished the adoption decision.
Sources and Further Reading
- NCCoE: Feedback on Software and Agentic AI Identity Concept Paper.
- NIST: Why Agentic AI Needs a Strong Identity Foundation.
- The AI Governance Question Regulators Are Forcing — And Most Leaders Can’t Answer.
- AI Governance Is Failing at the Design Phase — Not the Review Phase.
Sources last checked 1 October 2026. The business example is illustrative; recommendations are editorial interpretation, not statements of a new regulatory obligation.
About Gary Cheung
Gary Cheung works in information risk management, helping leaders make clear, accountable decisions about technology risk and AI governance.
If you are considering an AI-enabled workflow and need an independent information risk perspective, get in touch.
