The uncomfortable question every identity team is now being asked: what is that agent allowed to do, and how do we control it? As AI agents start holding their own accounts and acting on their own, they become another identity in your tenant — and if you can’t put Conditional Access in front of them, you’ve got a class of actor operating outside the controls you apply to everyone else. Extending CA to agent identities fixes that.
What you can actually do
Conditional Access now treats agents with user accounts as targetable identities. Three things stand out:
- Precise targeting — include or exclude individual agents, or group them dynamically with Custom Security Attributes, so agent policy is separate from human policy.
- Agent Risk — apply policy based on risky agent activity, the same shape of risk-based control you already use for users.
- Compliant devices and platforms — require agents running on managed endpoints (including Windows 365 for Agents) to operate only from devices that meet your compliance bar, and apply device-platform and trusted-network conditions.
Why it matters
This is Zero Trust catching up with reality. An agent that can read mail, move data, or call APIs is a principal you need to govern — scoping, risk, and device conditions are exactly the levers you’d want, delivered through the CA experience you already run rather than some bolt-on. The important design move is keeping agent identities on their own policies with their own attributes, not quietly folding them into the policies you wrote for people.
Source: Microsoft Learn. Summarised independently — check the source for the latest detail.