Microsoft Expands Security Controls for Locally Deployed AI Agents

AI agents are moving onto employee devices and into everyday work, including software development. That can leave security teams managing tools that were installed or introduced outside a central rollout. Microsoft’s October 19, 2026 announcement describes an expanded approach to finding and governing those agents across enterprise environments.

The announcement says Microsoft is expanding discovery by 35 additional local-agent types, bringing the total to 60 supported local agents. Examples named by Microsoft include Claude Code, OpenAI Codex, and GitHub Copilot. It also outlines separate identities for agents, permissions scoped to a task, ongoing risk assessment, and responses that can restrict or stop an agent when warranted. Together, these controls make Microsoft AI agent security an enterprise governance issue—not simply a question of which AI tools employees may use.

This article summarizes Microsoft’s announcement; it does not imply that every described capability is generally available in every product or environment. See the Microsoft Security blog post for the original description.

Why local-agent discovery matters

Agents may be introduced through a Microsoft platform, a partner, a software development kit, or a local installation. The last category can be harder for central IT to inventory, especially when a developer installs an assistant to work with code and files on a managed device. If a team cannot see an agent, it may struggle to determine who owns it, what it can access, and whether its activity is consistent with the task it was meant to perform.

Microsoft says it is extending discovery to 35 more local-agent types, for 60 supported types in total. Claude Code, OpenAI Codex, and GitHub Copilot are among the examples listed. The agents can be brought into a unified registry so organizations can understand ownership, activity, and risk, regardless of how the agents were discovered.

Discovery is a starting point, not a security decision by itself. An inventory can help an organization identify an agent, but the organization still needs to decide whether its use is allowed, what data and tools it may reach, and which controls should apply. Microsoft frames this as a continuous process: visibility informs risk, risk informs policy, and policy determines what the agent may do.

Give agents identities and accountable owners

Microsoft says it is extending Microsoft Entra Agent ID with identity types for additional agent patterns, including local and previously unknown agents identified by security sensors. The intent is to give an agent a durable identity distinct from the employee who uses or sponsors it. That identity can serve as an anchor for attribution, ownership, lifecycle management, risk, permissions, and policy.

That distinction matters during investigation. If an agent acts on a user’s behalf, an organization needs to understand which actions were taken by the person and which were performed by the agent. An agent-specific identity can make that distinction clearer and provide a target for access policies—even if the agent was not originally integrated with Microsoft Security.

For enterprise teams, a practical governance step is to establish ownership expectations for discovered agents. Decide who can approve an agent’s use, who reviews its access, and how it should be handled when its owner changes roles or no longer needs it. Those are implementation recommendations, not a claim that the announcement automatically supplies every organization’s approval or lifecycle process.

Replace inherited access with task-scoped permissions

A common risk is allowing an agent to inherit the full standing access of the employee who launched it. Microsoft argues that agents should instead start with no authority, or with least privilege, and receive only what they need for an approved task and for as long as that task requires.

The announcement describes Dynamic Permissions as a way to put organization-wide policy around agent authority. The organization’s policy sets the outer boundary; an agent cannot receive authority its user does not have. Permissions can then be scoped to a task, limited in time, reduced or removed as the task changes or ends, and paired with verified human approval for higher-impact actions.

For example, an expense-review agent might need to read submissions, consult policy, and approve routine reimbursements. It should not automatically receive every permission held by its sponsor. The same idea applies to a coding assistant: access should be considered in relation to the specific development task and the resources it requires, rather than assumed from the employee’s broader account privileges.

Microsoft also emphasizes controlling the agent’s action space. That means considering which tools, APIs, Model Context Protocol servers, resources, and other agents it can invoke—not only which destinations it can connect to. The company says security controls should also consider the content flowing into and out of an agent, including its sensitivity and provenance.

Assess risk as the agent works

Least privilege can reduce the impact of an error, but it cannot guarantee that an agent will stay aligned with its task. An agent may encounter untrusted content or experience a change in context. Microsoft’s proposed Dynamic Agent Risk combines signals from identity, data, endpoints, cloud, network, runtime, and the agent’s activity. The assessment is meant to reflect the agent’s current configuration, reachable resources, potential impact, and whether its actions are drifting from the user’s or organization’s intent.

Microsoft describes this as a continuously updated view, rather than a one-time score assigned during onboarding. The practical question is not always simply “keep running or stop.” Depending on policy and the situation, an organization may instead want to preserve safe read access while blocking writes, narrow the agent’s access to resources, or require human approval for a consequential action.

The companion capability, Dynamic Conditional Access for agents, is described as a way for a change in risk to trigger coordinated policy responses. Microsoft says those responses can include reducing permissions, restricting network paths, shortening or revoking time-bound access, requiring approval, isolating the runtime, or stopping execution entirely. These are graduated options; the announcement presents a kill switch as one possible response at the highest risk levels, not the only response to every alert.

Containment needs to extend beyond identity

Microsoft’s approach covers the agent’s runtime as well as its identity and access. The blog says models and agent harnesses should run in controlled environments rather than automatically inheriting fully privileged access to a device. It cites Microsoft Execution Container as an example of a sandbox designed to provide policy-controlled access and an enforcement boundary outside the agent’s reach.

The broader design principle is to place independent controls around software whose outputs and plans can change. In Microsoft’s framing, the model should not decide its own security authority. Separate systems should observe activity and enforce the organization’s rules. The blog also says model-level signals, such as chain-of-thought and other transparency signals, may contribute evidence to risk assessment; it stresses that the model itself must not become the security boundary.

Microsoft also describes Project Perception and Guardian Agents as part of its response for security teams. In the announcement, Guardian Agents can help investigate changes in risk, explain relevant evidence, and recommend or apply containment within boundaries set by people. Playbooks define desired security outcomes and coordinate actions, while people retain control over policies, approval boundaries, and delegation rules.

Practical steps for security and IT teams

1. Build an agent inventory. Identify where local agents are appearing, who owns them, and what work they support. Treat discovery as an input to governance, not proof that an agent is approved or fully controlled.
2. Define permitted use and ownership. Document who can authorize agents for different work and who is responsible for reviewing their access and continued use.
3. Map access to tasks. For each approved workflow, identify the minimum data, tools, APIs, and systems an agent needs. Avoid treating an employee’s existing permissions as a suitable default for an agent.
4. Set boundaries for consequential actions. Decide which actions can be automated, which require human approval, and what evidence should be retained for review.
5. Plan graduated responses. Define when policy should narrow access, block writes, restrict network paths, require approval, isolate execution, or stop an agent. A proportionate response can preserve safe work while limiting risky actions.
6. Test the operating process. Use representative workflows to check that teams can identify the agent, understand its access, investigate behavior, and apply the intended response. Confirm product availability and configuration requirements with Microsoft before relying on a capability in production.

These steps are governance recommendations based on the controls Microsoft describes. They are not a substitute for validating which products, integrations, policies, and device configurations are available in a particular environment.

Limitations and questions organizations should ask

The October 19 blog is a product and strategy announcement, not a complete deployment guide. It does not provide, in the article, a full list of all 60 supported agent types, detailed technical requirements for every agent, or a comprehensive rollout schedule. It also does not establish that discovery alone will provide complete visibility into every local installation or every action an agent takes.

Organizations should verify which capabilities are available to them, what licensing or configuration they require, which operating systems and integrations are covered, and how signals and enforcement work in their own environment. They should also test how policies behave when an agent’s risk changes. Product names and announced capabilities should not be taken as a guarantee that every control is enabled by default or applies identically to every agent.

FAQ

What did Microsoft announce on October 19, 2026?

Microsoft said it was expanding discovery by 35 additional local-agent types, bringing its total to 60 supported local agents. It also outlined agent identities, task-scoped Dynamic Permissions, Dynamic Agent Risk, Dynamic Conditional Access, and related runtime containment and response capabilities.

Which local agents are mentioned?

The announcement names Claude Code, OpenAI Codex, and GitHub Copilot as examples among the supported local agents. It does not list all 60 types in the blog post.

Does agent discovery mean the agent is approved or safe?

No. Discovery helps an organization know that an agent exists and investigate ownership, activity, and risk. Approval, access policy, monitoring, and response remain separate governance decisions.

How are task-scoped permissions different from user permissions?

The employee keeps their own access, while the agent has a distinct identity and authority limited to the task and its duration. Microsoft says organization-wide policy sets the upper boundary, and higher-impact actions can require verified human approval.

What can happen when an agent’s risk rises?

Microsoft describes graduated responses such as reducing permissions, preserving read access while blocking writes, narrowing reachable resources, restricting network paths, requiring approval, isolating the runtime, or stopping execution. The appropriate response depends on risk and organizational policy.

Are all the described controls available to every organization now?

The announcement does not specify in the blog post every availability date, licensing condition, or technical requirement. Organizations should confirm current availability and deployment details with Microsoft for their specific products and environment.

Bottom line

As coding and other agents spread across managed devices, enterprise security needs to account for more than the model or the employee who launched it. Microsoft’s announcement brings local-agent discovery together with distinct identities, task-limited authority, changing risk assessment, and responses that can contain an agent without automatically treating every concern as a reason to shut down all activity. The value of that approach will depend on how completely organizations can discover agents, configure policies, and verify that controls work in their own environments.