Microsoft Wants to Treat AI Agents Like Insider Risks

Microsoft is changing how it thinks about the AI agents that can read company files, approve expenses and act inside business software. In an October 19 security announcement, the company argues that an agent with workplace access should be treated as a potential insider risk. It does not mean the agent is malicious. It means a mistaken instruction, a compromised tool or an altered plan can cause damage at machine speed.

The new work extends Project Perception, which Microsoft introduced earlier, to supervise agents as they operate. Microsoft says its security stack can identify agents, assign them distinct identities, limit what they can do and change their permissions as their behaviour or context changes. The question for customers is whether those controls work across the many agent tools employees already use, not only within Microsoft’s own products.

A conventional security policy often starts with the employee. But an expense agent may need to read claims and approve routine reimbursements without inheriting every permission of the person who deployed it. Microsoft’s example illustrates the problem: a system that can complete a narrow task should not quietly gain authority to change unrelated records or export sensitive data.

The company says Project Perception and Microsoft Agent 365 will share a registry and risk signals. It is expanding discovery to 60 types of local agents, including Claude Code, OpenAI Codex and GitHub Copilot. Microsoft also says Entra Agent ID will cover more agent patterns, including agents found by security sensors rather than formally registered when created. Discovery is only the first step; a useful control must know who owns an agent, what it is supposed to do and what actions deserve human approval.

Microsoft describes a response to prompt injection in which a system might keep safe read access while blocking writes, narrow the resources an agent can reach, require human approval or stop it entirely. That is a more precise idea than treating every suspicious event as a reason to shut down an entire workflow. It also puts considerable responsibility on the accuracy of the risk signals and policies that decide when to intervene.

An agent can begin with a legitimate request and still encounter hostile text in a document or web page. If it treats that text as an instruction, a one-time permission check at launch will not be enough. Continuous monitoring matters because the agent’s inputs and proposed actions can change while a task is underway. TechBooky has reported cases of agents taking unexpected actions during ordinary information-gathering work, an illustration of why boundaries need to survive contact with real systems.

There are practical questions Microsoft has not settled by announcing an architecture. Security teams will need to measure false alarms, understand why an action was blocked and retain a clear record for audits. Administrators will also want to know how much control remains available when an agent runs on a rival platform. A registry is useful only if it sees enough of the estate to prevent shadow agents becoming a blind spot.

This is also a commercial contest. As enterprises deploy more agents, the company that controls identity, monitoring and approvals may become the default gatekeeper for AI work. Microsoft has an advantage through its existing security and workplace products, but customers should test interoperability rather than assume a single vendor has solved agent risk. The new announcement marks a shift from asking whether agents are productive to asking exactly what they are authorised to do, and who can stop them when that changes.