Read is not write. Suggest is not execute. Exception handling is not normal flow.
That sounds obvious until an AI agent is connected to tools.
Before that moment, the risk is mostly about information: what the model can see, what it can infer, what it might reveal, and what it might generate. Those risks are already real.
But the security model changes when the agent can act.
It can update a record. It can move a ticket. It can call an API. It can send a message. It can approve something. It can trigger another workflow. It can touch a system of record with credentials that were designed for a human, a service account, or an integration nobody expected to become conversational.
That is the point where “AI governance” stops being a policy sentence and becomes an access-control problem.
The mistake I see too often is treating an agent like a smart interface sitting on top of existing permissions.
A user has access to a tool, so the agent gets access to the tool.
A connector can call an API, so the agent can call the API.
A workflow exists, so the agent can trigger the workflow.
This is convenient.
It is also how you quietly turn a pilot into a privileged automation layer.
In normal operations, we do not give every field user the same scanner profile. We do not give every depot the same customer access. We do not give every technician the same approval rights. Access depends on route, customer, role, device, shift, location, exception type, and sometimes the exact state of the work.
Agents need the same discipline.
Not because they are human.
Because they can act inside systems that were built around human accountability.
The practical distinction starts with verbs.
Read.
Suggest.
Draft.
Validate.
Submit.
Approve.
Execute.
Escalate.
Those verbs are not equivalent. They should not carry the same permissions, the same audit trail, or the same approval path.
An agent that reads internal documentation is one risk class.
An agent that drafts a customer response is another.
An agent that updates a price, changes an order, closes an incident, or writes into an ERP is another again.
The same model can be involved in all three. The model is not the boundary. The allowed action is.
This is where workflow state matters.
A normal case and an exception should not have the same path.
A low-risk suggestion and a production write should not use the same authority.
A draft generated from approved context and a change applied to a system of record should not be treated as the same event.
When a field workflow is normal, the agent may be allowed to classify, summarize, or prepare the next step. When the workflow enters an exception state, it may need to stop, ask for approval, limit what it can see, or route the case to a human.
That is not a theoretical control.
That is how real operations already work.
The difference is that AI agents make the boundary easier to blur because the interface looks simple. A sentence hides the tool call. A prompt hides the credential. A connector hides the API. The demo hides the authorization model.
The right question is not only, “Can the agent do this?”
The better question is, “Under what workflow state is the agent allowed to do this?”
Allowed for which customer?
Using which data?
Through which tool?
With which identity?
Logged where?
Reviewed by whom?
Blocked under which exception?
That is the kind of authorization model enterprise AI will need.
Not one giant permission set because the agent is useful.
Not broad admin keys because the integration was easier.
Not hidden inherited rights because the user already had access.
A permission model tied to task, tool, data, action, and workflow state.
This is also where auditability becomes practical.
An audit trail that only says “the AI did it” is not useful.
The trail needs to show which agent identity acted, what it read, what it changed, what tool was called, which source was used, which rule allowed the action, and whether a human approved the step.
Otherwise we are not governing agents.
We are trusting a black box wrapped around our existing systems.
And yes, the model may be impressive. The workflow may be useful. The productivity gain may be real.
But once the agent can act, least privilege has to follow the work.
Not the demo.
Not the connector.
The work.
For me, the simplest design rule is this:
Treat every agent action as an operational event.
If the action would require a human role, a system permission, a business rule, or an audit trail, the agent should not bypass that discipline just because it speaks natural language.
Read is not write.
Suggest is not execute.
Exception handling is not normal flow.
Still the basic access-control lesson.
Now applied to systems that can reason, call tools, and move faster than the people reviewing them.