If your LinkedIn feed looks anything like mine, it has basically turned into an agent infomercial.
Sales agents. IT admin agents, meeting note agents, agents that summarize your day, schedule your dog, and probably judge your inbox. Everyone is talking about what these things can do. Very few people are asking the much less glamorous, but far more important question.
How do we actually secure them?
As someone who lives in the Microsoft security world, that gap between “shiny demo” and “governed, auditable, and not terrifying” is where my brain immediately goes. So yes, the Intune team absolutely deserves credit for the new Change Review and Policy Configuration agents. They are slick.
However, there is another feature that quietly landed in Entra ID that deserves way more attention.
Conditional Access for Agent ID
This is the control that lets us bring agents into the same Zero Trust world as our users and apps, instead of treating them like magical black boxes.
Ignite 2025. So Many Agents….
Ignite 2025 did not gently introduce agents. It slammed the accelerator.
We saw things like.
- Sales Development Agents that go prospecting on their own
- Workforce Insights Agents that comb through org data and trends
- Teams Channel Agents that connect to Jira, GitHub, and more through MCP servers
- Agent 365 stepping in as a kind of “control plane for agents” that plugs into the Microsoft ecosystem
All of that is exciting on its own. Then Microsoft quietly added gasoline to the fire.
Security Copilot is now included with Microsoft 365 E5. That is an adoption rocket!
In practice, that means organizations suddenly have access to a bunch of new security-focused agents across Defender, Entra, Intune, and Purview, ready to be turned on and pointed at production data.
The new Intune preview agents, like the Change Review Agent that sanity-checks policy changes before rollout, are another great example. Anyone who has ever pushed a configuration that unintentionally bricked half their fleet is probably already in love with that idea.
Yet there is a catch.
Analysts are predicting billions of agents in the next few years, many with access to highly sensitive systems and data. That is a lot of non-human identities running around your environment making decisions.
Our old way of handling service accounts is not going to cut it.
The Awkward Question. Who Are These Agents, Really?
Let’s zoom out for a moment and ask the questions that every security person should be asking.
When an agent.
- Updates a record in your CRM
- Scans access permissions in SharePoint
- Pushes policy changes into Intune
…what identity is actually being used?
Is it a service account with broad rights that everyone “just knows not to touch”? Is it an app registration with a terrifying list of granted permissions? If that agent starts doing something odd, can you block it with Conditional Access?
Traditional service accounts and application identities were never designed for autonomous agents that act on their own. They.
- Do not have rich risk signals
- Often bypass the Conditional Access logic you rely on for users
- Tend to be “all or nothing” in terms of access
That is where Microsoft Entra Agent ID comes in. It treats agents as first-class identities in your tenant.
Once that is in place, we can stop pretending agents are special unicorns and start treating them like what they really are. High-privilege identities that need guardrails.
Conditional Access for Agent ID
Conditional Access for Agent ID is where this all becomes real.
Instead of agents just “doing their thing” in the background, they now flow through the same policy engine that protects your human users and workload identities. Only now, the engine is using agent-specific signals too.
When an agent asks for a token to access something, Conditional Access evaluates that request. You can.
- Block high-risk agents automatically using Identity Protection risk detections
- Limit agents to specific cloud apps or APIs
- Use custom security attributes to build granular policies around groups of agents
Building Your Conditional Access Policy for Agents
The good news. Getting started with Conditional Access for Agent ID is not painful. If you have built traditional CA policies before, this will feel familiar.
You can roughly think in these steps.
- Sign in to the Microsoft Entra admin center with the right permissions to manage Conditional Access.
- Go to Entra ID > Conditional Access > Policies.
- Create a new policy and give it a clear, descriptive name.
- In Assignments, target all agent identities to start, or filter down to specific agents when you have a defined scope.
- In Target resources, decide whether you are protecting all cloud apps or a smaller set that your agents actually need.
- Under Conditions, consider.
- Agent risk. Block access if the agent is flagged as high risk.
- Under Access controls, select Block Access.
Microsoft even offers a template policy that blocks high-risk agent identities. It is a perfect starting baseline.
Checking Risky Agents in Entra
Once you start protecting agents with Conditional Access, you also need a quick way to see which ones are misbehaving. That is exactly what the Risky agents report in Entra Identity Protection gives you.
In practice, you might use this report during a weekly review. Check for any new high or medium risk agents, confirm that your “block high risk agents” policy is doing its job, and then decide whether you want to tune detections, adjust access, or offboard an agent entirely.
The E5 Effect. Why 2026 Is Going to Be Interesting
Let’s circle back to that Security Copilot change.
By including Security Copilot with E5, Microsoft effectively lowers the barrier to entry for agent adoption across a huge customer base. The result is predictable.
- More organizations will try agents
- More teams will wire those agents into production
- More sensitive workloads will be touched by non-human identities
Security Copilot agents for SOC triage, identity cleanup, endpoint hygiene, and more are incredibly powerful. They can do real work. They can also, if left unchecked, do real damage.
Conditional Access for Agent ID is how you turn that gut feeling into enforced reality.
Where Intune Fits In. The Short Version
Let’s talk Intune quickly, because the new Intune agents are a perfect example of why this matters.
- Change Review Agent. Evaluates configuration changes before deployment.
- Policy Configuration Agent. Translates intent into actual Intune policy.
- Device Offboarding Agent. Helps manage cleanup and transitions.
All three of these need serious rights in your Intune environment. They are not spectator agents. They are touching real configuration at scale.
Why This Is a Big Deal
The “agent era” is no longer a slide in a keynote. It is live, it is shipping, and it is landing in real tenants.
The organizations that are going to be in a good place are not just the ones that adopt agents first. They are the ones that secure agents first.
Agent 365 and Entra Agent ID show that Microsoft is thinking about governance, not just capability. Even better, you do not have to rebuild your security model from scratch.
- Your Conditional Access knowledge still applies
- Your Identity Protection setup still matters
- Your Zero Trust principles map directly onto agents
For consultants, architects, and IT leaders, this is a chance to be the voice in the room saying.
“Yes, the agent is impressive. Now show me how it is secured.”
Your future self. The one not explaining an “agent-related incident” to leadership. Will be very, very grateful.
