# Conditional Access policies cover both agent identities and agent users
When an organization deploys AI agents, those agents acquire access tokens to access organizational resources on every interaction, but without an…
Source: https://maester.dev/docs/tests/ZTA.61009
## Overview
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:
- 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.
## Remediation
- [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)
## Run it
The check runs as part of the whole assessment, with the ZeroTrustAssessment module installed:
```powershell
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
| | |
| --- | --- |
| Severity | High |
| Effort to fix | Low |
| Impact on users | Low |
| Pillar | AI |
| Category | AI Identity & Access |
| Product | [Entra ID](/docs/tests/products/entra) |
| Feature | Conditional Access |
| Area | AI and agents |
| ATT&CK | [T1078.004](/docs/tests?mitre=T1078.004) Cloud Accounts |
| Licence | AAD_PREMIUM&AGENT_365, AAD_PREMIUM_P2&AGENT_365, AAD_PREMIUM, AGENT_365 |
| 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`.