If an agent reads company data, sends email, changes records or initiates approvals, give it a separate identity, narrow permissions and access that expires. Existing identity controls, API permissions and approval rules can enforce that design today.
On 19 October 2026, Microsoft announced Dynamic Permissions, Dynamic Agent Risk and Dynamic Conditional Access. Dynamic Permissions would bind agent authority to a task and a defined period. Do not move to Microsoft 365 E7 solely because of this announcement. First obtain written product status and EU tenant availability.
Why should an agent have different permissions from its user?
An employee usually has access to more tasks and systems than an agent needs. Passing all of that standing authority to an agent increases the potential impact of a mistaken tool call or manipulated input.
In its 19 October security announcement, Microsoft says agents can make mistakes, be manipulated or compromised, and behave differently as their context changes. Its proposed model gives every agent an identity separate from the person using or sponsoring it.
The vendor explains the problem through an expense-approval agent. It may need to read submitted claims, check policy and handle routine reimbursements. It does not need every permission held by its sponsor. A separate identity also allows audit records to distinguish an employee’s own action from work performed by an agent on that person’s behalf.
For agents that browse the internet or call external tools, the guide to restricting an internet-connected agent provides additional test cases.
How would Dynamic Permissions change access control?
Under Microsoft’s description, organization-wide policy sets the outer boundary: an agent cannot receive authority that its user does not have. Within that boundary, access can be limited to the task and a defined period. Permissions can contract as the task changes and disappear when it ends. Higher-impact actions can require verified human approval.
The announced Dynamic Agent Risk would combine signals from identity, data, endpoints, cloud, network, runtime and agent activity. Dynamic Conditional Access could respond by reducing permissions, preserving reads while blocking writes, narrowing reachable resources or stopping execution.
The table turns those product principles into pilot and procurement requirements.
| Control point | Required configuration | Pilot test |
|---|---|---|
| Identity | Give the agent its own identity | Logs distinguish agent actions from user actions |
| Permission | Grant only the rights required for the approved task | The agent cannot reach unrelated mailboxes, files or business systems |
| Time limit | Expire access when the task ends | An old token cannot continue the operation |
| Write action | Require a human for consequential changes | The write fails without the required approval |
| Risk response | Allow read and write authority to be restricted separately | Suspicious input removes write access while preserving the reads required for investigation |
Source: the vendor’s description of Dynamic Permissions and Dynamic Conditional Access.
How does this apply to a finance approval workflow?
The expense example maps directly to an approval workflow running in Microsoft 365. The agent uses a separate identity to read a claim and the relevant policy. Its access excludes policy editing, supplier master data and complete finance folders belonging to other employees.
After routine checks, the agent can prepare a recommendation. A designated employee retains the decision that authorizes payment. The audit record should show the data used, the agent’s actions and the human decision.
During the pilot, give the agent a manipulated document and an input that attempts to trigger an unrelated tool call. A suitable control removes write authority, retains the evidence needed for investigation and requires a person to approve any continuation.
A workflow limited to summarising Teams and SharePoint content may need less custom integration. The guide on when Copilot is enough for Microsoft 365 automation helps identify when the process crosses that boundary.
If you are building a custom agent, define permissions and human approval points in the system design from the start. AI agent development
How much does Agent 365 cost?
Microsoft’s Agent 365 page dated 1 May 2026 listed the standalone product at USD 15 per user per month. Agent 365 was also available through Microsoft 365 E7 for commercial customers. One licence covers a person who manages or sponsors agents, or uses agents to perform work. The number of people involved therefore determines licence volume.
The same page listed agents operating behind the scenes with their own access as generally available. Agents participating in team workflows were in Public Preview. Windows 365 for Agents was available only in the United States and remained in Public Preview at that date.
Microsoft’s security blog presents the 19 October capabilities as additions to Microsoft 365 E7 and Project Perception. It does not assign each capability to a specific SKU or list its rollout date, EU availability or price. The corporate Project Perception post says the project was announced in July 2026 and describes Guardian Agents providing continuous supervision.
Require the reseller’s written quotation to state the release stage, required SKU, availability for EU tenants and which people must be covered by licences.
Current agent activity should determine purchase timing
If an agent already sends email, changes records, issues approvals or performs actions in a business system, reduce its permissions now through existing controls. Separate identities and least-privilege access are already practical design choices.
A company with no deployed agents should begin with inventory and permission policy rather than a new security licence. A buyer considering E7 solely for Dynamic Permissions or Project Perception should wait until the quotation includes the relevant product terms.
Microsoft says it is expanding local discovery by 35 agent types, bringing the total to 60, including Claude Code, OpenAI Codex and GitHub Copilot. If these tools run on developer devices, start by identifying their owners, identities and reachable resources.
Which checks should close the pilot and procurement decision?
- For every agent, record an owner, business purpose, runtime and the systems it can reach.
- Export the rights held by the agent and its sponsor. Remove permissions that the approved task does not require.
- Test reads, writes, unrelated tool calls and behaviour after prompt injection. Logs should show agent actions separately from user activity.
- Require human approval before money moves, data is deleted, permissions change or information is sent to an external party.
- Approve procurement only when the quotation states the release stage, SKU, EU tenant availability and licensing basis.