Microsoft Expands Security Controls for Local AI Agents

AI agents are moving onto employee devices, where they can assist with coding and other work while interacting with files, tools, services, and business data. For enterprise security teams, that creates a practical challenge: an agent may be installed or started locally without following the organization’s usual central deployment process, yet still have access to important resources.

In an October 19, 2026 announcement, Microsoft described an expansion of its security approach for these agents. The company says discovery now covers 60 supported types of local agents, including Claude Code, OpenAI Codex, and GitHub Copilot. It also outlined an approach that gives agents their own identities, limits authority to specific tasks, reassesses risk as activity changes, and allows security controls to respond in real time. The announcement frames this as a governance effort for an expanding agent estate—not simply a new list of developer tools to detect. Microsoft Security Blog. ([microsoft.com](https://www.microsoft.com/en-us/security/blog/2026/10/19/agents-are-your-newest-insiders-security-must-move-at-their-speed/))

Why local agents are an enterprise security concern

Agents can be useful because they act on a user’s behalf: for example, helping write code, research information, or work across applications. That usefulness often depends on access to data and tools. But a locally run agent can introduce an unfamiliar execution path on a managed device, and its access may not be obvious from a conventional inventory of centrally managed applications.

The risk is not that every agent is malicious. Microsoft’s announcement emphasizes that agents can make mistakes, be manipulated by untrusted inputs, or be compromised. Their behavior may also change as their context and plans change. An agent that starts a task with legitimate access could later encounter a malicious instruction in a document or attempt an action outside the task it was meant to perform. Because agents can operate quickly, security teams may need controls that react faster than a person can manually investigate every event. ([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 makes Microsoft AI agent security a question of governance as much as detection: Which agents exist? Who is responsible for them? What may each agent access or change? And what should happen when its activity no longer matches its intended purpose?

Discovery expands to 60 local-agent types

Microsoft says it is adding support for 35 additional types of local agents, bringing the total to 60. The named examples include Claude Code, OpenAI Codex, and GitHub Copilot. The company describes bringing discovered agents into a unified registry so organizations can get a more consistent view of agent ownership, activity, and risk. ([microsoft.com](https://www.microsoft.com/en-us/security/blog/2026/10/19/agents-are-your-newest-insiders-security-must-move-at-their-speed/))

Discovery matters because security controls cannot govern an agent they do not know is present. It can give IT and security teams a starting point for finding agents that arrive through different routes, including local installations, partner platforms, or software development kits. But discovery is only the first step: learning that an agent exists does not, by itself, establish who owns it or limit what it can do.

Microsoft’s stated direction is to give agents a distinct identity, separate from the employee using or sponsoring them. That identity can provide a durable reference for attribution, ownership, lifecycle management, risk, permissions, and policy. In practical terms, it can help an organization distinguish actions performed by an agent from actions performed directly by the person at the keyboard. ([microsoft.com](https://www.microsoft.com/en-us/security/blog/2026/10/19/agents-are-your-newest-insiders-security-must-move-at-their-speed/))

Give agents task-scoped authority—not a user’s full access

A central control in Microsoft’s announcement is Dynamic Permissions. The stated principle is that an agent should not automatically inherit all the standing access of its user. Instead, it should start with no authority or with the least authority needed, then receive permission for an approved task and only for as long as that task requires. Permissions may be narrowed or removed as the task changes or ends. Higher-impact actions can require 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/))

This separates the employee’s identity and access from the agent’s task-specific authority. For example, a coding agent might need to read a particular project and propose a change. That does not automatically mean it should also have broad access to unrelated repositories, production credentials, or the ability to deploy changes. The organization’s policy should define the outer boundary; task-level access should remain within it.

For security teams, this model points toward concrete governance questions. What is the agent’s approved purpose? Which files, repositories, APIs, or tools does it need? Does it need read access, write access, or both? How long should access last? Which actions should require a person’s approval? These are useful design questions regardless of whether an organization uses Microsoft’s announced controls or another security architecture.

Assess risk continuously and respond proportionately

Microsoft also announced Dynamic Agent Risk and Dynamic Conditional Access for agents. The company describes Dynamic Agent Risk as combining signals from areas such as identity, data, endpoints, cloud, network, runtime, and the agent’s activity. Its purpose is to maintain an evolving view of risk rather than rely only on a one-time assessment at setup. ([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 described as a way for changes in risk to trigger coordinated responses across enforcement points. Those responses need not be an all-or-nothing decision. Microsoft says policies could reduce permissions, allow reads while blocking writes, narrow access to resources, restrict network paths, shorten or revoke time-bound access, or require verified human approval. At higher risk levels, controls could isolate the runtime or stop execution. ([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. If an agent’s activity becomes suspicious, a blanket shutdown may be appropriate in some cases—but it may also interrupt harmless work. A more tailored response could preserve low-risk access while blocking a sensitive action, then escalate if evidence of risk increases. The right response depends on the sensitivity of the data, the potential impact of the action, and the organization’s tolerance for disruption.

Contain the runtime and the routes to tools

Identity and permissions are not the only control points. Microsoft’s post describes running an agent’s model and harness in a controlled environment, rather than allowing it to inherit unrestricted access to a device. It cites Microsoft Execution Container as an example of a sandbox that can provide policy-controlled access and an enforcement boundary for monitoring. ([microsoft.com](https://www.microsoft.com/en-us/security/blog/2026/10/19/agents-are-your-newest-insiders-security-must-move-at-their-speed/))

Organizations should also consider the paths an agent can use to reach tools, APIs, Model Context Protocol servers, data, and other agents. Monitoring only which destination an agent contacts may not reveal what information it sends or receives. Microsoft argues for controls that can observe content and consider sensitivity, provenance, and whether untrusted information may be influencing the agent’s behavior. ([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 an enterprise rollout, this suggests reviewing both the agent’s execution environment and its connections. A useful inventory can record the agent, device, owner, business purpose, approved tools and destinations, permission level, and any required human approval. That inventory is a practical governance recommendation, not a claim that Microsoft’s announcement requires a particular checklist or configuration.

Practical steps for security and IT teams

1. Establish visibility. Identify where local agents may run and how your organization will review discovered agents. Include developer workstations and teams that use coding assistants in the assessment.
2. Assign accountability. Require a responsible owner and a documented business purpose for approved agents. Decide how to handle agents that are detected but have no known owner.
3. Define task boundaries. Specify the resources, tools, and actions an agent needs for its use case. Separate read permissions from write, approval, and deployment permissions where possible.
4. Set time limits and approval gates. Avoid treating access as permanent when the task is temporary. Identify which consequential actions need a person to review and approve them.
5. Plan graduated responses. Decide in advance when to restrict writes, narrow resource access, require approval, isolate an agent, or stop execution. Test whether the response protects sensitive assets without causing avoidable disruption.
6. Review evidence and exceptions. Monitor activity against the approved purpose, investigate unusual behavior, and establish a process to revisit access when an agent, task, or risk context changes.

These steps are general operational guidance derived from the governance principles in Microsoft’s announcement. They do not guarantee that every local agent can be detected or controlled by any single product. Security teams should validate coverage in their own device, identity, and application environment.

What the announcement does—and does not—establish

Microsoft’s post describes an expanded discovery scope and a broader security approach, including agent identity, Dynamic Permissions, Dynamic Agent Risk, and Dynamic Conditional Access. It presents these capabilities as part of Microsoft’s security direction and its Project Perception work. The announcement does not, in the material cited here, provide a complete deployment guide, a release schedule for each capability, a licensing breakdown, or a guarantee that every agent variant and execution path will be detected.

That distinction matters when planning a rollout. A supported-agent count is not the same thing as universal coverage, and discovery is not equivalent to prevention. Enterprises should confirm product availability, prerequisites, supported platforms, configuration requirements, and licensing with current Microsoft documentation and their account team before basing a control program on a particular feature. They should also test how their own security policies behave with the agents and workflows employees actually use.

The broader lesson is useful beyond any one vendor: agent security needs independent controls around the model. An agent’s own output should not be the only evidence used to decide whether it is safe, and the agent should not be able to override the policies that govern its access. Visibility, least privilege, monitoring, and containment work together; none is a complete substitute for the others. ([microsoft.com](https://www.microsoft.com/en-us/security/blog/2026/10/19/agents-are-your-newest-insiders-security-must-move-at-their-speed/))

FAQ

Which local agents did Microsoft name?

Microsoft named Claude Code, OpenAI Codex, and GitHub Copilot as examples among 60 supported local-agent types. The company says the total includes 35 additional types in the announced expansion. ([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 discovering an agent mean it is blocked?

No. Discovery helps an organization identify an agent and bring it into view. Separate identity, permission, runtime, and policy controls are needed to govern what it can access or do.

What does task-scoped permission mean?

It means granting an agent only the authority needed for a defined task, for a limited period, rather than automatically giving it all of its user’s standing access. Microsoft says permissions can be reduced or removed as the task changes or ends, with human approval required for higher-impact actions under policy. ([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 happens if an agent’s risk changes?

Microsoft describes a graduated response: controls could narrow access, block writes while preserving reads, restrict network paths, require human approval, or, at higher risk, isolate the runtime or stop execution. Exact behavior depends on policy and implementation. ([microsoft.com](https://www.microsoft.com/en-us/security/blog/2026/10/19/agents-are-your-newest-insiders-security-must-move-at-their-speed/))

Is the expanded capability available to every organization now?

The October 19 post describes the expansion and announced capabilities, but does not establish a complete availability, licensing, or rollout schedule. Confirm current requirements and availability in Microsoft’s official product documentation before planning deployment.

As local coding and other agents spread across managed devices, enterprise security teams need to govern more than installation. The durable task is to identify each agent, limit its authority, observe what changes, and contain risky behavior without assuming every unexpected signal requires the same response.