Do not bound AI agents and Copilots only at creation through user roles, but per task, tool and runtime action, with just-in-time approval and auditable logs. In September 2026 Microsoft announced the preview of an Entra MCP Firewall that gives central runtime visibility into traffic between agents and external MCP servers and applies Zero Trust policy and runtime protection to it.
The occasion is a concrete product change. In the Entra update of September 2026 Microsoft describes an MCP Firewall within Global Secure Access. It gives administrators central visibility into the traffic between AI agents and external MCP servers, lets them apply Zero Trust policy, discovers so-called shadow servers and makes it possible to allow or block servers, tools, resources and prompts. With that, least privilege shifts from a setting made when an agent is created to a control that applies during execution.
Our analysis: this shift is the actual news. As long as permissions are recorded only at provisioning, what an agent actually calls at the moment of action remains invisible. A control point on the tool traffic changes that, provided organisations move their governance model along with it.
Why an AI agent needs its own identity and task-bound scope
Microsoft describes least privilege for agents as a design requirement. The guidance Least privilege for AI agents with Microsoft Entra Agent ID states that identity, scope, tool access and auditability must be defined in advance. According to Microsoft, the recommended approach includes:
- taking inventory of effective permissions;
- unique identities per agent;
- authorisation bound to a task;
- allowlists for tools and actions;
- time-bound elevation instead of permanent permissions;
- logging and the ability to revoke access.
An agent that operates with a shared user identity cannot be traced afterwards. A separate identity per agent makes it possible to determine precisely on whose behalf an action took place and which scope applied to it. That aligns with the broader principle of giving AI agents their own identity with logged authorisation, so that actions remain traceable.
How the MCP Firewall adds a new control point on tool traffic
The difference between static roles and runtime control becomes visible with the Model Context Protocol. During a task an agent can call external MCP servers for tools and data resources. Without visibility into that traffic, an administrator does not know which resources are being accessed. According to Microsoft, the MCP Firewall provides a policy control point for that traffic: it becomes visible, policy can be enforced, and unapproved servers can be blocked.
Our assessment: the value lies not in blocking as such, but in the fact that the allowlist becomes a runtime property. An agent can then be limited to servers, tools and prompts that are permitted for its task, while the MCP traffic becomes visible for control. This does require maintenance: the allowlist must move along with the tasks that agents actually perform, otherwise either too much access arises, or traffic that runs outside the known paths.
Which administrator roles and approvals belong to Copilot agents
Least privilege applies not only to the agent, but also to the people who configure and roll out agents. The documentation on Copilot agent governance recommends the least-privileged administrative role model. Organisations can restrict agent access to specific users or groups, and route sensitive AI and search administrator roles through Privileged Identity Management, with just-in-time activation, approval, MFA and audit. The Agents admin guide for Microsoft 365 additionally describes managing which users, groups, apps and agents are available within a tenant.
For a concrete workflow this comes down to a series of test questions. We summarise the guidance into a practical checklist as follows:
- Which agent acts, and with which own identity?
- On behalf of which user or group, within which tenant scope?
- With which time-bound scope, instead of permanent permissions?
- Against which tool or data resource, and is it on the allowlist?
- Which actions are permitted and where is human approval required?
- Which logs prove that access was restricted or revoked?
Making that last point demonstrable aligns with the broader practice of demonstrably logging human oversight of AI decisions. For the GDPR side of agents that choose their own data and tools, it is useful to manage AI agents as non-human identities.
Why trust in agent permissions is greater than the actual enforcement
That the new tooling is needed is shown by research that Infosecurity Magazine reported on 1 September 2026 in 65% of Enterprises Have Seen AI Agents Act Out of Scope. According to that reporting, 94% of the IT and security leaders surveyed say they are confident that agents do not have too much access, while 32.7% actually apply least-privilege provisioning and 34.2% check authorisation at the moment of execution. The reporting also names recommendations: runtime authorisation, automatic detection and containment, and revoking credentials when pilots end.
Our analysis: these figures expose the core. Trust in correct permissions is far greater than the actual application of runtime authorisation. The MCP Firewall and the Entra guidance provide tools to narrow that gap, but do not close it by themselves. The difference between 94% confidence and roughly a third that checks at runtime only shrinks when allowlists, approvals and logs become part of the daily workflow instead of a one-off configuration. This is the broader subject within the governance of agentic AI and autonomous AI agents: least privilege is not a tick box at creation, but a property that can be controlled per task and per action.
Sources and references
Sources: The article draws on Microsoft's Entra update of September 2026, Microsoft's least-privilege guidance and Copilot administration documentation on Microsoft Learn, and on research reported by Infosecurity Magazine.