Reference
Policies for Microsoft Agent 365
See the Microsoft Agent 365 inventory reference for the objects these templates work on.
| Policy | Description | Severity | Category | Checks |
|---|---|---|---|---|
| Active Identity With a Disabled Agent User ⭐ | Flags enabled agent identities whose linked agent user account has been disabled - a half-decommissioned agent. An agent identity is bound one-to-one to its agent user. When the agent user account is disabled but the identity is still enabled, the agent is half-decommissioned: the identity can still be issued tokens and act through application permissions even though its user-facing account (mailbox, Teams presence) was turned off. Either re-enable the agent user if the agent is still needed, or disable the identity to complete the decommission. | Medium | Operation | Agent Identity |
| Blueprint credential expiring within 30 days (likelihood) ⭐ | Risk-probability factor: a credential approaching expiry raises the likelihood of an outage or unsafe hot-rotation. A passwordCredential or keyCredential expiring within 30 days raises the likelihood of either an outage (rotation missed) or a hot-rotation under pressure that bypasses normal change-control. Either failure mode is materially more probable in the rotation window. | Medium | Operation | Agent Blueprint |
| Blueprint has no owners (likelihood) ⭐ | Risk-probability factor: blueprints without an owner have no accountability surface, raising the likelihood of unnoticed drift. A blueprint with no owners has no accountability for its child identities' credentials, permissions, or lifecycle. The unowned state raises the likelihood that drift, expired credentials, or stale permissions go unnoticed. | High | Security | Agent Blueprint |
| Blueprint uses password credential (likelihood) ⭐ | Risk-probability factor: blueprints with at least one passwordCredential are materially more likely to suffer a credential leak than federated-only blueprints. Blueprints with passwordCredentials carry plaintext secrets that can leak via logs, env files, and developer machines. Federated identity credentials rotate automatically and never appear in plaintext, so a blueprint still using a client secret has a materially higher likelihood of credential exposure than a federated-only blueprint. | High | Security | Agent Blueprint |
| Identity is active (likelihood) ⭐ | Risk-probability factor: agent identities that are enabled and not disabled by Microsoft are reachable and therefore carry baseline likelihood for latent risks to surface. A blocked or Microsoft-disabled agent identity cannot manifest a problem - it has no operational surface. An active identity (AccountEnabled = true and not disabled by Microsoft) is reachable and therefore carries baseline likelihood for any latent risk to materialise. | Medium | Security | Agent Identity |
| Identity holds 5+ application permissions (likelihood) ⭐ | Risk-probability factor: a broad set of application permissions widens the attack surface and increases the likelihood that one of them is misused. An identity granted five or more application permissions (appRoleAssignments) has a wide attack surface - each granted scope is a separate pathway through which a compromise could escalate. Split from delegated grants so the two can be tuned independently. | Medium | Security | Agent Identity |
| Identity holds 5+ delegated permissions (likelihood) ⭐ | Risk-probability factor: a broad set of delegated permissions widens the on-behalf-of attack surface. An identity granted five or more delegated permissions (oauth2PermissionGrant scopes) has a wide on-behalf-of surface. Each scope is a separate pathway that can be invoked on behalf of users; a higher count raises the likelihood that one is misused. | Medium | Security | Agent Identity |
| Identity has a deactivated owner or sponsor (likelihood) ⭐ | Risk-probability factor: an identity whose owner or sponsor account is disabled has no functioning oversight, raising the likelihood that drift or misuse goes unnoticed. An identity whose owner or sponsor has a disabled Microsoft Entra account has lost its functioning human oversight: nobody is watching for drift, expired credentials, or stale permissions, and access-review escalations route to an account that can no longer act. That unwatched state raises the likelihood that a latent issue goes unnoticed until it becomes an incident. Mirrors the Policy check on the impact axis. | Medium | Security | Agent Identity |
| Microsoft-disabled identity still enabled (likelihood) ⭐ | Risk-probability factor: an identity Microsoft flagged but the tenant left enabled is both suspected and reachable, the highest-likelihood state for an incident to surface. Microsoft disables an agent identity (DisabledDueToViolationOfServicesAgreement) only after detecting suspicious, abusive, or malicious activity, or a Services Agreement violation. If the tenant has not also disabled the account, the identity is both Microsoft-suspected and still reachable for token issuance - the single highest-likelihood state an agent identity can be in. Mirrors the Policy check on the impact axis. | High | Security | Agent Identity |
| Identity has no owners (likelihood) ⭐ | Risk-probability factor: identities without a registered owner have no accountability, so misuse or drift goes unnoticed. An identity with no owners has no one technically accountable for its credentials, permissions, or lifecycle. Misuse goes unnoticed and unrotated, materially raising the likelihood that a latent issue surfaces. Mirrors the existing Policy check on the impact axis. | High | Security | Agent Identity |
| Custom-built agent package (likelihood) | Risk-probability factor: custom-built agents skip vendor-grade vetting, modestly raising the likelihood of latent issues in declared behavior, data access, or prompt safety. Custom-built agents are typically authored by individual employees or small teams and rarely go through vendor-grade vetting. Their declared behavior, data access, and prompt safety have a higher likelihood of containing latent issues than vendor-published packages. | Low | Operation | Agent |
| Agent package is not blocked (likelihood) ⭐ | Risk-probability factor: agent packages that are not blocked are usable by end users, so any latent risk in the agent carries baseline likelihood of surfacing. A blocked agent package cannot be installed or used by end users, so any latent risk in the agent has no path to manifest. A package that is NOT blocked carries baseline likelihood for its declared risks to surface - directly mirroring the user framing 'when an agent is blocked, the likelihood of a problem is low; if not, it is higher.' | Medium | Security | Agent |
| High-privilege permission scope (likelihood) ⭐ | Risk-probability factor: high-privilege scopes (.ReadWrite.All, .FullControl.All, .Write.All, Mail.Send, Directory.ReadWrite*, RoleManagement.ReadWrite*) carry elevated likelihood of broad impact when any agent holds them. A permission scope being high-privilege - tenant-wide writes, full control, role management, message send - means any agent holding it carries elevated likelihood of broad blast radius. Surfacing this on the Permission entity makes critical scopes show up as high-likelihood rows in the Agent Permission inventory, so reviewers can drill into 'which agents hold this' from the Portal. | High | Security | Agent Permission |
| Agent user is enabled (likelihood) ⭐ | Risk-probability factor: enabled agent user accounts can sign in and act across workloads, so latent issues are likelier to manifest. An agent user account that is enabled is reachable for sign-in and can act in Teams, Exchange, and other workloads. A disabled account cannot, so the likelihood of an active problem is materially lower when the account is disabled. | Medium | Security | Agent User |
| Agent user is a Guest (likelihood) ⭐ | Risk-probability factor: Guest-type agent users introduce external-identity provenance into agent automation, raising the likelihood of cross-tenant exposure. An agent user with UserType = Guest is an externally-sourced identity acting as an agent. The combination of external identity provenance with agent automation raises the likelihood of cross-tenant data exposure or rogue automation. | High | ExternalAccess | Agent User |
| Agent user has no manager (likelihood) ⭐ | Risk-probability factor: an agent user without a manager has no auto-cascade target for sponsorship, raising the likelihood of orphaned permissions. Microsoft Entra Agent ID's sponsor model auto-cascades responsibility to the manager when a sponsor leaves. An agent user with no manager has slipped that safety net, raising the likelihood that the account stays active past its useful lifespan. | Medium | Operation | Agent User |
| Agent Missing Publisher ⭐ | Flags agents that have no publisher recorded in the agent registry, making accountability and escalation impossible. Agents without a recorded publisher cannot be attributed back to a responsible owner or vendor. When something goes wrong - data exposure, hallucinations, broken actions - there is no one to escalate to. Block the agent or contact the creator and require a publisher value before allowing re-enablement. | Medium | Operation | Agent |
| Agent User Has a Deactivated Sponsor or Manager ⭐ | Flags agent users whose sponsor or manager has a disabled Microsoft Entra user account, breaking the sponsorship-continuity chain. Sponsorship of an agent user auto-transfers to the sponsor's manager when the sponsor leaves, so both the sponsor and the manager are part of the human-oversight chain. When a sponsor's account is disabled, that oversight is gone; when the manager's account is disabled, the auto-transfer has no valid target. Reassign the sponsor, or update the manager, to an active user so sponsorship continuity is preserved. | Medium | Operation | Agent User |
| Agent User Has No Sponsors ⭐ | Flags agent user accounts that have no sponsors registered. Microsoft Entra Agent ID requires every agent identity - and the agent user attached to it - to have an accountable human sponsor responsible for its lifecycle and access decisions. Sponsorship is the entry point for identity governance: access-package expiry escalations and entitlement-management approvals route to the sponsor, and sponsorship auto-transfers to the sponsor's manager when they leave. An agent user with no sponsor has slipped that safety net. Assign a sponsor. | High | Operation | Agent User |
| Agent User Is a Guest ⭐ | Flags agent user accounts whose UserType is Guest, introducing external-identity provenance into agent automation. Agent users already run with permissions similar to a guest user. An agent user whose UserType is Guest layers external-identity provenance on top of agent automation, which broadens the cross-tenant data-exposure surface. Confirm the agent genuinely needs an external identity; otherwise recreate it as a Member agent user, and review the access packages and group memberships granted to it. | High | ExternalAccess | Agent User |
| Blocked Agent Still Deployed ⭐ | Flags agents that are blocked in the agent registry but still appear deployed to users, indicating that the block is not being enforced. Agents marked as blocked in the Microsoft 365 agent registry should not remain deployed to users. A blocked agent that still shows as deployed indicates either a stale block decision that was never followed up on, or a configuration drift that bypasses the block. Review the block reason with the agent owner, confirm whether the block should stand, and remove the deployment so the block actually takes effect for end users. | High | Security | Agent |
| Blueprint Credential Expiring Within 30 Days ⭐ | Flags agent identity blueprints with at least one passwordCredential or keyCredential expiring in the next 30 days. A passwordCredential or keyCredential on the blueprint expires soon. When it expires, every child agent identity loses authentication. Rotate the credential ahead of time, or - preferred - migrate to a federatedIdentityCredential which has no expiry. | Medium | Operation | Agent Blueprint |
| Blueprint Has a Deactivated Owner or Sponsor ⭐ | Flags agent identity blueprints whose owner or sponsor has a disabled Microsoft Entra user account. Owners hold technical accountability for a blueprint (credentials, permissions, incident response) and sponsors hold business accountability for its lifecycle. When an owner's or sponsor's Microsoft Entra account is disabled, that accountability is no longer functional - drift, expired credentials, and stale permissions on the blueprint and all of its child identities go unwatched. Reassign the owner or sponsor to an active user. | Medium | Operation | Agent Blueprint |
| Blueprint Has No Owners ⭐ | Flags agent identity blueprints that have no owners registered in the owners collection. Without registered owners, no one is technically responsible for the blueprint. Owners control credentials, permissions, and lifecycle; without them, the blueprint is effectively unmanaged. Assign at least one owner. | High | Operation | Agent Blueprint |
| Blueprint Has No Sponsors ⭐ | Flags agent identity blueprints that have no sponsors registered in the sponsors collection. Sponsors are accountable for the blueprint's lifecycle and access reviews. Microsoft Entra Agent ID's sponsor model auto-transfers sponsorship to the sponsor's manager when they leave; a blueprint with no sponsors has slipped that safety net. Assign at least one sponsor. | Medium | Operation | Agent Blueprint |
| Multitenant Blueprint Without a Verified Publisher ⭐ | Flags multitenant-capable agent identity blueprints that have no verified publisher recorded. Publisher verification is the signal Microsoft surfaces so admins can tell whether a multitenant app comes from a developer they trust; admins can even gate consent on it. A multitenant-capable agent identity blueprint (signInAudience allows multiple orgs) with no verified publisher is an externally-sourced agent template whose publisher Microsoft has not confirmed. Confirm the blueprint's provenance with the vendor and require publisher verification, or restrict the blueprint to single-tenant use. | Medium | ExternalAccess | Agent Blueprint |
| Blueprint Uses Password Credential ⭐ | Flags agent identity blueprints that have at least one passwordCredential. Federated identity credentials are preferred for production agents. passwordCredentials (client secrets) must be rotated on a recurring schedule and can leak through logs, env files, or developer machines. Microsoft's guidance for agent blueprints is to use federatedIdentityCredential, which rotates automatically and never appears in plaintext. Migrate the blueprint off password credentials. | Medium | Security | Agent Blueprint |
| Custom Agent Deployed Tenant-Wide ⭐ | Identifies custom-built agents that are deployed to every user in the tenant, where individual-author agents may not have gone through the same review as vendor apps. Custom-built agents are typically created by individual employees or small teams and rarely go through the same vetting as vendor-published apps. A custom agent deployed to every user in the tenant should be re-evaluated to confirm it has been reviewed for data access, action surface, and prompt safety before scaling. | Medium | Operation | Agent |
| Microsoft-Disabled Blueprint Has Active Identities ⭐ | Flags blueprints disabled by Microsoft that still have linked agent identities. An agent identity blueprint that Microsoft has disabled (DisabledByMicrosoftStatus == DisabledDueToViolationOfServicesAgreement) should not still have linked agent identities. Investigate why Microsoft disabled the blueprint and reconcile its child identities. | High | Security | Agent Blueprint |
| External-publisher Agent Available to All Users ⭐ | Identifies external-publisher agents that every user in the tenant can find and install, which is a common oversharing pattern after a broad initial enablement. Agents from external publishers that are available to every user in the tenant expand the surface area for data exposure and unvetted behavior. Review whether the agent has been certified, whether its publisher is trusted, and restrict availability to a smaller pilot group until a formal review has been completed. | High | ExternalAccess | Agent |
| Microsoft-Disabled Identity Still Enabled ⭐ | Flags agent identities that Microsoft disabled (DisabledDueToViolationOfServicesAgreement) but whose account is still enabled in the tenant. Microsoft sets DisabledByMicrosoftStatus = DisabledDueToViolationOfServicesAgreement when it disables an agent identity for suspicious, abusive, or malicious activity, or a Services Agreement violation. The tenant should also turn off the account (AccountEnabled = false). An identity that Microsoft flagged but the tenant left enabled is a live, Microsoft-suspected identity that can still be issued tokens until your tenant disables it. Disable the account in the Microsoft Entra admin center and investigate the cause before re-enabling. | High | Security | Agent Identity |
| Identity Has a Deactivated Owner or Sponsor ⭐ | Flags agent identities whose owner or sponsor has a disabled Microsoft Entra user account. An agent identity's owner is accountable for its credentials and permissions; its sponsor is accountable for its lifecycle and access reviews. When that owner or sponsor has a disabled Microsoft Entra account, the identity has lost its functioning human oversight - the access-review and incident-response paths point at an account that can no longer act. Reassign the owner or sponsor to an active user. | Medium | Operation | Agent Identity |
| Identity Has No Owners ⭐ | Flags agent identities that have no owners registered. An agent identity with no owners has no one technically responsible for it. Owners control credentials, permissions, and lifecycle. Assign an owner before allowing the identity to run in production. | High | Operation | Agent Identity |
| Identity Has No Sponsors ⭐ | Flags agent identities that have no sponsors registered. Orphaned agent identities - those with no sponsor - skip the access-review process that keeps agent permissions in check. Assign a sponsor immediately. | High | Operation | Agent Identity |
| Shadow AI agent detected on managed devices ⭐ | Flags unapproved AI tools and agents detected on Intune-managed devices. Unmanaged AI tools installed on managed devices are active data-egress channels: they can transmit corporate content, code, or PII to an external service without data-loss-prevention controls or auditability. Confirm whether each tool is sanctioned; if it is, mark it approved to stop flagging it. If it is not, block its execution on managed devices and contact the user. | Medium | Security | Shadow AI Agent |
| Shadow AI: agentic AI CLI detected ⭐ | Flags unapproved local agentic AI CLIs and coding agents on managed devices - the highest-risk shadow AI class. Agentic AI CLIs and local coding agents (OpenClaw, Claude Code, GitHub Copilot CLI, Aider, Cline) run on the endpoint with broad filesystem, shell, and network access. They can autonomously read source code and local files, execute commands, and send that content to an external model provider with little visibility - the exact scenario Microsoft surfaces as Shadow AI. Treat these as high risk: confirm sanctioning, restrict to approved users, and block execution on managed devices where they are not approved. | High | Security | Shadow AI Agent |
| Unused Blueprint ⭐ | Flags agent identity blueprints that have no linked agent identities. A blueprint with zero linked identities is consuming OAuth client credentials and policy slots without delivering value. Either delete the blueprint or create the intended identities. | Low | Operation | Agent Blueprint |