Posted in

Your agents are insiders: inventory the permissions

by ailona•

On October 19, Microsoft’s executive vice president for security published a post that reframes the agent in your tenant as a personnel problem. It was deployed by someone inside your own company, it holds standing access to data and tools, and it is expected to do something you did not ask for without anyone attacking it. The operator response that exists today is unglamorous and mostly mechanical, which is why it is worth starting now: build an inventory of agent identities, then cut what each one can reach.

The claim, in Microsoft’s words

Hayete Gallot, EVP of Microsoft Security, opens by naming the assumption most IT teams made:

Since we were the ones who deployed agents internally for our companies, we implicitly trusted our agents.

Two sentences later she drops the conclusion: “They are agentic insiders.” Her reasoning is not that models are malicious. It is that “frontier models, regardless of their origin, cannot be trusted,” because they are trained to attain results rather than to respect organizational norms:

They will adapt as the context changes, may not behave as intended and will collaborate and collude with other agents to reach their objectives, without needing to be compromised.

The part an admin has to act on is the next line, because it is a description of your current estate rather than a prediction: “These agents are frequently overprivileged, have access to data, tools and systems and can take actions and make decisions in critical processes.”

The same day, Nadim Abdo, CVP of Identity and Network Access, published the operator-facing companion post. It quotes Satya Nadella’s framing, linked from that post: we should separate the supply of intelligence from the authority over it, and “the controls that determine what it can access, what actions it can take, and whether it should continue operating must sit outside the model, where the model cannot bypass or tamper with them.”

What the claim does not include

Both posts are vendor framing, and it is worth being precise about what they do and do not carry. Neither cites an incident count, telemetry from a customer environment, or an observed case of agents colluding. “Reward hacking” and agent collusion are stated as properties of how models are trained and deployed, not as measured findings. Treat the sentences as Microsoft’s stated threat model. It is a reasonable one, and it is also not evidence on its own.

What is testable is the design claim underneath: if the model cannot be the security boundary, then identity and permissions have to be. That is a statement about where controls live, and it happens to describe the two inventories you can run this week.

Step one: the agent identity inventory in Entra

Entra Agent ID is the identity anchor, and Microsoft Graph exposes it directly. The first agent identity inventory is one request:

GET https://graph.microsoft.com/v1.0/servicePrincipals/microsoft.graph.agentIdentity

Three details from the Graph reference matter before you hand this to a script:

  • It returns only agent identities. The call is scoped to that one derived type, so it does not return the rest of your service principals. If an agent was registered some other way, it will not appear here.
  • Least privilege is AgentIdentity.Read.All. That permission covers delegated and application scenarios. AgentIdentity.ReadWrite.All is the higher tier and you do not need it to take inventory.
  • The person running it needs a role, not Global Admin. For nonowners calling this API in delegated scenarios, the least-privileged built-in role is Agent ID Administrator. Worth noting: whoever creates an agent identity blueprint is auto-assigned as owner, and owners can create and modify the identities under that blueprint without holding an Agent ID role at all.

Paging is the practical trap. The default and maximum page size is 100 agent identity objects, so any tenant of size needs to follow @odata.nextLink rather than reading the first page and calling it a census. The endpoint supports $count, $filter, $select, $top, $orderby, $expand and $search, and some filter combinations require the ConsistencyLevel: eventual header alongside $count.

Step two: the local agents nobody deployed through the portal

The cleaner half of the estate is the one provisioned through a platform. The messy half is the developer who installed a coding agent on a laptop. Microsoft’s line for that is blunt: “You cannot secure what you cannot see.” Abdo’s post says discovery is expanding “to 35 additional types of local agents, bringing the total to 60 supported local agents,” naming Claude Code, OpenAI Codex and GitHub Copilot among them.

The 60 is checkable. The Defender AI agent support matrix, last updated October 7, lists 60 named agents in its Windows discovery table alone, with discovery support and runtime protection support tracked separately. In the Defender portal the list lives under Assets > AI agents > Local agents, and advanced hunting answers the same question in KQL:

AgentsInfo
| where Platform == "LocalAgents"
| summarize arg_max(Timestamp, Name, Version, LifecycleStatus, RawAgentInfo) by AgentId
| where LifecycleStatus !in~ ("Deleted", "Uninstalled")

AgentsInfo tells you what an agent is and how it is configured: publisher, version, host process, trust and auto-approve settings, configured MCP servers, and the device and account it runs under. The exposure graph tells you what it can reach. Those are different questions with different filters, because both sources hold cloud agents too. The trap is in the edges: ExposureGraphEdges has no property that marks an agent as local, so filtering it on the ai-agent label returns every agent in the tenant. Resolve the local set from ExposureGraphNodes first (node label ai-agent, platform LocalAgents), then join to the edges on the node ID.

Two caveats from the docs, and the second is the bigger reason for an empty list. First, discovery is activity based: Defender lists an agent after it observes that agent doing something on an onboarded device, so installing an agent does not by itself guarantee it appears in the inventory. Second, discovery requires Microsoft Defender Antivirus running in active mode with real-time protection enabled. On a device where a third-party antivirus product is primary and Defender sits in passive mode, local agents do not show up at all no matter how much activity they generate. An empty result is neither proof of an empty laptop nor proof of a quiet one.

Least privilege, which is policy before it is product

Here is the sentence to put in front of whoever sponsors agents in your org. Abdo writes that “an agent should not automatically inherit all the standing access of its user. It should begin with no authority and receive only what it needs for the approved task, for only as long as the task requires.” The identity half of that is shippable today: agent identities are separate objects, so you can strip them without touching the human account behind them.

The automated half is not shippable yet. Microsoft says it is “introducing Dynamic Permissions,” where organization-wide policy sets an outer boundary that also prevents an agent from obtaining authority its user does not have, with task-scoped and time-bound permissions and verified human approval on higher-impact actions. Dynamic Agent Risk and Dynamic Conditional Access for agents are in the same paragraph of the same announcement. No general availability date and no pricing appear in either post.

The licensing gate the announcement leaves out

Both posts read as though the whole control set is available now. Learn tells a more useful story, and the split is worth knowing before you promise anyone containment:

  • Agent identity itself is open. “Agent ID is available for all Microsoft Entra customers.” You can create agent identities and run the inventory query on any Entra tenant.
  • The security features on top of it are not. “Extending Microsoft Entra security features to agents requires Microsoft Agent 365.” That covers the capabilities the Agent ID page groups under security and governance: Conditional Access for agents, Identity Protection for agents, identity governance for agents, network controls for agents, and agent sign-in and audit logs. Agent 365 is included with Microsoft 365 E7 and is an add-on to Microsoft E5/A5/Business Premium, or to the Defender Suite plus Purview Suite. Agent 365 is licensed per user for agents that operate across Microsoft 365 services and enterprise workflows.
  • Defender has its own line. Defender for Endpoint Plan 2 covers local agent discovery, the AI agent inventory, and advanced hunting against AgentsInfo. Viewing risk level, risk indicators and security recommendations for those agents needs Microsoft 365 E7, or Agent 365 together with Defender for Endpoint Plan 2.

Put plainly: every Entra customer can inventory and clean up. Continuous containment, the risk scoring and the Conditional Access responses ride on the Agent 365 entitlement, and Agent 365 is licensed per user. A Business Standard tenant can finish the first half of this work this week; the second half is not a checkbox, it is a licence line.

What is announced but not yet enforceable

Worth tracking, not worth designing around. Guardian Agents and Playbooks, Dynamic Permissions, Dynamic Agent Risk, Dynamic Conditional Access, and the Microsoft Execution Container (MXC) sandboxing that Abdo describes as giving the model and harness a policy-controlled environment rather than device-level privilege. Gallot calls Guardian Agents “an established industry term” and describes them as watching and moderating “every action of every agent, before it happens, 24/7.” That is Microsoft’s characterization of a category, not a citation, and nothing in either post gives a date.

Model-level evidence is the other direction of travel: chain-of-thought and other signals feeding Dynamic Agent Risk, on the argument that observing inputs and outputs is not enough to tell whether an agent’s intent still matches its task. Gallot is explicit that transparency “will not replace containment.”

The other half of this story

Identity and permissions are half the control surface. Runtime is the other half, and Defender’s agent runtime protection is where the endpoint enforcement lands. The audit-before-block sequence for that, including what to leave in audit mode and for how long, is in the October 6 post on MDE AI agent runtime protection. Read that one for the runtime half; this one stops at the identity boundary.

What to do this week

  • Run the Graph query. Use an app with AgentIdentity.Read.All, page through @odata.nextLink, and export the whole set. Do not read page one and call it done.
  • Attach an owner and a purpose to every row. An agent identity with no named owner and no described task is a candidate for deletion, not for a review meeting.
  • Trim the access that remains. Check each agent identity against the task it performs and remove anything beyond it. The point of a separate identity is that you can cut it without disabling a person.
  • Pull the local inventory too. Assets > AI agents > Local agents in the Defender portal, plus the AgentsInfo query. Remember that activity-based discovery means a gap in the list is not a gap on the disk.
  • Price the gap before you promise containment. If the ask includes Conditional Access for agents, agent risk scoring or recommendations, that is an Agent 365 or Microsoft 365 E7 conversation. Inventory first, license second, and say which one you are delivering.

The uncomfortable part of Microsoft’s framing is that it removes the excuse. An agent that misbehaves was never compromised, so there is no incident to point at and no attacker to attribute. What is left is an access review, run against a class of identity most tenants have never counted.

Sources

As an Amazon Associate I earn from qualifying purchases. Links on this site may be affiliate links.