Skip to content
3.0 preview2.3.0 stable

These docs describe the preview. Pick the version you run and every page marks what it doesn't have yet. Get the preview →
Maester 2.x docs (archived) →

Sponsor

Agent identity lifecycle tagging (customSecurityAttributes present)

ZTA.61008MediumEntra IDAgent identitiesPreview 3.0

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

The check runs as part of the whole assessment, with the ZeroTrustAssessment module installed:

Install-Module ZeroTrustAssessment -Scope CurrentUser
Connect-Maester
Invoke-Maester -Pack ZTA -SkipBuiltIn

Leave out -SkipBuiltIn to run Maester’s own checks in the same run.

About this check
SeverityMedium
Effort to fixMedium
Impact on usersLow
PillarAI
CategorySecure AI Authentication and Access
ProductEntra ID
FeatureAgent identities
AreaAI and agents
TenantWorkforce

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.