Skip to content

Commit b017427

Browse files
authored
update dev branch with release changes (#1430)
update dev branch with release changes
2 parents 81a8c5e + 6fa6979 commit b017427

10 files changed

Lines changed: 89 additions & 60 deletions

src/powershell/ZeroTrustAssessment.psd1

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -12,7 +12,7 @@
1212
RootModule = 'ZeroTrustAssessment.psm1'
1313

1414
# Version number of this module.
15-
ModuleVersion = '2.4.0'
15+
ModuleVersion = '2.5.0'
1616

1717
# Supported PSEditions
1818
CompatiblePSEditions = 'Core', 'Desktop'

src/powershell/tests/Test-Assessment.21844.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
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.
22

3-
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.
3+
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.
44

55
**Remediation action**
66

src/powershell/tests/Test-Assessment.25375.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -7,8 +7,8 @@ Without this protection:
77

88
**Remediation action**
99
- 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).
10-
- 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).
11-
- 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).
10+
- 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).
11+
- 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).
1212
- Monitor license utilization through Microsoft 365 admin center. For more information, see [Microsoft 365 admin center](https://admin.microsoft.com/Adminportal/Home#/licenses).
1313
- 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).
1414
<!--- Results --->
Lines changed: 11 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -1,12 +1,17 @@
1-
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.
1+
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:
22

3-
**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.
3+
- Agent identities aren't monitored or reviewed
4+
- Admin settings drift
5+
- AI-specific detections have no owner to investigate or adjust
6+
- Network control policies for AI aren't adjusted as the AI estate evolves
7+
- AI-related escalations have no designated responder
48

5-
**Remediation action**
9+
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.
610

7-
- [Assign an Entra ID role via the admin center](https://learn.microsoft.com/entra/identity/role-based-access-control/manage-roles-portal)
8-
- [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)
9-
- [Assign Microsoft Purview roles and role groups](https://learn.microsoft.com/purview/purview-permissions)
11+
**Remediation action**
1012

13+
- [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)
14+
- [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)
1115
<!--- Results --->
1216
%TestResult%
17+
Lines changed: 14 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -1,14 +1,20 @@
1-
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.
1+
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.
22

3-
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.
3+
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.
44

5-
**Remediation action**
5+
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:
6+
7+
- Defining an attribute taxonomy
8+
- Coordinating with application owners
9+
- Establishing an operational process to tag new agents as they're provisioned
610

7-
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)
8-
2. [Assign custom security attributes to an application](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/custom-security-attributes-apps?pivots=portal)
9-
3. [Manage custom security attribute assignments using Microsoft Graph](https://learn.microsoft.com/en-us/graph/custom-security-attributes-examples?tabs=http)
10-
4. [Conditional Access for Agent ID (Preview)](https://learn.microsoft.com/en-us/entra/identity/conditional-access/agent-id)
11-
5. [Filter for applications in Conditional Access](https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-filter-for-applications)
11+
**Remediation action**
1212

13+
- [Conditional Access for agent identities](https://learn.microsoft.com/entra/identity/conditional-access/agent-id?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci)
14+
- [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)
15+
- [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)
16+
- [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)
17+
- [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)
1318
<!--- Results --->
1419
%TestResult%
20+
Lines changed: 11 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -1,11 +1,16 @@
1-
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.
1+
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:
22

3-
**Remediation action**
3+
- 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.
4+
- 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.
5+
6+
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.
47

5-
- [Conditional Access for Agent ID (Preview) — concept and configuration](https://learn.microsoft.com/entra/identity/conditional-access/agent-id)
6-
- [Identity Protection signals for agents (informs risk-based policies that complement the baseline)](https://learn.microsoft.com/entra/id-protection/concept-risky-agents)
7-
- [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)
8-
- [Custom security attributes in Microsoft Entra ID (referenced by attribute-based agent scoping)](https://learn.microsoft.com/entra/fundamentals/custom-security-attributes-add)
8+
**Remediation action**
99

10+
- [Conditional Access for Agent ID (Preview)](https://learn.microsoft.com/entra/identity/conditional-access/agent-id?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci)
11+
- [Identity Protection signals for agents](https://learn.microsoft.com/entra/id-protection/concept-risky-agents?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci)
12+
- [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)
13+
- [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)
1014
<!--- Results --->
1115
%TestResult%
16+

0 commit comments

Comments
 (0)