Enterprise AI becomes materially different when it moves from answering to acting.
A system that drafts a note can be reviewed after the fact. A system that updates a record, triggers a workflow, sends a message, changes a priority, queries a sensitive source or calls another tool is no longer only producing an output. It is entering the operating system.
At that point, permission design becomes architecture.
Before giving an AI system a tool, the organisation has to decide what the system may observe, what it may recommend, what it may execute, where it must ask permission and when it must stop. These are not only governance questions. They are product, workflow and accountability questions.
The common mistake is to treat permissions as an access-control layer added near the end. But in agentic workflows, permissions shape the system itself. They define the boundary between assistance and action, between automation and judgement, between speed and control.
A useful test is simple: for every AI action, can we say who gave authority, what evidence the action relied on, what limit applies, what exception must escalate and who remains accountable after execution?
If those answers are unclear, the system may still be impressive in demo mode. But it is not yet ready for enterprise use.
The more an AI system can do, the more carefully the organisation must design what it is not allowed to do.