From 4ccd9e85bb41c2b1bdc00dfe22cb3f34b348ddde Mon Sep 17 00:00:00 2001 From: Anton Staykov Date: Tue, 21 Jul 2026 14:46:12 +0200 Subject: [PATCH 1/2] Update recommendations, release 2.5.0 --- src/powershell/tests/Test-Assessment.21844.md | 2 +- src/powershell/tests/Test-Assessment.25375.md | 4 +-- src/powershell/tests/Test-Assessment.61006.md | 17 +++++++---- src/powershell/tests/Test-Assessment.61008.md | 22 +++++++++------ src/powershell/tests/Test-Assessment.61009.md | 17 +++++++---- src/powershell/tests/Test-Assessment.61011.md | 18 +++++++----- src/powershell/tests/Test-Assessment.61012.md | 17 +++++++---- src/powershell/tests/Test-Assessment.61013.md | 28 ++++++++++--------- src/powershell/tests/Test-Assessment.61014.md | 22 +++++++-------- 9 files changed, 88 insertions(+), 59 deletions(-) diff --git a/src/powershell/tests/Test-Assessment.21844.md b/src/powershell/tests/Test-Assessment.21844.md index 869f7e8403..aeb89d023f 100644 --- a/src/powershell/tests/Test-Assessment.21844.md +++ b/src/powershell/tests/Test-Assessment.21844.md @@ -1,6 +1,6 @@ Threat actors frequently target legacy management interfaces such as the Azure AD PowerShell module (AzureAD and AzureADPreview), which don't support modern authentication, Conditional Access enforcement, or advanced audit logging. Continued use of these modules exposes the environment to risks including weak authentication, bypass of security controls, and incomplete visibility into administrative actions. Attackers can exploit these weaknesses to gain unauthorized access, escalate privileges, and perform malicious changes. -Block the Azure AD PowerShell module (appID: 1b730954-1685-4b74-9bfd-dac224a7b894) and enforce the use of Microsoft Graph PowerShell or Microsoft Entra PowerShell to ensure that only secure, supported, and auditable management channels are available, which closes critical gaps in the attack chain. +Block the Azure AD PowerShell module (appID: 00001111-aaaa-2222-bbbb-3333cccc4444) and enforce the use of Microsoft Graph PowerShell or Microsoft Entra PowerShell to ensure that only secure, supported, and auditable management channels are available, which closes critical gaps in the attack chain. **Remediation action** diff --git a/src/powershell/tests/Test-Assessment.25375.md b/src/powershell/tests/Test-Assessment.25375.md index 04a7dd18c8..d94413bc28 100644 --- a/src/powershell/tests/Test-Assessment.25375.md +++ b/src/powershell/tests/Test-Assessment.25375.md @@ -7,8 +7,8 @@ Without this protection: **Remediation action** - Review Global Secure Access licensing requirements and purchase appropriate licenses. For more information, see [Licensing overview](https://learn.microsoft.com/entra/global-secure-access/overview-what-is-global-secure-access?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci#licensing-overview). -- Assign licenses to users through the Microsoft Entra admin center. For more information, see [Assign licenses to users](https://learn.microsoft.com/entra/fundamentals/license-users-groups?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci). -- Use group-based licensing for easier management at scale. For more information, see [Group-based licensing](https://learn.microsoft.com/entra/fundamentals/concept-group-based-licensing?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci). +- Assign licenses to users through the Microsoft 365 admin center. For more information, see [Assign or unassign licenses for users in the Microsoft 365 admin center](https://learn.microsoft.com/microsoft-365/admin/manage/assign-licenses-to-users?view=o365-worldwide&preserve-view=true&wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci). +- Use group-based licensing for easier management at scale. For more information, see [Assign or unassign licenses to a group in the Microsoft 365 admin center](https://learn.microsoft.com/microsoft-365/admin/manage/manage-group-licenses?view=o365-worldwide&preserve-view=true&wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci). - Monitor license utilization through Microsoft 365 admin center. For more information, see [Microsoft 365 admin center](https://admin.microsoft.com/Adminportal/Home#/licenses). - Review Microsoft Entra Suite as an alternative that includes both Internet Access and Private Access. For more information, see [What's new in Microsoft Entra](https://learn.microsoft.com/entra/fundamentals/whats-new?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci#microsoft-entra-suite). diff --git a/src/powershell/tests/Test-Assessment.61006.md b/src/powershell/tests/Test-Assessment.61006.md index 3e2287ffe9..e9c61bae6a 100644 --- a/src/powershell/tests/Test-Assessment.61006.md +++ b/src/powershell/tests/Test-Assessment.61006.md @@ -1,12 +1,17 @@ -The AI control plane in Microsoft Entra ID, Microsoft Purview, Microsoft Defender, Microsoft Intune, Microsoft Power Platform, Microsoft SharePoint, and Microsoft Global Secure Access — the administrative scopes that manage agent identities, Microsoft 365 Copilot admin settings, Conditional Access for AI, Copilot Studio environments, AI grounding sources, AI posture signals, and AI detection and response — must have named principals assigned to each role. When any of these roles has no assigned principals, no human operator is accountable for that slice of the AI surface: agent identities go un-reviewed, Copilot admin settings drift, AI-specific detections have no owner to tune, AI-network policies go un-adjusted, and AI-related escalations have no designated responder. Threat actors exploit this by targeting the AI control plane directly, relying on the gap between "the role exists in the directory" and "someone is actually watching it" — a gap that is invisible from a standard role-exposure audit but immediately consequential when an AI-related incident requires action. Confirming that every AI admin role has at least one assigned principal is the minimum organizational posture for AI administration: it does not prescribe who the principal is, how many there are, or how the assignment is made, but it guarantees that every AI admin scope has at least one accountable party. +The AI control plane surface includes Microsoft 365, Microsoft Power Platform, Microsoft SharePoint, and every layer of the Microsoft Security stack. Microsoft Entra ID is the identity control plane for this entire surface, and its administrative scopes manage agent identities, Microsoft 365 Copilot admin settings, Conditional Access for AI, Copilot Studio environments, AI grounding sources, AI posture signals, and AI detection and response. If there's no human assigned to an administrative role that manages these AI capabilities, then there's no accountable operator for that slice of the AI surface. This gap could mean: -**Scope of this check.** This check evaluates **Microsoft Entra directory role** assignments only. AI administration can also be granted through portal-native role systems that are *not* Entra directory roles — for example Microsoft Purview role groups, Microsoft Defender XDR custom roles, Power Platform environment-scoped roles and Dataverse security roles, SharePoint site-level permissions, and Copilot Studio maker permissions. A role appearing as "unassigned" here means no Entra principal is assigned to the corresponding Entra role; a workload-native administrator may still exist outside Entra and is out of scope for this assessment. +- Agent identities aren't monitored or reviewed +- Admin settings drift +- AI-specific detections have no owner to investigate or adjust +- Network control policies for AI aren't adjusted as the AI estate evolves +- AI-related escalations have no designated responder -**Remediation action** +Threat actors exploit this gap by targeting the AI control plane directly. They rely on the gap between a role existing in the directory and someone actually monitoring it. Confirming that every AI admin role has at least one assigned principal is the minimum organizational posture for AI administration. This check evaluates Microsoft Entra directory role assignments only. A role appearing as unassigned means no Microsoft Entra principal is assigned to the corresponding directory role, so workload-native administrators might still exist outside Microsoft Entra and are outside this assessment. AI administration of other platforms, such as Microsoft Purview role groups or Microsoft Defender custom roles, must be reviewed separately. -- [Assign an Entra ID role via the admin center](https://learn.microsoft.com/entra/identity/role-based-access-control/manage-roles-portal) -- [Create a PIM-eligible assignment for an Entra ID role](https://learn.microsoft.com/entra/id-governance/privileged-identity-management/pim-how-to-add-role-to-user) -- [Assign Microsoft Purview roles and role groups](https://learn.microsoft.com/purview/purview-permissions) +**Remediation action** +- [Assign a Microsoft Entra ID role via the admin center](https://learn.microsoft.com/entra/identity/role-based-access-control/manage-roles-portal?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci) +- [Create a PIM-eligible assignment for a Microsoft Entra ID role](https://learn.microsoft.com/entra/id-governance/privileged-identity-management/pim-how-to-add-role-to-user?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci) %TestResult% + diff --git a/src/powershell/tests/Test-Assessment.61008.md b/src/powershell/tests/Test-Assessment.61008.md index 5be90aca99..242821089a 100644 --- a/src/powershell/tests/Test-Assessment.61008.md +++ b/src/powershell/tests/Test-Assessment.61008.md @@ -1,14 +1,20 @@ -Custom security attributes are the primary mechanism for Conditional Access to distinguish between agent identities at scale, and they must be assigned to agent identities as part of the identity lifecycle. Without custom security attributes, Conditional Access policies can only target all agent identities, individual agent identities by object ID, or agent identities grouped by blueprint — none of which scale as the agent fleet grows. Attributes unlock the most powerful targeting pattern: filtering agents by department, approval status, sensitivity tier, or any organization-defined classification. For example, an attribute set called AgentAttributes with an AgentApprovalStatus attribute (values such as New, In_Review, HR_Approved, Finance_Approved, IT_Approved) enables attribute-based Conditional Access policies that match agents to resources based on their classification. +Custom security attributes are the primary mechanism for Conditional Access to distinguish between agent identities at scale. Without them, Conditional Access policies can only target all agent identities, individual agents by object ID, or agents grouped by blueprint. As your agent fleet grows, these mechanisms can't scale. Custom security attributes unlock the ability to filter agents by department, approval status, sensitivity tier, or any organization-defined classification. For example, an attribute set called `AgentAttributes` with an `AgentApprovalStatus` attribute (values such as `New`, `In_Review`, `HR_Approved`, `Finance_Approved`, `IT_Approved`) enables attribute-based Conditional Access policies that match agents to resources based on their classification. -When agent identities lack custom security attributes, the organization cannot reliably enforce Conditional Access policies and risks having gaps. This means that a newly provisioned or unclassified agent identity receives the same access controls as a fully vetted one, because there is no metadata to differentiate them. A threat actor who compromises or registers a rogue agent identity gains access to resources without being subject to classification-based policy enforcement. The absence of lifecycle tagging also degrades governance visibility — security teams cannot query, audit, or report on agent classification posture because there is nothing to query against. Assigning custom security attributes closes this gap by ensuring every agent identity carries machine-readable classification metadata that Conditional Access and audit queries can consume. +When agent identities lack custom security attributes, the organization can't reliably enforce attribute-based Conditional Access policies. A newly provisioned or unclassified agent identity receives the same access controls as a fully vetted agent identity because there is no metadata to differentiate them. A threat actor who compromises or registers a rogue agent identity gains access without being subject to classification-based policy enforcement. Assigning custom security attributes closes this gap by ensuring every agent identity carries machine-readable classification metadata that Conditional Access and audit queries can consume. -**Remediation action** +Policies that target all agent identities without attribute filters may still provide baseline protection, but they can't distinguish between approved and unapproved agents. Implementing attribute-based controls requires: + +- Defining an attribute taxonomy +- Coordinating with application owners +- Establishing an operational process to tag new agents as they're provisioned -1. [Add or deactivate custom security attributes in Microsoft Entra ID](https://learn.microsoft.com/en-us/entra/fundamentals/custom-security-attributes-add?tabs=ms-powershell) -2. [Assign custom security attributes to an application](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/custom-security-attributes-apps?pivots=portal) -3. [Manage custom security attribute assignments using Microsoft Graph](https://learn.microsoft.com/en-us/graph/custom-security-attributes-examples?tabs=http) -4. [Conditional Access for Agent ID (Preview)](https://learn.microsoft.com/en-us/entra/identity/conditional-access/agent-id) -5. [Filter for applications in Conditional Access](https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-filter-for-applications) +**Remediation action** +- [Conditional Access for agent identities](https://learn.microsoft.com/entra/identity/conditional-access/agent-id?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci) +- [Add or deactivate custom security attributes in Microsoft Entra ID](https://learn.microsoft.com/entra/fundamentals/custom-security-attributes-add?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci) +- [Assign custom security attributes to an application](https://learn.microsoft.com/entra/identity/enterprise-apps/custom-security-attributes-apps?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci) +- [Manage custom security attribute assignments using Microsoft Graph](https://learn.microsoft.com/graph/custom-security-attributes-examples?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci) +- [Filter for applications in Conditional Access](https://learn.microsoft.com/entra/identity/conditional-access/concept-filter-for-applications?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci) %TestResult% + diff --git a/src/powershell/tests/Test-Assessment.61009.md b/src/powershell/tests/Test-Assessment.61009.md index 3ee143fa18..c609aee1e6 100644 --- a/src/powershell/tests/Test-Assessment.61009.md +++ b/src/powershell/tests/Test-Assessment.61009.md @@ -1,11 +1,16 @@ -When an organisation deploys AI agents, those agents acquire access tokens for organisational resources on every interaction — mail, files, line-of-business APIs, downstream agents — and they do it without an interactive user session and without the device, location, or MFA signals that classic Conditional Access uses to make trust decisions for human users. Microsoft Entra Agent ID introduces two distinct first-class identity types that initiate these token acquisitions: **agent identities** (instantiated agents, modelled as service principals, that perform agentic tasks against resources) and **agent users** (non-human user accounts that back agent experiences requiring a mailbox or Teams presence). Conditional Access treats them as separate principal types: a policy that targets agent identities does not evaluate on agent-user sign-ins, and the reverse is also true. A tenant that enables agent workloads without at least one Conditional Access policy enforcing — `block unless approved` — has no enforcement boundary on autonomous AI access at all: every token request from an agent identity or an agent user is allowed by default, exactly the failure mode adversaries exploit when they compromise a single agent or its backing user account and then pivot through the resources that account can reach. As of writing this spec, Agent Users controls do not allow exclusions. A policy that blocks all agent users represents a tenant-level baseline that disables agent users from functioning. +When an organization deploys AI agents, those agents acquire access tokens to access organizational resources on every interaction, but without an interactive user session and device, location, or MFA signals that classic Conditional Access uses to make trust decisions for human users. Microsoft Entra Agent ID introduces two distinct identity types: -**Remediation action** +- An [agent identity](https://learn.microsoft.com/entra/agent-id/agent-identities?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci): An identity account within Microsoft Entra ID that provides unique identification and authentication capabilities for AI agents. +- An [agent's user account](https://learn.microsoft.com/entra/agent-id/agent-users?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci): An optional account that pairs 1:1 with an agent identity when the agent must access systems that require a user object. + +Conditional Access treats both agent identity objects as separate principal types. So a policy that targets agent identities can't target an agent's user account, and vice versa. A tenant that enables agent workloads without at least one Conditional Access policy enforcing block-unless-approved has no enforcement boundary on autonomous AI access. Every token request from an agent identity or agent's user account is allowed by default. Threat actors seek to exploit this type of failure mode when they compromise a single agent identity or its backing agent's user account and pivot through the resources that identity can reach. -- [Conditional Access for Agent ID (Preview) — concept and configuration](https://learn.microsoft.com/entra/identity/conditional-access/agent-id) -- [Identity Protection signals for agents (informs risk-based policies that complement the baseline)](https://learn.microsoft.com/entra/id-protection/concept-risky-agents) -- [Filter for applications in Conditional Access (basis for custom-security-attribute-based agent and resource targeting)](https://learn.microsoft.com/entra/identity/conditional-access/concept-filter-for-applications) -- [Custom security attributes in Microsoft Entra ID (referenced by attribute-based agent scoping)](https://learn.microsoft.com/entra/fundamentals/custom-security-attributes-add) +**Remediation action** +- [Conditional Access for Agent ID (Preview)](https://learn.microsoft.com/entra/identity/conditional-access/agent-id?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci) +- [Identity Protection signals for agents](https://learn.microsoft.com/entra/id-protection/concept-risky-agents?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci) +- [Filter for applications in Conditional Access](https://learn.microsoft.com/entra/identity/conditional-access/concept-filter-for-applications?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci) +- [Custom security attributes in Microsoft Entra ID](https://learn.microsoft.com/entra/fundamentals/custom-security-attributes-add?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci) %TestResult% + diff --git a/src/powershell/tests/Test-Assessment.61011.md b/src/powershell/tests/Test-Assessment.61011.md index 691a52dd8a..e5ff0d9a7c 100644 --- a/src/powershell/tests/Test-Assessment.61011.md +++ b/src/powershell/tests/Test-Assessment.61011.md @@ -1,12 +1,16 @@ -An agent endpoint that does not require Microsoft Entra user authentication is an unauthenticated reachable surface inside the tenant's AI estate. A threat actor that locates such an endpoint — through reconnaissance of public agent URLs, leaked Copilot Studio links, or enumeration of Foundry project endpoints — can interact with the agent without presenting any identity, then ride the agent's own grants to reach grounding data, connected tools, and downstream APIs the agent is authorized to call. Because the call never reaches Microsoft Entra, no Conditional Access policy evaluates it, no sign-in risk score is computed, no audit record ties the action to a real user, and no later investigation can attribute the resulting data access. The runtime behaviour that enforces Entra user authentication lives inside each agent's host (Copilot Studio, Microsoft 365 Copilot, Microsoft Foundry, custom code, third-party platforms) and is therefore not directly observable from the directory; what *is* observable is the trail left in the Microsoft Entra sign-in logs whenever an agent and its callers do go through Entra. This check inspects the last 30 days of sign-in activity for each agent identity and classifies the agent by the strongest evidence found: a non-interactive agent sign-in whose subject is a real user (the agent calling downstream resources on behalf of a signed-in user) is the strongest positive signal; an interactive user sign-in to the agent's blueprint is a good positive signal that proves users do reach the agent through Entra; absence of either across the lookback window means the platform has no evidence the agent enforces Entra user authentication and a control owner must verify the agent's host configuration directly. +An agent endpoint that does not require Microsoft Entra user authentication is an unauthenticated but reachable surface inside the tenant's AI estate. A threat actor might find this endpoint by discovering public agent URLs, using leaked Copilot Studio links, or enumerating Foundry project endpoints. The actor can then interact with the agent without presenting an identity and use the agent’s existing grants to access grounding data, connected tools, and downstream APIs. -**Remediation action** +Calls that don't reach Microsoft Entra can't be evaluated by Conditional Access policies, have no sign-in risk to calculate, and can't tie audit records to a specific user. The lack of this information makes it difficult to investigate and remediate. The runtime behavior that enforces Microsoft Entra user authentication lives inside each agent's host (Copilot Studio, Microsoft 365 Copilot, Microsoft Foundry, custom code, or non-Microsoft platforms) and is therefore not directly observable from the directory. What *is* observable is the trail left in the Microsoft Entra sign-in logs whenever an agent and its callers do go through Microsoft Entra. + +This check inspects the last 30 days of sign-in activity for each agent identity and classifies the agent by the strongest evidence found: a non-interactive agent sign-in where the subject is a real user is the strongest positive signal. An interactive user sign-in to the agent's blueprint is also positive evidence that users reach the agent through Microsoft Entra. Absence of either signal across the observation period means the platform can't confirm the agent enforces Microsoft Entra user authentication, and an accountable owner must verify the agent's host configuration directly. -- [Authenticate users in interactive agents](https://learn.microsoft.com/en-us/entra/agent-id/identity-platform/interactive-agent-authenticate-user) -- [Request delegated user authorization for interactive agents](https://learn.microsoft.com/en-us/entra/agent-id/identity-platform/interactive-agent-request-user-authorization) -- [Agent users in Microsoft Entra Agent ID](https://learn.microsoft.com/en-us/entra/agent-id/identity-platform/agent-users) -- [Microsoft Entra Agent ID overview](https://learn.microsoft.com/en-us/entra/agent-id/what-is-microsoft-entra-agent-id) -- [Sign-in logs in Microsoft Entra ID](https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-sign-ins) +**Remediation action** +- [Authenticate users in interactive agents](https://learn.microsoft.com/entra/agent-id/interactive-agent-authentication-authorization-flow?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci) +- [Request delegated user authorization for interactive agents](https://learn.microsoft.com/entra/agent-id/grant-agent-access-microsoft-365?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci) +- [Agent users in Microsoft Entra Agent ID](https://learn.microsoft.com/entra/agent-id/agent-users?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci) +- [Microsoft Entra Agent ID overview](https://learn.microsoft.com/entra/agent-id/what-is-microsoft-entra-agent-id?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci) +- [Sign-in logs in Microsoft Entra ID](https://learn.microsoft.com/entra/identity/monitoring-health/concept-sign-ins?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci) %TestResult% + diff --git a/src/powershell/tests/Test-Assessment.61012.md b/src/powershell/tests/Test-Assessment.61012.md index a4a434eb45..705d6d807c 100644 --- a/src/powershell/tests/Test-Assessment.61012.md +++ b/src/powershell/tests/Test-Assessment.61012.md @@ -1,10 +1,17 @@ -When an organisation enables AI agents in Microsoft Entra, two distinct non-human principal types start acquiring access tokens against organisational resources without any of the device, location, or interactive-MFA signals that classic Conditional Access uses to make trust decisions for human sign-ins: **agent identities** (instantiated agents, modelled as service principals, that act with their own identity or on a user's behalf). Microsoft Entra ID Protection for agents continuously evaluates each agent's behaviour and emits a risk level — high, medium, or low — driven by signals such as unfamiliar resource access (the agent reaches outside its established pattern), sign-in spikes (token replay or automation abuse), failed-access probing (an attacker enumerating resources with the agent's credentials), sign-ins by risky users during delegated authentication, and admin-confirmed compromise. Risk detection alone does not stop anything: without a Conditional Access policy that consumes the risk level and blocks token issuance, the platform records that an agent is high risk while continuing to mint the very tokens the adversary needs to keep moving — the report says "compromised", the resource still says "yes". As of May 2026, only agent identities support risk evaluation in conditional access. Agent ID Users are not covered by risk-based conditional policies. +When an organization enables AI agents in Microsoft Entra, [agent identities](https://learn.microsoft.com/entra/agent-id/agent-identities?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci) can access tokens to access organizational resources without an interactive user session and device, location, or MFA signals that classic Conditional Access uses to make trust decisions for human users. Microsoft Entra ID Protection for agents continuously evaluates each agent's behavior and emits a risk level that is driven by signals such as: + +- Unfamiliar resource access (the agent reaches outside its established patterns) +- Sign-in spikes (token replay or automation abuse) +- Failed-access probing (an attacker enumerating resources with the agent's credentials) +- Sign-ins by risky users during delegated authentication (an attacker leveraging a compromised user account) +- Admin-confirmed compromise (a security admin manually flags the agent as compromised) + +Without a Conditional Access policy that consumes the risk level and blocks token issuance, the platform can just record that an agent is high risk while continuing to mint the very tokens the adversary needs. The logs say "compromised" while the resource still says "yes." A risk-based Conditional Access policy that blocks high-risk agent identities is required to close this gap between detection and enforcement. **Remediation action** -- ID Protection for agents (concept, signals, and risk levels): -- Conditional Access for Agent ID (Preview) — covers the three agent access patterns and the single "All agent users" assignment for agent users: -- Plan a Conditional Access deployment (recommended: deploy in report-only mode and validate via sign-in logs filtered by `agentType` before switching to enforcement): -- Microsoft Entra ID P2 feature comparison (license precondition for ID Protection signal generation): +- [ID Protection for agents](https://learn.microsoft.com/entra/id-protection/concept-risky-agents?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci) +- [Conditional Access for agent identities](https://learn.microsoft.com/entra/identity/conditional-access/agent-id?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci) %TestResult% + diff --git a/src/powershell/tests/Test-Assessment.61013.md b/src/powershell/tests/Test-Assessment.61013.md index 408d083bd7..e6305717d7 100644 --- a/src/powershell/tests/Test-Assessment.61013.md +++ b/src/powershell/tests/Test-Assessment.61013.md @@ -1,18 +1,20 @@ -Microsoft Entra Agent ID requires every agent identity and every agent identity blueprint to have at least one sponsor — a human user (or supported group) who carries business accountability for the agent's lifecycle: deciding when the agent is no longer needed, requesting access packages on the agent's behalf, approving extensions when access expires, and authorising suspension during incidents. Sponsorship is the entry point for the rest of identity governance: lifecycle workflows route sponsor-leaving notifications to managers and cosponsors, access-package expiry escalations are sent to the sponsor, and entitlement-management approvers rely on the sponsor relationship to validate that an agent's continued access reflects current business need. An agent identity that exists in the tenant without a sponsor is governance-invisible. Sponsorship alone, however, is not enough: the workshop guidance also requires that agent permissions — group memberships, Microsoft Graph and other API permissions — flow through Microsoft Entra entitlement management rather than through direct grants. An access package is the unit of bundled grant; an assignment policy attached to that package decides who may request or be assigned the package, who must approve, how long the resulting assignment lasts, and how the assignment is reviewed for continued business need. When an organisation enables agent workloads but does not author at least one access package whose policy targets agent identities, every permission an agent receives must instead be granted directly — through `appRoleAssignment`, `oauth2PermissionGrant`, group `members/$ref`, or directory-role assignment — outside the entitlement-management control loop. Direct grants have no built-in expiration, no approver, no sponsor-driven extension notification, and no access-review schedule; once made, they persist until an administrator notices and removes them. A threat actor who later compromises the agent — through credential theft, blueprint compromise, or a malicious access-package request that no governance pipeline existed to intercept — operates against an identity whose permissions were never reviewed against current business need, the precise standing-privilege condition that lifecycle workflows, sponsor approvals, and time-bounded access packages are designed to prevent. This check verifies the two foundational conditions together: every agent identity and blueprint has at least one sponsor currently resolvable in the directory, and at least one access package in the tenant has an assignment policy whose `allowedTargetScope` is `allDirectoryAgentIdentities` — the Microsoft Graph value corresponding to the portal's *For users, service principals, and agent identities in your directory* → *All agents* selection. +Microsoft Entra Agent ID requires every [agent identity](https://learn.microsoft.com/entra/agent-id/agent-identities?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci) and [agent identity blueprint](https://learn.microsoft.com/entra/agent-id/agent-blueprint?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci) to have at least one sponsor. A sponsor is a human user, or supported group, that holds business accountability for the agent's lifecycle, such as deciding when the agent is no longer needed, approving extensions when access expires, and authorizing suspension during incidents. A sponsor is different from an owner, which designates the human users responsible for technical operations and incident response. -**Remediation action** +Sponsorship is the entry point for identity governance: + +- Lifecycle Workflows can route sponsor-leaving notifications to managers +- Access package expiry escalations are sent to the sponsor +- Entitlement management approvers rely on the sponsor relationship to validate continued access. -- [Administrative relationships in Microsoft Entra Agent ID](https://learn.microsoft.com/en-us/entra/agent-id/identity-platform/agent-owners-sponsors-managers) -- [Governing agent identities](https://learn.microsoft.com/en-us/entra/id-governance/agent-id-governance-overview) -- [Agent identity sponsor tasks in Lifecycle Workflows (Preview)](https://learn.microsoft.com/en-us/entra/id-governance/agent-sponsor-tasks) -- [Add sponsors to an agent identity](https://learn.microsoft.com/en-us/graph/api/agentidentity-post-sponsors?view=graph-rest-1.0) -- [Manage agents in Microsoft Entra ID](https://learn.microsoft.com/en-us/entra/agent-id/manage-agent) -- [Access packages for agent identities](https://learn.microsoft.com/en-us/entra/agent-id/agent-access-packages) -- [Create an access package in entitlement management](https://learn.microsoft.com/en-us/entra/id-governance/entitlement-management-access-package-create) -- [Create an assignment policy via Microsoft Graph](https://learn.microsoft.com/en-us/graph/api/entitlementmanagement-post-assignmentpolicies?view=graph-rest-beta) -- [Delegation and roles in entitlement management](https://learn.microsoft.com/en-us/entra/id-governance/entitlement-management-delegate) -- [Lifecycle Workflow built-in tasks](https://learn.microsoft.com/en-us/entra/id-governance/lifecycle-workflow-tasks) -- [Create a workflow via Microsoft Graph](https://learn.microsoft.com/en-us/graph/api/identitygovernance-lifecycleworkflowscontainer-post-workflows?view=graph-rest-1.0) +Without an assigned sponsor, agent identities can't be properly governed. An agent identity that exists without a sponsor is governance-invisible. Without an access package that targets agent identities, every permission an agent receives must be granted directly, through `appRoleAssignment`, `oauth2PermissionGrant`, group membership, or directory-role assignment, which is outside the entitlement management control loop. Direct grants have no built-in expiration, no approver loops, and no access review schedules. Without a Lifecycle Workflow containing agent sponsor tasks, the sponsor relationship is a static directory record with no automation when a sponsor moves or leaves. A threat actor who compromises an ungoverned agent — through credential theft, blueprint compromise, or a malicious access-package request that no governance pipeline existed to intercept — operates against an identity whose permissions were never reviewed. This check also verifies that at least one access package assignment policy targets all directory agent identities. +**Remediation action** + +- [Administrative relationships in Microsoft Entra Agent ID](https://learn.microsoft.com/entra/agent-id/agent-owners-sponsors-managers?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci) +- [Governing agent identities](https://learn.microsoft.com/entra/id-governance/agent-id-governance-overview?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci) +- [Agent identity sponsor tasks in Lifecycle Workflows](https://learn.microsoft.com/entra/id-governance/agent-sponsor-tasks?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci) +- [Access packages for agent identities](https://learn.microsoft.com/entra/agent-id/agent-access-packages?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci) +- [Create an access package in entitlement management](https://learn.microsoft.com/entra/id-governance/entitlement-management-access-package-create?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci) %TestResult% + diff --git a/src/powershell/tests/Test-Assessment.61014.md b/src/powershell/tests/Test-Assessment.61014.md index 90294a76e8..16797d4fd1 100644 --- a/src/powershell/tests/Test-Assessment.61014.md +++ b/src/powershell/tests/Test-Assessment.61014.md @@ -1,18 +1,18 @@ -Agent identities and agent identity blueprint principals are the two service-principal-derived types that carry runtime access in Microsoft Entra Agent ID. Agent identities are instantiated agents that acquire tokens and access resources directly; blueprint principals are the provisioning surface from which agent identities are created, and they hold their own app role assignments, delegated permission grants, and group memberships that can propagate to child agents. The `owners` relationship on each object designates the human user(s) responsible for technical operations and incident response, distinct from the `sponsors` relationship that carries business accountability for lifecycle and access decisions. When either object type has no owner, the tenant has an active principal that the security operations team cannot route to a responsible party when ID Protection flags it as risky, when anomalous resource-access patterns emerge, or when access-package extension requests require approval. A threat actor who compromises an ownerless agent or blueprint principal — through credential theft, blueprint exploitation, or malicious delegated consent — operates against a principal with no designated human for immediate containment, extending dwell time from minutes to the next manual directory audit cycle. The second failure mode is disabled objects that were blocked as part of triage but never deleted: a disabled object's `accountEnabled` property is `false` and it cannot acquire new tokens, but its app role assignments, group memberships, and OAuth2 permission grants persist in the directory. If a disabled agent identity is re-enabled — by an administrator who mistakes the disabled state for a provisioning error, or by a threat actor who has obtained directory write access — every permission snaps back without re-approval. If a disabled blueprint principal is re-enabled, it restores the provisioning surface for all child agent identities. The combination of ownerless objects and stale disabled objects is a standing-privilege accumulation pattern: the ownerless object has no human to initiate deletion, and the disabled-but-not-deleted object retains the privilege surface that deletion would have eliminated. +Microsoft Entra Agent ID introduced two identity types: [agent identities](https://learn.microsoft.com/entra/agent-id/agent-identities?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci) and [agent identity blueprint principals](https://learn.microsoft.com/entra/agent-id/agent-blueprint?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci). These identity objects derive from service principals, and so carry the same requirements and best practices for ownership, lifecycle management, and cleanup as any service principal. Blueprint principals are the provisioning surface from which agent identities are created and can hold grants that propagate to child agents. Having a designated owner for these objects helps in two important areas of agent identity management: -**Remediation action** - -Administrative relationships for agent IDs — owners, sponsors, and managers -- [Administrative relationships in Microsoft Entra Agent ID (Owners, sponsors, and managers)](https://learn.microsoft.com/entra/agent-id/agent-owners-sponsors-managers) +- Risks are contained and investigated by a responsible party +- Disabled objects don't introduce dormant privileges -Manage agent identities in your organization — add owners, enable/disable, delete -- [Manage agent identities in your organization](https://learn.microsoft.com/entra/agent-id/manage-agent-identities-organization) +The owners relationship on each agent identity object designates the human users responsible for technical operations and incident response, distinct from the sponsors relationship that carries business accountability for lifecycle and access decisions. So when ID Protection flags an agent identity as risk or anomalous resource access patterns emerge, the security operations team can route to a responsible party for containment and investigation. If there's no owner designated, a threat actor who compromises an ownerless agent or blueprint principal (through credential theft, blueprint exploitation, or malicious delegated consent) operates against a principal with no designated human for immediate containment. This issue can extend dwell time from minutes to the next manual directory audit cycle. -Governing agent identities — full governance lifecycle overview -- [Governing agent identities](https://learn.microsoft.com/entra/id-governance/agent-id-governance-overview) +When an agent identity or agent identity blueprint is disabled, it can't acquire new tokens so it can't access resources. The object still exists in the directory, so its app role assignments, group memberships, and OAuth2 permission grants persist. If an administrative error or a threat actor with directory write access re-enables the object, every permission snaps back without reapproval. If a disabled blueprint principal is re-enabled, it also restores the provisioning surface for all child agent identities. The combination of ownerless objects and stale disabled objects creates a standing-privilege accumulation pattern that proper ownership and cleanup are designed to prevent. -Manage agents in end-user experience — sponsors and owners can manage agents from the My Account portal -- [Manage agent identities (end user)](https://learn.microsoft.com/entra/agent-id/manage-agent-identities-end-user) +**Remediation action** +- [Administrative relationships in Microsoft Entra Agent ID](https://learn.microsoft.com/entra/agent-id/agent-owners-sponsors-managers?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci) +- [Manage agent identities in your organization](https://learn.microsoft.com/entra/agent-id/manage-agent-identities-admin?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci) +- [Governing agent identities](https://learn.microsoft.com/entra/id-governance/agent-id-governance-overview?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci) +- [Manage agents in end-user experience](https://learn.microsoft.com/entra/agent-id/manage-agent-identities-end-user?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci) %TestResult% + From 6fa6979b408ebdca7d09b7c9eb290426c18d71b7 Mon Sep 17 00:00:00 2001 From: Anton Staykov Date: Tue, 21 Jul 2026 14:57:46 +0200 Subject: [PATCH 2/2] module version --- src/powershell/ZeroTrustAssessment.psd1 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/powershell/ZeroTrustAssessment.psd1 b/src/powershell/ZeroTrustAssessment.psd1 index 936619ddc7..05aac32fc7 100644 --- a/src/powershell/ZeroTrustAssessment.psd1 +++ b/src/powershell/ZeroTrustAssessment.psd1 @@ -12,7 +12,7 @@ RootModule = 'ZeroTrustAssessment.psm1' # Version number of this module. -ModuleVersion = '2.4.0' +ModuleVersion = '2.5.0' # Supported PSEditions CompatiblePSEditions = 'Core', 'Desktop'