The commercial risk in an AI agent is rarely the model alone. It is the authority around the model: which records it can read, which systems it can change, and whether those permissions still make sense when the agent encounters unexpected instructions. That should change the deployment decision. The question is not simply whether an agent fits inside existing access controls, but whether those controls are precise enough for autonomous work.
The pattern we keep seeing is a useful distinction being missed. Reusing an organisation’s Microsoft permissions is better than inventing a parallel access model. It means security teams can apply familiar identity, authorization and audit practices. But “existing permissions” does not mean “appropriate permissions”. An agent may inherit access that was tolerable for a person performing varied work but excessive for a narrow, repeatable task.
That difference matters because an agent can act faster, continuously and at greater scale than the employee who enabled it. Microsoft’s identity guidance recommends explicit authorization, minimum necessary rights, short-lived access and separate trust decisions for agents, plugins and tools. It also treats high-impact or irreversible actions as requiring stronger approval and monitoring.
Consider a finance operations agent asked to review supplier invoices in a Microsoft 365 environment. It may need to read a defined SharePoint site and extract purchase-order details. It does not need access to every mailbox, the ability to change permissions or the authority to send payment instructions. If the implementation grants broad application permissions because they are quicker to configure, the business has converted a narrow efficiency tool into a tenant-wide risk.
The practical consequence is larger than a security review. Narrow access changes what the agent can do without human intervention. It can classify documents and prepare a recommendation, while a person approves a payment or sends an external message. That division preserves speed in the low-risk part of the workflow and keeps accountability around the irreversible part. It can also reduce the cost of future audits because the agent’s purpose, owner and activity are easier to reconstruct.
The strongest objection is that detailed scoping creates friction. Teams may spend longer defining sites, roles, approval paths and exceptions than they would building a convincing demonstration. That objection is valid. An agent with no useful reach produces no business value. But broad access does not remove complexity; it postpones it until the system is operating at scale, when an error, compromised credential or manipulated document can affect more data and more people.
There is another complication. Permissions govern what an agent may reach, not what it will interpret as an instruction. Microsoft’s security guidance says controls determining access and actions should sit outside the model, with continuous observation, tailored authority and containment boundaries. A document that tells an agent to forward confidential material is still untrusted input, even when the agent is allowed to read that document.
Our view is therefore narrower and more demanding than “use the permissions you already have”. Preserve the enterprise identity model, but redesign access around the agent’s job. Give each agent a distinct owner and identity, separate reading from acting, constrain tools and destinations, and make consequential actions independently enforceable. Microsoft’s current guidance also recommends unique agent identities, named accountability and policy applied through the agent lifecycle.
The larger shift is organisational. Deploying an agent forces a company to state who is accountable for a piece of work, what authority that work genuinely requires and where a decision must return to a person. Better permissions are not an administrative detail around AI. They are the operating boundary that determines whether added capacity becomes useful capability or uncontrolled exposure.