Microsoft wants each AI agent to have its own identity and narrower authority. The delivery status matters

The problem is inherited human authority

The 19 October Microsoft Security account says an agent may be installed locally or connected through platforms that the central security team did not approve or even see. If it runs with a developer's or employee's full account authority, a mistake, hostile tool response or prompt injection can cause changes in systems the agent was never intended to touch. Microsoft frames the answer as separating the model's reasoning from the authority to access resources. Identity, policy, enforcement and logs must sit outside the model's own decisions.

Microsoft says it is expanding discovery by 35 local agent types to 60 supported types and bringing found agents into a unified registry. That is a discovery claim about supported types, not a count of actual agents in any customer's estate. It says Entra Agent ID is being extended to cover local and previously unknown agents, while Dynamic Permissions, Dynamic Agent Risk and Dynamic Conditional Access are being introduced to narrow what agents can do as context changes. The article also describes execution containers and Guardian Agents that can help investigate and contain risky behaviour. Some phrases are present-tense capability descriptions and others are introduction or roadmap language. An operator needs product documentation and tenant availability checks before treating any control as deployed.

a control-to-evidence comparison. It avoids implying that a named product feature is universally rolled out. Source: Microsoft Security, 19 October 2026.

Which agents exist?

• Microsoft describes: Discovery support for 60 local agent types and a unified registry.
• Verification an operator still needs: Whether the relevant sensor is deployed and sees the estate's versions and platforms.

Who owns the action?

• Microsoft describes: Distinct agent identity linked to ownership and lifecycle.
• Verification an operator still needs: Whether logs separate a human's action from the agent acting for them.

What can it reach?

• Microsoft describes: Task-scoped, time-limited Dynamic Permissions.
• Verification an operator still needs: Whether the relevant application or tool actually enforces those scopes.

What happens when risk changes?

• Microsoft describes: Dynamic Agent Risk, Conditional Access and containment choices.
• Verification an operator still needs: Which signals are consumed, how decisions are audited, and what modes are available now.

Four separate boundaries behind the product names

Microsoft's security account describes an agent as a model, a harness, a tool-and-resource action space, and a runtime. That decomposition gives a better audit method than asking whether an agent has a security dashboard. The model proposes an action. The harness turns that proposal into a tool call. The tool credential grants authority. The runtime determines which files, network paths and processes the agent can reach. Control over only one layer leaves the others open.

A distinct Entra Agent ID could answer which agent performed a call, but it will not alone prevent a broad human token being reused inside the harness. A restricted Microsoft Execution Container could constrain local processes and resources, but it will not alone decide whether an expense approval was valid. A network destination allowlist could stop an unknown host, but it may not distinguish a permitted API request that reads more records than the task needed. Microsoft proposes policy and signals at each boundary, with organisation-wide limits outside the model's reach.

Its four responsibilities are not a four-step deployment sequence. Discovery and identity help establish ownership; task- and time-scoped Dynamic Permissions narrow authority; runtime, data and tool controls mediate execution; Dynamic Agent Risk and Conditional Access can contract rights if evidence changes. Microsoft's wording says it is introducing several controls. The announcement is an architecture and delivery direction, not a verified account of those controls preventing a specific incident across all supported environments.

The control path is a design to verify, not a claim that every Microsoft feature is already deployed in every tenant.

A concrete trust-boundary example

Microsoft gives an expense-approval agent as an example. A human employee might have broad access to finance data; the agent only needs specific claims, policy and limited approval authority for a short task. If it encounters a hostile document and tries an unrelated action, the protection system should be able to preserve safe reads while blocking writes, require human approval, narrow network or data access, or isolate the runtime. Those are proposed control behaviours in Microsoft's architecture, not a reported live attack or a case study demonstrating a prevented loss.

For an expense task, a useful test case starts with an agent that may read one claim and the relevant policy but cannot export the whole finance database or approve its own increase in limit. Feed it a benign test document carrying an instruction outside the task and observe what the harness attempts, what the policy engine actually denies, what is recorded under the agent's identity, and whether the employee's wider rights are still separated. If a tool call succeeds with the employee's broad token, the policy claim has failed at the point of action even if a dashboard shows a low risk score.

The mechanism to test is: human assigns task → agent gets a distinct identity and bounded tools → independent policy evaluates each consequential action → logs preserve what was allowed, blocked or escalated. A registry without enforcement is an inventory. An identity without separate permissions is a label. A risk score without auditable action can become a dashboard rather than a boundary. That is the useful test of the announcement.

Separate discovery, containment and evidence

The figure 60 concerns types of locally running agents that Microsoft's discovery tooling says it supports after adding 35 more. It is not 60 installed agents in a customer estate, 60 vulnerabilities, or 60 product integrations with identical policy enforcement. A tenant should inventory installed agent instances and versions, then run a controlled discovery exercise to measure what its configured sensors actually find. The unsupported remainder is an unknown until measured.

A useful control record for each discovered agent has at least six fields: owner, task purpose, distinct identity, credential source, allowed tools and resources, and the log location for attempted and completed actions. Add expiry and revocation for temporary rights. This record lets a reviewer reconstruct who authorised an action and which policy was enforced. A registry entry alone cannot answer whether an OAuth token, MCP server or local shell still bypasses the intended boundary.

When risk changes, Microsoft describes several different possible decisions: keep reading but block writing, narrow the resources, require verified human approval, revoke time-bound access, isolate the runtime or stop it. These are not interchangeable. Blocking all access may halt a legitimate workflow unnecessarily; preserving reads during a suspected data leak may be too permissive. The policy must tie each response to a named risk signal, observable action and escalation owner. The public announcement does not publish an independent false-positive rate or a tenant-level efficacy result for those decisions.

What security teams can do now

Start with a local-agent inventory, including developer machines and non-standard installations. Record who installed each agent, which credentials or tokens it uses, the remote MCP servers and other tools it can invoke, and where its actions appear in logs. Where an agent shares a person's credential, identify the systems that cannot distinguish an agent action from a human one. Limit tool scopes and token life before adding automated workflows. For higher-impact writes, require an approval outside the model's own conversation. Then test the actual enforcement path with a benign untrusted document or tool response, rather than accepting the presence of a policy setting as proof.

A small acceptance test can make the procurement question concrete: install one supported local agent in a managed test environment, register or discover it, issue it a narrow task, and try three actions. The first should be allowed, the second should exceed its tool or data scope, and the third should be a consequential write requiring approval. Capture identity, policy decision, tool result and audit record for each. Then remove the permission and confirm the agent cannot reuse it. Repeat after a risk signal changes. This establishes what works in that tenant without assuming the whole roadmap is live.

The open question is availability. Microsoft provides an architectural direction and names extensions, but this source alone does not give a complete edition-by-edition release matrix or independent efficacy test. A follow-up should check product documentation, licensing, rollout status and evidence that each control blocks the intended action in a real tenant.

Sources checked 20 October 2026: Microsoft Security Blog, 19 October; Microsoft's companion announcement.