Microsoft Expands Project Perception to Discover and Govern Enterprise AI Agents

Enterprise AI agents can do more than answer questions. Depending on how they are configured, they may access company data, call tools and services, or take actions on a user’s behalf. That capability creates a security challenge: organizations need to know which agents are operating, what each can reach, and how to limit its authority if its behavior or circumstances change.

On October 19, 2026, Microsoft announced expanded Project Perception capabilities aimed at discovering and governing these agents. The announcement includes discovery for 35 additional types of local agents and a model for task-scoped, time-limited permissions. Microsoft says agent permissions and protections can adapt as context and risk change. The goal is to make security controls responsive to agent activity rather than relying only on broad permissions granted in advance. Read Microsoft’s announcement. ([microsoft.com](https://www.microsoft.com/en-us/security/blog/2026/10/19/agents-are-your-newest-insiders-security-must-move-at-their-speed/?trk=public_post_comment-text&utm_source=openai))

What Microsoft announced

Microsoft describes Project Perception as part of a broader approach to securing what it calls the “agentic insider”: an AI agent that operates within an organization and may interact with business systems or information. The company says it is expanding discovery to 35 additional types of local agents, bringing its stated total to 60 supported local agents. Microsoft names Claude Code, OpenAI Codex, and GitHub Copilot as examples. Discovered agents can be brought into a unified registry to give IT and security teams a view of agents, their 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/?trk=public_post_comment-text&utm_source=openai))

Discovery is a starting point, not a security boundary by itself. Finding an agent helps an organization understand that it exists, but does not automatically prove that its permissions are appropriate or that every action it takes is safe. Microsoft’s announced approach also emphasizes giving agents distinct identities, limiting access to approved tasks, and using signals about agent activity and context to inform controls.

The other major element is task-scoped authority. Rather than letting an agent inherit all of a sponsoring employee’s standing access, Microsoft says an agent should receive its own identity and only the permissions required for the current task, for the duration of that task. The announcement calls this Dynamic Permissions. It describes organization-wide policy as the outer limit, with permissions that can be narrowed or removed as the task changes or ends; higher-impact actions may 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/?trk=public_post_comment-text&utm_source=openai))

How dynamic risk and access controls are intended to work

Traditional access controls are often set when an account or application is configured. That remains important, but an agent’s inputs, working context, and proposed actions can change during a task. Microsoft’s model pairs ongoing observation of activity with risk assessment and control changes. In practical terms, an organization could define what an agent is allowed to do for a task, monitor whether its actions remain within that purpose, and tighten or revoke access when risk increases.

Microsoft gives the example of an expense-approval agent that needs to read submissions, check policy, and approve routine reimbursements. That agent should not automatically receive every permission held by the employee who sponsors it. If it encounters a suspicious instruction or proposes an action outside its task, a response could be proportionate: allow safe read activity to continue while blocking writes, limit the resources available, require human approval for a consequential action, or stop the agent when warranted. This is an illustrative scenario in Microsoft’s announcement, not a guarantee that every deployment will support each response in the same way. ([microsoft.com](https://www.microsoft.com/en-us/security/blog/2026/10/19/agents-are-your-newest-insiders-security-must-move-at-their-speed/?trk=public_post_comment-text&utm_source=openai))

The broader design principle is to enforce policy outside the AI model. An agent may reason about what to do, but independent security controls should determine what it is authorized to access and which actions are permitted. Microsoft’s description spans identity, permissions, data, endpoints, networks, cloud resources, and runtime environments. A registry and risk signals can support visibility; identity and permissions provide points where policy can be applied.

Why local-agent discovery matters

Agents do not all arrive through one centrally managed platform. Teams may adopt tools through development workflows, partner services, or local installations. That can leave security teams with an incomplete inventory, especially when tools are introduced outside a formal deployment process. Expanding discovery to additional local agent types is intended to reduce that visibility gap.

For security teams, the practical value of an inventory is not simply counting agents. It is being able to ask operational questions: Who owns this agent? What business purpose does it serve? Which identity does it use? What data, tools, and systems can it reach? Is it still needed? Are its actions consistent with the approved task? Microsoft says Project Perception and Microsoft Agent 365 share signals, context, and a unified registry, but organizations should confirm the actual integrations and coverage available in their environment. ([microsoft.com](https://www.microsoft.com/en-us/security/blog/2026/10/19/agents-are-your-newest-insiders-security-must-move-at-their-speed/?trk=public_post_comment-text&utm_source=openai))

Discovery can also help establish accountability. A distinct agent identity can make it easier to distinguish actions performed by an agent from actions performed directly by a person. That separation is useful for policy enforcement and investigations, provided identity assignment and activity records are configured and maintained appropriately.

Practical steps for enterprise security teams

Organizations can prepare for agent governance by building a process that does not depend on one product feature alone:

1. Create an agent inventory. Identify centrally managed and locally installed agents, record their owners and business purposes, and establish a review process for newly discovered agents. Treat an inventory as a living record rather than a one-time audit.
2. Assign accountable identities. Where supported, give agents identities distinct from the people who sponsor or use them. Document who is responsible for each identity and how it will be disabled or retired.
3. Map tasks to permissions. For each agent use case, list the specific data, tools, and actions needed. Prefer narrow resource scopes and read-only access where the task allows it. Avoid granting broad standing access simply because it is convenient during setup.
4. Define action limits and approval points. Identify which actions an agent may perform without review and which require a person’s approval. Set explicit limits for writes, external sharing, financial decisions, and changes to important systems.
5. Decide how risk should change access. Establish what signals warrant limiting a tool, blocking a write, asking for approval, or stopping a session. Test those response paths before depending on them in production.
6. Review activity and exceptions. Make sure security and operations teams know where to inspect agent activity, who responds to alerts, and how to investigate actions that fall outside the expected task.
7. Reassess access over time. Review permissions when an agent’s task changes, its owner leaves, a tool is replaced, or the agent is no longer in use. Remove access that is no longer justified.

These steps are governance practices, not a claim that Project Perception automatically performs every one of them. The product’s announced controls still need to fit an organization’s identity architecture, data protections, approval procedures, and incident-response processes.

Limitations and questions to verify

Expanded discovery does not mean every agent in an enterprise will necessarily be detected. Microsoft’s figure describes support for 60 local agent types, not universal visibility into every agent, custom tool, version, or deployment. Teams should validate which agent types and environments are covered and identify any remaining blind spots.

Likewise, dynamic controls depend on the signals available, the policies configured, and the enforcement points connected to the agent’s tools and resources. Risk assessment is not a guarantee that all harmful or out-of-scope behavior will be detected before it happens. Organizations should test policies with realistic workflows and keep human review for decisions where errors could have significant consequences.

Microsoft’s announcement does not provide a complete deployment guide, detailed licensing terms, or a feature-by-feature rollout schedule for the newly described capabilities. Its Microsoft Learn documentation says Project Perception is in Limited Public Preview and cautions that some capabilities may be prerelease. Enterprises should verify current availability, eligibility, supported integrations, and operational requirements with Microsoft before planning a production rollout. ([learn.microsoft.com](https://learn.microsoft.com/en-us/security/agentic-security/recon-agent?utm_source=openai))

Finally, tighter permissions do not remove all AI risks. Agents can still produce incorrect outputs, misunderstand instructions, or be affected by untrusted inputs. Least privilege, monitoring, approval gates, and clear ownership can reduce exposure, but they should complement—not replace—testing, data governance, and incident response.

Frequently asked questions

What is Microsoft Project Perception?

Microsoft describes Project Perception as an agentic security system that brings together security signals and controls to help organizations discover, assess, and govern agents. The October 2026 announcement focuses in part on agents operating inside the enterprise and on adjusting their protections as risk changes.

What does “35 additional local agent types” mean?

Microsoft says it is expanding discovery to 35 additional types of local agents, for a stated total of 60 supported local agents. The announcement lists Claude Code, OpenAI Codex, and GitHub Copilot as examples. It does not claim that every locally installed or custom-built agent will be detected.

What are task-scoped permissions?

Task-scoped permissions give an agent access appropriate to a particular task rather than automatically passing along all of a user’s permissions. Microsoft says the permissions can be time-bound and adjusted or removed as a task changes or finishes, within organization-wide policy limits.

Do dynamic controls guarantee an agent cannot make a harmful decision?

No. They are intended to limit authority and adapt protections as activity or risk changes, but they do not guarantee that every unsafe action will be prevented. Organizations should validate agent outputs, test enforcement, and require human approval for consequential actions where appropriate.

Is Project Perception generally available?

Microsoft Learn currently describes Project Perception as being in Limited Public Preview. Availability and supported capabilities may vary, so organizations should check Microsoft’s current documentation and confirm eligibility before making deployment plans. ([learn.microsoft.com](https://learn.microsoft.com/en-us/security/agentic-security/recon-agent?utm_source=openai))

Bottom line

Microsoft’s Project Perception expansion addresses two foundational needs in enterprise AI security: seeing more locally deployed agents and limiting what each agent can do as its task and risk change. The announcement points toward continuous governance rather than one-time approval. For security leaders, the immediate work is to inventory agents, establish accountable identities, define narrow task permissions, and test how access should change when behavior warrants closer control.