Agent 365: Governance and Security · 1 of 5
The Agents-at-Risk Model
The Agents-at-Risk model turns thousands of agent signals into a ranked list of identity, ownership, and permission failures needing action.
A mature agent program can still drown its operators. The registry may be complete, identities may be issued, data controls may be active, and threat detection may be switched on, yet the morning question remains simple: which agents need attention now? The Agents-at-Risk model answers that question by turning many security signals into a short, ordered view of the agents most likely to cause harm if left alone.
The problem is not visibility; it is prioritization
Large organizations can accumulate thousands of software agents. Some are built into productivity tools, some are created by developers, some are deployed by business teams, and some appear through experimentation before governance catches up. A registry helps answer what exists. Identity helps answer what each agent is. Access control helps answer what each agent can reach. None of those, by itself, tells a security team what to look at first.
That distinction matters. Monitoring every agent equally sounds thorough, but in practice it produces fatigue. A team that treats a harmless, well-owned scheduling agent the same as an unregistered agent with broad access is not being careful; it is failing to allocate attention where the risk is highest.
The Agents-at-Risk model is a triage model. It does not replace the registry, identity controls, data protection, or threat detection. It sits above them and asks a narrower operational question: among all the agents being observed, which ones show the most serious missing safeguards today?
What administrators see in Microsoft 365
In the Microsoft 365 admin center, the Agents at Risk card appears on the Overview page. It gives administrators a tenant-wide summary of agents with the most severe risks and immediately surfaces the top three most at-risk agents. That small design choice is important: the first screen is not an inventory dump, but a ranked prompt for action.
From the card, an administrator can select View agents and land in the All agents Registry page with the view already filtered and sorted by risk level. In other words, the interface carries the operator from summary to investigation without making them rebuild the filter manually.
This is the practical value of the card. It shortens the distance between detection and decision. Instead of checking several consoles, exporting lists, comparing rows, and then deciding what matters, the administrator starts from a pre-prioritized registry view.
One ranked view from three security systems
The risk view is built by aggregating signals from Microsoft Entra, Microsoft Purview, and Microsoft Defender. Microsoft Entra contributes identity and access context. Microsoft Purview contributes data protection and governance context. Microsoft Defender contributes threat and behavior context.
That combination is the point. An agent can look acceptable from one angle and worrying from another. An identity system may show that the agent exists and has permissions. A data system may show that the agent touches sensitive information. A threat system may show unusual behavior or permission patterns. The risk becomes clearer when these signals are considered together.
The administrator does not have to manually reconcile three separate views to decide whether an agent deserves attention. The model aggregates the relevant signals into a single risk-based ordering so the most urgent agents rise to the top.
The three Critical risk types
The model highlights three risk types at Critical severity. Each one represents a basic safeguard that is absent or has failed.
A shadow agent is an agent with no registry entry, no owner, or no Microsoft Entra Agent ID identifier. This is the dangerous form of agent sprawl: an actor that is not properly known, not clearly accountable, or not represented by the expected identity foundation.
No owner assigned means the agent has no owner or sponsor recorded. This can happen even when the agent is otherwise visible. The risk is not that the agent is invisible, but that nobody is clearly responsible for reviewing it, justifying it, and fixing it when it misbehaves.
Excessive permissions means the agent appears to hold more access than its role requires. This risk is detected using signals from Microsoft Entra and Microsoft Defender together. It is the classic least-privilege problem applied to non-human identities: the agent may be doing a narrow job while carrying broad authority.
- Shadow agent: no registry entry, no owner, or no Microsoft Entra Agent ID identifier.
- No owner assigned: no owner or sponsor is on record for the agent.
- Excessive permissions: the agent holds more access than its role appears to justify, using Microsoft Entra and Microsoft Defender signals.
Why these risks are more alike than they look
The three Critical risks are not random. They are different expressions of the same governance failure: a missing basic control.
The shadow agent is missing a reliable identity and registration path. The unowned agent is missing accountability. The over-permissioned agent is missing restraint. In each case, the organization has lost one of the anchors that makes an agent governable.
This is why the model is useful even though the labels are simple. It does not chase obscure edge cases first. It looks for the conditions that make ordinary incidents harder to contain: not knowing the actor, not knowing the accountable person, or giving the actor too much reach.
The decisions this model should change
For leaders, the Agents-at-Risk view helps turn governance from a policy slogan into an operating rhythm. It supports questions such as: Are our riskiest agents concentrated in one business unit? Are owners missing because teams do not understand the requirement, or because the registration process is too hard? Are excessive permissions the result of one bad integration pattern repeated many times?
For practitioners, the ranked list helps decide what to fix first. A shadow agent may need discovery, registration, identity assignment, or removal. An unowned agent may need an accountable sponsor before any further expansion is approved. An over-permissioned agent may need an access review, a narrower role, or a redesign of how it calls downstream systems.
The model also helps avoid a common mistake: treating all findings as tickets of equal weight. The top of the list should drive immediate remediation. Lower-risk findings may still matter, but they can be handled through normal backlog, periodic review, or policy improvement.
How to work the list without creating busywork
A healthy process begins with review, but it should not end there. The team should confirm why each agent was flagged, assign the right remediation path, make the change, and then check whether the same pattern is appearing elsewhere.
For shadow agents, the fix is not merely to acknowledge the finding. The agent must be brought into the registry and identity model or be removed. For missing owners, the fix is not a placeholder name; it is a person or group with enough authority to make lifecycle and access decisions. For excessive permissions, the fix is not just a one-time permission cut; it is a check on the design pattern that produced the overreach.
Over time, the goal is not to celebrate a dashboard full of red indicators. The goal is to make the Agents-at-Risk list shorter and less surprising. If the same category keeps returning, the organization has found a process defect, not just an agent defect.
Key takeaways
- The Agents-at-Risk model is a prioritization layer for large agent populations, not a replacement for the underlying controls.
- The Agents at Risk card in the Microsoft 365 admin center surfaces a tenant-wide view and highlights the top three most at-risk agents.
- Risk severity is aggregated from Microsoft Entra, Microsoft Purview, and Microsoft Defender so administrators do not have to combine those views manually.
- The three Critical risks are shadow agent, no owner assigned, and excessive permissions.
- Each Critical risk is a missing basic safeguard: identity, accountability, or least privilege.
- A useful operating process fixes the individual agent and also looks for the repeated pattern that caused the risk.
Glossary
- Agent
- A software actor that can perform tasks, call systems, or handle information on behalf of a user, team, or process.
- Agents at Risk card
- A Microsoft 365 admin center Overview page card that summarizes the highest-severity agent risks across a tenant.
- Agent registry
- The authoritative catalog used to list and manage agents known to the organization.
- Aggregated risk
- A combined risk view built from signals across more than one security or governance system.
- Critical severity
- The highest severity rating used for the most urgent agent risk findings in this model.
- Microsoft Entra Agent ID identifier
- The identity foundation used to represent an agent in Microsoft Entra so it can be governed as a known non-human identity.
- Shadow agent
- An agent with no registry entry, no owner, or no Microsoft Entra Agent ID identifier.
- Least privilege
- The practice of giving an agent only the access it needs to perform its intended job and no more.
- Excessive permissions
- A risk condition in which an agent appears to have more access than its role requires.