See every agent in one place, understand what it can access, detect agent sprawl early, and apply least-privilege permissions using the same Microsoft Entra tools you already use for users — without introducing new governance models.
Approve and scope agent access with accountability, enforce agent-specific Conditional Access in real time, automatically block risky behavior, and ensure every agent always has an owner, even as people change roles or leave.
Leandro Iwase, Microsoft Entra Senior Product Manager shows how to keep agents operating securely, transparently, and predictably across their entire lifecycle.
AI agents get real identities.
See how to apply permissions, protections, and policies. Treat agents like human users with Microsoft Entra Agent ID.
Gain full visibility for each agent in your tenant.
See how many agents exist, which are active or unmanaged, and where sprawl is starting — before it becomes a risk. Check out Microsoft Entra Agent ID.
Control what agents can access in real time.
Apply Conditional Access policies directly to agents using Microsoft Entra Agent ID. Start here.
QUICK LINKS:
00:00 — Treat AI Agents Like Real Identities
00:42 — Stop Agent Sprawl
02:26 — Least Privilege with Agent Blueprints
03:39 — Scope Agent Access
05:10 — Create agent specific Conditional Access policies
06:12 — Protect against a sponsor account
07:01 — Agents flagged as risky
07:50 — Ownerless agents
09:00 — Wrap up
Link References
Check out https://aka.ms/EntraAgentID
Unfamiliar with Microsoft Mechanics?
As Microsoft’s official video series for IT, you can watch and share valuable content and demos of current and upcoming tech from the people who build it at Microsoft.
- Subscribe to our YouTube: https://www.youtube.com/c/MicrosoftMechanicsSeries
- Talk with other IT Pros, join us on the Microsoft Tech Community: https://techcommunity.microsoft.com/t5/microsoft-mechanics-blog/bg-p/MicrosoftMechanicsBlog
- Watch or listen from anywhere, subscribe to our podcast: https://microsoftmechanics.libsyn.com/podcast
Keep getting this insider knowledge, join us on social:
- Follow us on Twitter: https://twitter.com/MSFTMechanics
- Share knowledge on LinkedIn: https://www.linkedin.com/company/microsoft-mechanics/
- Enjoy us on Instagram: https://www.instagram.com/msftmechanics/
- Loosen up with us on TikTok: https://www.tiktok.com/@msftmechanics
Video Transcript:
-As more AI agents become active in your environment, you need control over them and what they can access. That’s where Microsoft Entra Agent ID comes in. It lets you treat agents like you would treat human users with their own built-in identities. Agent ID lets you define permissions and extend new and existing protections to them. You stay in control across their entire life cycle, from initial creation to monitoring the day-to-day activities where we continuously check for risk and protect access to resources, to switching their ownership if their sponsors no longer around, and disabling them when they’re no longer needed. The good news is that you can use the same tools in Microsoft Entra that they use to manage human identities today. Let me show you. Here in the Entra Domain Center, you see a new type under Entra ID called Agent ID. In the overview, you’ll find a summary with key metrics. These insights highlight what you need to know about your agents.
-For example, how many agents are in your tenant, the number of agents recently created, how many are active or unmanaged and without identities. Each are starting point for understanding agent activity and spotting early signs of agent sprawl. Moving to the agent registry, you get visibility for each agent in your tenant and what platform they were built on and whether they have an Agent ID or not. The agents here are mixture of Microsoft-built agents, agents that you built in Microsoft Foundry, Copilot Studio, as well as Security Copilot. And no Microsoft agents using APIs and SDK supporting Agent ID. In fact, Agent Registry in Microsoft Entra is a shared center registry also used by the Agent 365 control plane. Next, in our agent identities, we can see all AI agents with an agent ID. Here, each agent automatically gets identity record, which is immutable object ID, just like a user or app registration would. It can quickly filter the list of the agents I want to manage. And by clicking into an agent like this one for HR self-service, we can see each details like the agent status, sponsor, permissions, roles, and associated policies.
-Then, agent blueprints are templates for how agent identities are created. They ensure that any agent created has the right controls and is aligned with organizational policies. In the blueprint, we can see that it has one linked agent identity, which is actually itself. That said, this blueprint could be used for other agents as they are created. In fact, let me show you how this works with a blueprint that has more linked agent IDs. Back in our agent identities view, I’ll take a look at this HR Test agent to verify its agent blueprint. Here’s one has two linked agent identities. One has been named an Actor agent and is active. I’ll click into its access details. Here, I can see the details for each permissions. It has Application.ReadWrite.All permissions in the Microsoft Graph, which means it’s over permission, so it’s potentially dangerous. If I go back to the agent page, I can disable this agent. And if I confirm, this will block the agent to improve security and prevent and authorize access to it. So as an administrator, you have full visibility into your agent details and their correspondent permissions for accessing your resources.
-Next, for scoping access to just what an agent needs to perform his tasks, we use access packages in Microsoft Entra. Let me show you. We start under Identity Governance, from Entitlement management and Access packages. You can see that I’ve already got one for a sponsor-initiated access package created. This includes the resources to help automate HR-related tasks for our agents. In Resource roles, you can see the specific Microsoft Graph API-related roles. Under Policies, that is just one initial policy. And clicking into it, we can see who can request access. I can choose from Admin, Self, Agent Sponsor, or Owner.
-Importantly, these access package requires agent sponsor to approve any agent requests for access and it requires a business justification as well. Let me show you how the access request process works. I’m logged in as a human agent sponsor with the My Access portal open. I’ll browse Available access package. And here, the Sponsor-Initiated Agent Access package that we saw before. Clicking to exposes which identity I’m requesting access for, and I’ll keep the Sponsor agent option, and I’ll choose our HR Actions Agent. Next, I just need to enter a business justification. I’ll enter Timebound access for HR agents, then submit the request. Once the request has been approved, the agent will work according to my policies. And now, I can even create specific conditional access policies that will assess this realtime as agents try to access resources.
-Here, I’ve created a Conditional Access policy to prevent agents from requesting sensitive information. In Assignments, there is now an option to apply the policy to agents. Under Grant, you see that this policy blocks all access requests by default, and you can see all agent identities are in scope. In my case, I want to make one exception. I want to make sure only approve HR agents can access HR information and stop our other agents. We can do that using an exclusion for HR-approved agents. Back in my policy, if I move over to Exclude, I can exclude one or more agent IDs from the policy. Using filter rules, this is how I can only allow the agents that were approved by HR to get access to dedicated HR resources, as you can see here. Under Target resources and in the filter, you also see that this policy covers all resources. So that was a very target Conditional Access policy.
-We can also apply broader policies for all agents at risk to protect against a sponsor accounting being compromised and giving the agent malicious instructions. I move over to another Conditional Access policy that I’ve started. Just notice the identities in scope are, again, all agents. Target resources are all resources. But under Conditions, there is a new one called Agent risk. And when I’m look at what’s configured, you see the now we have High, Medium, and Low risk level options. I’ve chosen High. And once that’s enabled, condition access, you assess agent risk in realtime based on its likelihood of compromise and automatically block access to any resource per this policy scope.
-Now, we’ve protected from risk agents when they request access to resources. And from Microsoft Entra, you can see which agents are currently flagged as risky in your tenant. Right from Identity Protection, you find your risky agents. So let’s take a look. We have three of them here. Our HR Actor agent from before shows high risk. By clicking in, you can see why. It looks like this agent tried to access resources that it does not usually access. Remember, this policy was a scoped to all agents without any exclusions, so if you block our HR agents too in case high risk is detected. So now our agents are running with their own identities and our resources are protected.
-Since agents have one or more human sponsor, let’s move on to what happens if a sponsor leaves or change roles and makes the agent ownerless. For that, using lifecycle workflows, we can automatically notify the right people when agents become ownerless. Work workflows are a great way to automate routine tasks like employee onboarding and offboarding, and they work for agents too. I will narrow my list down by searching for a sponsor. There’s my workflow for AI agents to configure their sponsor in the event of a job profile change. Drilling into the workflow and then into its tasks, you see that we have two tasks defined for the what happens when the job profile changes. The first is an email to notify the manager of the user move, and I’ll click into the second task, which sends an email to the manager to notify them about agent identity sponsorship change they will need to action.
-Let me show you an example when an agent sponsor leaves their role. Here, we’re seeing the manager’s mobile device. There’s a come in for an Outlook. And when we open it, in the mail, we can see that the manager needs to identify a sponsor for the two HR agents listed. This way, you can ensure the agents always have assigned sponsors.
-Microsoft Entra Agent ID provides comprehensive identity, access, and lifecycle management for agents, with the same familiar tools you leverage already for users. To learn more, checkout aka.ms/EntraAgentID. Keep checking back to Microsoft Mechanics for the latest tech updates, and thanks for watching.