Microsoft says its security tools are expanding discovery to 60 types of local AI agents, including Claude Code, OpenAI Codex and GitHub Copilot. The addition covers 35 more types. For teams running agents against company data and business tools, the immediate question is who owns each agent and which actions it can take on someone else’s behalf.
The October 19 announcement pairs that inventory expansion with plans for distinct Entra Agent ID identity types, Dynamic Permissions and risk-responsive Conditional Access for agents. Microsoft frames the problem through an expense-approval assistant: it needs to read claims and approve routine reimbursements, but an agent carrying its sponsor’s full standing permissions can reach much further than that assignment. Microsoft is assessing its own security products here; evaluate the policy at your own tool-call boundary before relying on the announced controls.
An agent needs its own identity
An agent may arrive through a Microsoft platform, a partner SDK or a local installation outside the usual deployment process. Microsoft says native integrations, connectors and sensors feed a shared registry used by Project Perception and Microsoft Agent 365. The registry is intended to associate an agent with its owner, activity and risk. The count of 60 describes supported types of local agent; enumerate the actual agents and credentials in your tenant.
Discovery gives an operations team a place to begin. A separate agent identity lets it attach policy and attribution to the assistant rather than recording every action as the sponsoring employee’s. Microsoft says it is extending Entra Agent ID to cover additional patterns, including local and previously unknown agents discovered through security sensors. That extension is especially relevant where staff install coding assistants locally and then give them access to repositories, files or cloud tools.
The identity only helps when an action path uses it. Inventory identifies the owner; authorization at the tool or API call decides whether the assistant reads an expense or approves it.
A prompt injection changes the task
Microsoft’s expense example makes the timing clear. The assistant starts with authority to review submissions and approve routine claims. It then encounters untrusted content in an external document and attempts an unrelated action. Its original configuration may be unchanged even though the requested action has drifted from the approved task. Agents can make mistakes or be manipulated without being malicious themselves.
Microsoft describes three boundaries around that path. A controlled execution environment such as Microsoft Execution Container keeps the model and harness from inheriting full device privilege. Local, network and data controls mediate calls to tools, APIs, Model Context Protocol servers and other agents, including the content moving through those calls. Dynamic Permissions would assign an agent its own task-scoped, time-bound authority inside an organization-wide policy limit, with human approval for higher-impact actions.
“The employee retains the employee’s access. The agent receives its own identity, permissions and its own authority scoped to its current task and for the duration of the task only,” Microsoft writes. Separate agent permissions let the expense assistant read claims without granting the employee’s unrelated access.
Microsoft says Dynamic Agent Risk would combine identity, data, endpoint, cloud, network, runtime and agent-activity signals. Dynamic Conditional Access could then preserve reads while removing approval or write authority, narrow resource and network access, demand human approval, or stop the agent. Before relying on these proposed controls, determine which ones enforce decisions on the agent and tool path in your environment.
Put approval behind the tool call
Start with the agents that can write business records, invoke tools or approve transactions. For the expense assistant, identify its owner and separate identity, the resources it can read, its approval or write grants, the permitted task duration and the human approver for consequential steps. Compare those grants with the permissions of the sponsoring employee. If the assistant inherits access to other business systems, narrow its credential and tool grants to the expense workflow and put the approval decision in a system the agent cannot alter.
Next, inspect how a call crosses from agent to tool. Record the agent identity, destination, requested action and policy decision at the tool-call authorization point where your instrumentation permits it; use those records to investigate an unexpected write attempt. Reconcile local installations with the tools and credentials they use, including agents absent from the registry.
The NIST AI Risk Management Framework is a voluntary approach to risk management across the design, use and evaluation of AI systems. It gives a governance reason to assign owners and re-evaluate authority, independent of Microsoft’s product claims. The actual decision still belongs at each organization’s identity, data and tool boundary.
Test the agent’s approval boundary
For an enterprise running an expense or similar action-taking agent, remove standing permissions unrelated to its task, set a short grant duration and require human approval for a consequential write. Then use a controlled, authorized test account and a non-production expense claim: request a permitted read and an out-of-scope approval. The expected policy result is a successful read and a denied approval, with the agent identity and decision visible in the enforcement record. Use that local test to decide whether your implementation enforces the policy.
If the same employee credential still approves the out-of-scope claim through another tool path, fix that path before extending the agent’s access. A registry count tells you what the product can discover; the blocked write tells you what actually governs the work.