Microsoft Expands Security Controls for Local AI Agents

AI coding agents are moving onto employee devices—and, with them, into development environments, files, credentials, tools, and business data. That creates a governance problem for enterprise security teams: an agent may be installed locally, started by an employee, and able to act using access that was never designed for an autonomous system.

In an October 19, 2026, Microsoft Security announcement, Microsoft outlined expanded discovery and a broader approach to controlling locally deployed agents. The company said it was adding 35 local-agent types, bringing its announced total to 60, including Claude Code, OpenAI Codex, and GitHub Copilot. The plan also includes distinct agent identities, permissions scoped to individual tasks, continuous risk assessment, and responses that can restrict or stop an agent as circumstances change. ([microsoft.com](https://www.microsoft.com/en-us/security/blog/2026/10/19/agents-are-your-newest-insiders-security-must-move-at-their-speed/))

The announcement makes Microsoft AI agent security an enterprise governance story, not simply an inventory update. The central idea is that organizations need to know which agents are operating, distinguish an agent’s actions from its sponsor’s, limit what it can do, and adapt controls when its behavior or risk changes.

Why local agents change the security picture

Traditional software inventories can tell IT which applications are installed. Agent governance needs to answer harder questions: Which agent is actually running? Which user and device is it associated with? What tools, services, or data can it reach? And are its actions still aligned with the task it was given?

These questions matter especially for coding agents. Depending on their setup, they may read a repository, modify files, run commands, or connect to tools and services. Other local agents may operate on documents or business workflows. Microsoft’s concern is not that agents are inherently malicious; it is that they can make mistakes, be manipulated by untrusted input, or act in ways that exceed the original intent—potentially at machine speed. ([microsoft.com](https://www.microsoft.com/en-us/security/blog/2026/10/19/agents-are-your-newest-insiders-security-must-move-at-their-speed/))

An employee’s existing permissions are not automatically an appropriate permission set for an agent. If an agent uses a person’s broad access, an error or malicious instruction could have consequences beyond the immediate task. That is why the announcement emphasizes a separate identity and authority for each agent, rather than treating the agent as an invisible extension of its user.

Discovery: broader coverage, with important distinctions

Microsoft’s October 19 post says discovery is expanding by 35 local-agent types, to 60 supported types, and names Claude Code, OpenAI Codex, and GitHub Copilot as examples. Discovery can help an organization bring agents into a shared view so security and IT teams can investigate ownership, activity, and risk. The announcement also describes extending Microsoft Entra Agent ID to cover additional patterns, including local and previously unknown agents identified by security sensors. ([microsoft.com](https://www.microsoft.com/en-us/security/blog/2026/10/19/agents-are-your-newest-insiders-security-must-move-at-their-speed/))

There is a practical qualification: “supported” does not mean every product, operating system, or protection capability is covered in the same way. Microsoft’s support matrix separates agent discovery from runtime protection and lists support by platform and scenario. It also says discovery is activity-based: installing a supported agent by itself does not guarantee that it will appear in the inventory; Defender must observe activity on an onboarded device. ([learn.microsoft.com](https://learn.microsoft.com/en-us/defender-endpoint/ai-agent-support-matrix?wt.mc_id=studentamb_365381))

Microsoft later reported that local-agent and configured MCP-server discovery on Windows and macOS was generally available, with coverage expanded to more than 50 supported agents and MCP servers. The same update described local-agent runtime protection for Windows as still in preview. The figures and availability descriptions refer to different announcements and capabilities, so organizations should check Microsoft’s current support matrix and product guidance rather than assume that every one of the 60 types has identical, generally available enforcement. ([techcommunity.microsoft.com](https://techcommunity.microsoft.com/blog/microsoftthreatprotectionblog/now-generally-available-discover-local-ai-agents-with-microsoft-defender/4568216))

For security teams, the useful takeaway is to distinguish three questions: Can the product detect this agent? Can it report related tool or MCP-server configuration? And can it enforce runtime controls for this specific agent and platform? An affirmative answer to the first does not automatically mean the other two are supported.

Identity and permissions: make authority explicit

Microsoft’s proposal treats an agent as an accountable entity with an identity distinct from the person who launches or sponsors it. That identity can provide a consistent point for attribution, ownership, lifecycle management, permissions, and policy. In an investigation, this should help teams separate “the employee opened the file” from “the agent took an action on the employee’s behalf.”

The next layer is task-scoped authority. Microsoft describes Dynamic Permissions as a way to set organizational boundaries and grant only the authority an agent needs for an approved task, for a limited period. Permissions can be narrowed or removed as the task changes or ends; higher-impact actions can be gated by verified human approval. The agent should not gain authority beyond that of its user. ([microsoft.com](https://www.microsoft.com/en-us/security/blog/2026/10/19/agents-are-your-newest-insiders-security-must-move-at-their-speed/))

For example, a code-review agent might need read access to a designated repository and permission to propose changes, but not permission to publish a release or alter production credentials. A finance agent may need to read claims and check policy without receiving unrestricted access to payment systems. These are practical examples of the least-privilege principle, not claims that Microsoft automatically configures those specific permissions for every agent.

Permissions are only one boundary. Microsoft also describes controlled runtimes, such as sandboxes, and policies that mediate an agent’s access to tools, APIs, MCP servers, resources, and other agents. A policy that blocks a destination but ignores the data being sent or received may miss important context, so Microsoft argues for controls that consider both access paths and content. ([microsoft.com](https://www.microsoft.com/en-us/security/blog/2026/10/19/agents-are-your-newest-insiders-security-must-move-at-their-speed/))

Dynamic risk and proportionate containment

A static approval at onboarding cannot account for every later change. An agent may start with a valid assignment, then encounter a malicious instruction in a repository, document, website, or tool response. The software configuration may be unchanged even though the situation—and the risk—has changed.

Microsoft’s proposed Dynamic Agent Risk model combines signals from identity, data, endpoints, cloud, network, runtime, and the agent’s activity. It is intended to assess configuration, reachable resources, potential impact, and whether behavior appears to drift from the task or organizational intent. Microsoft describes this as an ongoing assessment, rather than a one-time score. ([microsoft.com](https://www.microsoft.com/en-us/security/blog/2026/10/19/agents-are-your-newest-insiders-security-must-move-at-their-speed/))

Dynamic Conditional Access is the proposed control loop: a change in risk can trigger a graduated response. Rather than choosing only between “allow everything” and “shut down,” policy could preserve safe read access while blocking writes, narrow access to resources, restrict network paths, shorten or revoke permissions, or request human approval for a consequential action. At higher risk, the runtime could be isolated or execution stopped. ([microsoft.com](https://www.microsoft.com/en-us/security/blog/2026/10/19/agents-are-your-newest-insiders-security-must-move-at-their-speed/))

That graduated approach is important operationally. A security team may want to prevent an agent from pushing code while allowing it to continue reading a repository for investigation. The objective is to contain the risky capability without automatically discarding all useful work. Whether a particular Microsoft control can take a given action depends on product support, configuration, and the agent scenario.

What enterprise teams can do now

The announcement describes a direction and a set of Microsoft capabilities; organizations can still take practical steps to reduce risk while evaluating availability:

1. Inventory actual use. Review endpoint and developer workflows to identify approved and unapproved coding and productivity agents. Treat discovery as a starting point, and verify which devices and agent types your tools can observe.
2. Map agent access. For each important workflow, document the repositories, files, credentials, network destinations, APIs, tools, and MCP servers the agent can reach. Identify access inherited from a sponsoring user.
3. Define task boundaries. Specify the intended task, allowed actions, data scope, time limit, and actions that require a person. Prefer separate, narrow agent credentials over broad, long-lived user credentials where the architecture supports it.
4. Separate observation from enforcement. If a product offers audit and block modes, begin by observing behavior on a limited device group. Review alerts and false positives before broad enforcement. Microsoft’s October 29 Defender guidance recommends starting with a limited group in Audit mode, reviewing detections for one to two weeks, then considering Block mode. ([techcommunity.microsoft.com](https://techcommunity.microsoft.com/blog/microsoftthreatprotectionblog/now-generally-available-discover-local-ai-agents-with-microsoft-defender/4568216))
5. Test failure paths. In a controlled environment, confirm what happens when an agent receives untrusted instructions, tries an out-of-scope tool, or attempts a high-impact change. Check that logging, approval, and containment work as intended.
6. Assign ownership. Give each agent a business owner and a technical owner, and define how it is approved, reviewed, updated, and retired. Include security, endpoint, identity, development, and data-governance teams in the process.

These steps do not depend on a single vendor control. They help organizations establish policy and accountability before agent adoption becomes too widespread to manage through ad hoc exceptions.

Limitations to keep in view

Expanded discovery is not a guarantee of complete visibility. Microsoft’s documentation says inventory depends on supported combinations and observed activity on onboarded devices; its support matrix also distinguishes discovery from runtime protection. Some listed platform support may be in preview, and support for MCP configuration or enforcement can differ by agent. ([learn.microsoft.com](https://learn.microsoft.com/en-us/defender-endpoint/ai-agent-support-matrix?wt.mc_id=studentamb_365381))

Likewise, a discovered agent is not necessarily governed end to end. Identity assignment, permissions, data controls, runtime boundaries, and response policies each need appropriate configuration and integration. The October 19 post describes Dynamic Permissions, Dynamic Agent Risk, and Dynamic Conditional Access as being introduced; teams should verify availability, prerequisites, and licensing in current Microsoft documentation before planning a rollout. ([microsoft.com](https://www.microsoft.com/en-us/security/blog/2026/10/19/agents-are-your-newest-insiders-security-must-move-at-their-speed/))

Finally, risk scoring and automated containment cannot replace clear business policy or human judgment. Organizations still need to decide which actions are acceptable, which require approval, and how to handle a false positive that blocks legitimate work. Logging and review are necessary to assess whether automated controls are effective and proportionate.

FAQ

What did Microsoft announce on October 19, 2026?

Microsoft said it was expanding local-agent discovery by 35 types, to 60 supported types, including Claude Code, OpenAI Codex, and GitHub Copilot. It also outlined distinct agent identities, task-scoped permissions, dynamic risk assessment, and policy-driven containment. ([microsoft.com](https://www.microsoft.com/en-us/security/blog/2026/10/19/agents-are-your-newest-insiders-security-must-move-at-their-speed/))

Does discovery mean every local agent is automatically blocked or secured?

No. Discovery helps identify supported agents and, depending on the scenario, associated context. Microsoft documents discovery and runtime protection separately, with different platform and integration requirements. Inventory alone should not be treated as proof that an agent is actively protected. ([learn.microsoft.com](https://learn.microsoft.com/en-us/defender-endpoint/ai-agent-support-matrix?wt.mc_id=studentamb_365381))

What is task-scoped permissioning?

It means granting an agent only the authority required for a specific approved task, limiting how long that authority lasts, and changing or removing it when the task changes or finishes. Microsoft says higher-impact actions can require verified human approval. ([microsoft.com](https://www.microsoft.com/en-us/security/blog/2026/10/19/agents-are-your-newest-insiders-security-must-move-at-their-speed/))

What should an organization check before deploying these controls?

Check the current support matrix for the exact agent, operating system, discovery features, MCP visibility, and runtime-protection mode. Confirm device onboarding, prerequisites, availability, and policy behavior in a test group before applying enforcement broadly. Microsoft’s support documentation notes that combinations not listed are not currently documented as supported. ([learn.microsoft.com](https://learn.microsoft.com/en-us/defender-endpoint/ai-agent-support-matrix?wt.mc_id=studentamb_365381))

The bigger picture

Microsoft’s expansion reflects a broader shift in enterprise security: AI agents need to be managed as active identities with bounded authority, not treated only as applications or as extensions of their users. Wider discovery can help teams find local agents, but governance depends on what follows—clear ownership, limited permissions, visibility into tools and data, and a tested response when risk rises. For enterprises adopting coding and other agents, that is the practical meaning of Microsoft AI agent security.