Microsoft Treats AI Agents as Insiders—Guardian Agents Watch Their Actions

On October 19, 2026, Microsoft announced an expansion of Project Perception to govern enterprise AI agents as insider risks. It introduced Guardian Agents and said discovery would expand by 35 local agent types to 60. The proposed system connects a shared registry, distinct agent identities, limited permissions and changing risk signals to controls over what an agent can do.

Guardian Agents are intended to supervise activity, investigate risk changes and help contain actions within boundaries set by people. In TechCrunch’s account of the launch, Microsoft security executive Hayete Gallot put the concern bluntly: “Unfortunately, frontier models, regardless of their origin, cannot be trusted.” The architecture therefore places access decisions and enforcement outside the model whose behavior is being assessed.

A shared registry gives each agent an accountable identity

Project Perception and Microsoft Agent 365 share signals, context and a unified registry intended to give IT and security teams a consistent view of agents and their risk. Agents can enter that view through platform integrations, connectors or security sensors, including when they were created locally without a central deployment process. Discovery establishes that an agent exists; ownership and activity records make it possible to govern that agent over time.

Microsoft Entra Agent ID provides the identity anchor. The expansion includes identity types for additional agent patterns, including locally discovered and previously unknown agents. That distinction matters because an employee who sponsors an agent and the agent acting on the employee’s behalf need separate attribution, permissions and lifecycle decisions. A registry entry by itself cannot decide whether a particular request should be allowed.

The identity also has to travel with the agent’s requests across applications, tools and other agents. Otherwise, an access system could treat the sponsor’s broad permissions as the agent’s own authority. The proposed arrangement gives policy a specific actor to evaluate before the agent reads data or takes an action.

Permissions and execution boundaries restrict what an agent can do

Dynamic Permissions is designed to grant authority for an approved task and only for the time that task requires. Organization-wide policy sets the outer boundary, including a rule that an agent cannot receive authority its user lacks. Permissions can narrow or expire as the task changes, while a consequential action can require verified human approval.

The runtime and the paths to tools provide separate places to enforce those decisions. A controlled environment such as Microsoft Execution Container can keep observation and policy enforcement outside an agent’s reach. Controls on calls to tools, APIs, data and other agents can inspect both the destination and the content moving through those paths, including sensitive information or untrusted input.

Those are enforcement boundaries: under a configured policy, they can allow or deny a request independently of the model’s own judgment. An agent assigned to process expenses, for example, could have authority to read submissions and approve routine reimbursements without inheriting every permission of the employee who assigned the task. That is an illustration of the proposed design, not a reported deployment result.

Risk signals inform Guardian Agents and policy responses

Dynamic Agent Risk is intended to reassess an agent while it works, using signals from identity, data, endpoints, cloud, network, runtime and the agent’s activity. The assessment considers the resources the agent can reach, the potential effect of an error and whether its actions appear to drift from the task or organizational intent. A change in evidence can therefore change the risk assessment even when the agent’s original configuration stays the same.

Dynamic Conditional Access is the proposed link from that assessment to restrictions at enforcement points. Depending on policy and risk, it could preserve reading while blocking writes, narrow reachable resources, shorten or revoke temporary access, demand human approval, or isolate and stop the runtime. A risk signal interprets behavior; the access boundary applies the resulting restriction. That separation is central to the design because the agent under scrutiny does not get to grant itself permission.

Guardian Agents occupy the supervisory layer. Working through Project Perception playbooks and rules set by people, they are intended to examine why risk changed, investigate evidence, recommend or apply containment and help refine policy. Human operators retain authority over objectives, approval boundaries and consequential decisions. The announcement describes how supervision should work, but does not establish that every unsafe action will be recognized or stopped.

What the controls mean for availability

Microsoft’s Project Perception documentation describes the product as a Limited Public Preview for a small, invitation-only group. That status applies to the documented product; it does not establish that every newly described control is already available to those customers. The expansion gives no general availability date for the complete sequence.

• Inventory: The shared Project Perception and Microsoft Agent 365 registry is part of the described architecture. Expanded local-agent discovery was announced; a release date for each added integration was not specified.
• Identity: Microsoft Entra Agent ID is the policy anchor. Identity types for additional agent patterns were introduced without a stated general availability date.
• Permissions: Dynamic Permissions would limit authority by task and duration. The timing and supported combinations of these controls were not specified.
• Action supervision: Dynamic Agent Risk and Guardian Agents are intended to assess activity and investigate changes. Their effectiveness depends on the evidence available and, for supervision, the agents’ interpretation of it.
• Response: Dynamic Conditional Access and runtime controls are the proposed enforcement path for narrowing access or stopping execution. The full connected path has no stated general availability date.

For administrators, the decisive deployment detail is when a discovered agent can receive an identity that carries through to an enforceable permission change. Until the supported integrations and release dates are specified, the complete control sequence remains an announced design rather than a generally available safeguard.

Also read:

• Google Workspace vs Microsoft 365: Same $7, Very Different Apps
• Reka’s Rho-1 Unifies Video and Robot Actions—but It Is Still a Preview
• Microsoft’s PERM Suspension Blocks a Green-Card Step, Not H-1B Work