# Risk-based Conditional Access blocks risky agent identities
When an organization enables AI agents in Microsoft Entra, agent identities can access tokens to access organizational resources without an interactive…
Source: https://maester.dev/docs/tests/ZTA.61012
:::note[Maester checks this too]
[MT.1181](/docs/tests/MT.1181) (Conditional Access policy is present that blocks high agent risk sign-ins.) checks the same setting. Running both reports it twice.
:::
## Overview
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
- [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)
## 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 Authentication & 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_P2&AGENT_365, AAD_PREMIUM_P2, 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`.