Agent identity lifecycle tagging (customSecurityAttributes present)
ZTA.61008 is in Maester 3.0.0-preview and not in the stable 2.3.0 release yet. It will be in the next stable release. To use it now, install the preview:
Install-Module Maester -AllowPrerelease -ForceHow to get the preview, and go backUse the preview in GitHub Actions
Overview
Section titled “Overview”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 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.
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
Remediation
Section titled “Remediation”- Conditional Access for agent identities
- Add or deactivate custom security attributes in Microsoft Entra ID
- Assign custom security attributes to an application
- Manage custom security attribute assignments using Microsoft Graph
- Filter for applications in Conditional Access
Run it
Section titled “Run it”The check runs as part of the whole assessment, with the ZeroTrustAssessment module installed:
Install-Module ZeroTrustAssessment -Scope CurrentUserConnect-MaesterInvoke-Maester -Pack ZTA -SkipBuiltInLeave out -SkipBuiltIn to run Maester’s own checks in the same run.
About this check
| Severity | Medium |
| Effort to fix | Medium |
| Impact on users | Low |
| Pillar | AI |
| Category | Secure AI Authentication and Access |
| Product | Entra ID |
| Feature | Agent identities |
| Area | AI and agents |
| Tenant | Workforce |
Product, feature, area and ATT&CK are Maester’s: the assessment does not record them, so Maester keeps them in the pack’s taxonomy.json.
A Microsoft check, part of the Zero Trust Assessment pack. Text from ZeroTrustAssessment 3.1.0, © Microsoft, MIT licence.
About this check
- Severity
- Medium
- Effort to fix
- Medium
- Impact on users
- Low
- Product
- Entra ID
- Feature
- Agent identities
- Area
- AI and agents
- Pack
- Microsoft Zero Trust Assessment