Microsoft Entra Agent ID - Simply Explained

0:00 The agent. Nobody can name somewhere in your Microsoft three hundred sixty five tenant. An AI agent is signing in with an account nobody can name. It reads your mail, opens your files, and answers questions in teams. And when something goes wrong, there's no person on the other end to ask. That gap is what Microsoft Entra Agent ID was built to close. Welcome to the M365 FM podcast, where we explore the people, ideas, and technologies shaping the future of work. Today we're unpacking Microsoft Entra Agent ID, the framework that gives AI agents their own identity and why that changes how you manage your tenant. By the end, you'll know how to spot an agent and why giving it its own name matters. Why agents need their own identity an AI agent isn't a person, and it isn't a classic app either.

0:43 It reads. A situation, decides what to do, and then acts on that decision, calling tools and touching real data along the way. That makes it a new kind of worker in your tenant, one that doesn't fit the identity models you already have. Think about how we handle people. A user account is built around the things a human does to prove who they are like a password, a code on their phone, or a fingerprint. An application account leans the other way, assuming that whatever is signing in is steady, predictable, and owned by a known team for a long time. Agents break both patterns. They get created by automation, by someone clicking around in Copilot Studio or through an API, and nobody sits down to approve each one. One agent might live for a few minutes, and a busy workflow can create and destroy thousands of them in a single day, which is a pace no human identity was ever designed to keep up with.

1:27 When an agent borrows a login, every action it takes looks like the person who owns that login did it. And that turns your audit trail into a work of fiction. When it runs on a shared service account instead, you can't tell which agent did what, and you can't switch off one agent without breaking the others. Nobody wants to make that call at two in the morning. An agent identity fixes this by giving the agent an account of its own. It's an account built specifically for agents that come and go quickly, and it arrives with a named human attached. That one change turns an agent from an anonymous process into something you can manage. What an agent identity actually is. An agent identity is a special kind of service principle inside Microsoft Entra, and a service principle is simply the identity and app users to sign in.

2:08 In plain terms, it's the account your AI agent uses to prove who it is when it reaches for your apps, your services, and your data. Picture it like a profile. An agent identity has an ID that's unique in your tenant. A display name you'll see in the admin center, a blueprint it was created from, and an optional sponsor, which is the human being responsible for it. Some agents also get a second account called an agent user, which is a real user account decorated as an AI agent. That second account is only needed when a system insists on a user object, like a mailbox or a team's presence. Here's the part that surprises people the agent identity has no password, no secret, and no key of its own. It doesn't hold credentials at all, which means there's nothing sitting on the agent that an attacker could steal, and the agent can't sign in by itself.

2:50 The blueprint is the piece that gets it in. It holds the credentials and trades them for a token, which is just a temporary pass that says, This is agent X, and here's what agent X is allowed to touch. The blueprint makes that trade on behalf of the agent identity, and the agent identity is the one that shows up in the logs. One more boundary is worth knowing. An agent identity is single tenant, so it can only be used inside the tenant where it was created, and it can't reach into another organization's tenant. Blueprints themselves can travel across organizations, but the identities they create stay local, and that keeps the blast radius contained. The practical effect is simple to state because the agent has its own account and a named sponsor, you can answer the two questions that matter when something goes sideways. Which agent did this and who is responsible for it.

3:32 That puts serious weight on the blueprint. It turns out to be the most important object in this whole story, and by the end, you'll see why. It's also the one to watch. Blueprints. One template. Many agents. An agent identity blueprint is a template. It defines the kind of agent you're creating and holds the settings that every agent made from it will share. Like its name, its publisher, the roles it defines, and the permissions it's allowed to ask for. Microsoft's own example makes this concrete. Say you had a blueprint called Sales Assistant Agent. From that one template, you can spin up an agent for North America sales, another for South America, one for enterprise accounts and one for small business. Every one of them gets its own agent identity while still showing up as a sales assistant agent in the admin center. That grouping is the whole point because those agents share a blueprint, you can apply one policy to all of them, disable the entire family in a single move, or revoke a permission once instead of chasing down forty separate accounts.

4:21 The blueprint gives you a handle on the fleet, not just the individual. And it's the difference between managing one agent and governing one hundred. The blueprint also holds the credentials, so the keys live in one place instead of scattered across every agent. It's allowed to do exactly one thing in your tenant, and that's create or remove agent identities. It can't go off and read your files on its own, and it can't wander into your data by itself. Blueprints can also be multi-tenant, which means a publisher can offer one to other organizations, and each customer gets its own local identities created from it. The identities stay local even when the blueprint travels. A blueprint also gives you a paper trail. Actions taken by any agent of a given kind can be traced back to the blueprint that created it. So a new agent of the same kind picks up the same rules the moment it appears.

5:02 When you disable a blueprint, every agent identity underneath it stops signing in immediately, which makes it a genuine kill switch. That's an enormous amount of control sitting in one object, and it's why the blueprint is the one to watch. Hold on to that thought because it comes back when we get to the mistakes people make. Agent identities versus service principles versus managed identities. Three names get mixed up all the time, so let's separate them. A service principle, a managed identity, and an agent identity are all ways for software to sign in, and they solve different problems. A service principle is the identity and application users to sign in. It's built for steady, predictable workloads that hold their own credentials, which works beautifully for a long running service and gets awkward for something that spins up and disappears by lunchtime.

5:43 A managed identity is an identity that Azure creates and manages for you, so there's no secret for you to store or rotate when your code runs inside Azure. It's the cleanest option available because there's simply no key lying around to leak an agent. Identity is the newer one, and it's built specifically for agents. It sits on the same foundation as a service principal, but the credentials live on the blueprint instead of the identity, and the agent identity carries the permissions and the audit trail. Here's how the three differ. A normal application is one to one with its identity, while a single blueprint can produce many agent identities. A standard service principle holds its own credentials and acts as itself directly, while an agent identity holds nothing and is impersonated by its blueprint. A managed identity doesn't replace an agent identity at all, because it's just one of the credential types you can put on a blueprint that split matters more than it sounds, because the blueprint holds the credentials and the identity holds the permissions.

6:33 The identity is what you see in the logs, and the blueprint is what an attacker would need to steal. One thing stays familiar an agent identity can be given the same kinds of access a service principal gets, including Microsoft Graph permissions, Microsoft Entra roles, and Azure roles. That's the part to respect because it means an agent can hold real power in your environment. Each one has a natural home. Use a managed identity when your code runs in Azure and you want no secrets to babysit, use a service principle for the steady application workloads that have always used one. Reach for an agent identity when the thing signing in is an AI agent that decides and acts on its own. Some agents you meet today were built before this platform existed, and they're still running on a plain application service principle.

7:14 They look like agents in the admin center, but they don't get the sponsor, the life cycle controls or the clean agent specific logging that the newer model provides conditional access for agents. Now that you know what these identities are, the next question is what they're allowed to do. Conditional access is the rule book that answers that, and it's the same tool you may already use for your people. Conditional access looks at the signals around a sign in, like who is asking where they're asking from, and how risky the whole thing looks. Then it decides whether to let the request through, block it, or demand something more. The same engine runs for agents, but the rules have to be written for agents because an agent can't answer a prompt on your phone. There are three ways an agent gets access and each one is a different subject. An agent can act on behalf of assigned end user, which we call delegated access.

7:57 It can act as itself with no user in the picture, which is how an autonomous agent works in the background, or it can act through its own user account. The digital worker style, when it needs to look like a real colleague with a mailbox and a calendar. Because each of those is a different subject. Each one needs its own policy. A policy that names the agent identity won't reach the agent's user account, and the reverse is just as true. So the safe habit is to write a policy for each way your agent signs in miss one, and you've left a door propped open. Here's where the blueprint earns its keep again. AIM one policy at a blueprint, and it covers every agent created from it, including the ones you haven't built yet. As the number of agents grows, you can also tag them with labels like environment or data sensitivity, and target those labels in a policy.

8:38 That way, a single rule covers a whole group. Instead of a list you have to maintain by hand. Intra can also flag a risky agent and block it automatically the same way it handles a risky user. You can run a new policy in report only mode first, which lets you watch what it would do before it starts blocking anything in production. There's one honest limit to remember conditional access only protects the resources that sit behind entra. So if an agent reaches your data with an API key, it walks right past the whole check governing the agent lifecycle access rules keep an agent inside its lane, but someone still has to own the agent over time. And that's where governance comes in. Microsoft Entra lets you manage an agent the same way you manage a person across its whole life, not just on the day it's created. Every agent identity should have a named human sponsor, the person accountable for what the agent is for and what it can reach.

9:23 There's usually an owner as well who handles the technical side and keeping both roles current is the difference between a managed agent and an orphan. There's a safety net built in. If a sponsor leaves the organization, sponsorship automatically transfers to that person's manager, so an agent is never left floating with nobody responsible for it. That single rule prevents a slow drift that would otherwise go unnoticed for months. For access, you can use access packages, which are time bound bundles of permission that arrive with an approval. An agent can request one itself. A sponsor can request one on its behalf, or an administrator can assign one directly. The important part is the clock, because when the package expires, the access goes away instead of lingering for years. Direct assignment still has its place, and it's fine for a short list of agents you know well.

10:05 Access packages are the better fit when the same access keeps getting handed out because the approval and the expiry come built in from the start. Then there are lifecycle policies which come down to three checks an agent has to keep passing. A sponsor has to reconfirm that the agent is still needed. The agent has to keep at least the minimum number of sponsors, and the agent can't go silent for too long without any sign ins. If an agent fails one of those checks, the policy can disable it, delete it, or disable it, and then delete it. After a grace period gives someone time to fix the problem. The recommended rhythm is to have sponsors attest, every six to twelve months that each agent is still needed. Put that together and you get a system that stops agent sprawl, the slow pile up of identities that nobody owns and nobody remembers, least privilege explained simply.

10:45 Least privilege sounds fancy, but it's a simple idea. Give the agent the smallest amount of access it needs to do its job and nothing more. That matters more with agents than with most things, because an agent chain's actions across systems a small over permission on one step can quietly open up a much bigger blast radius later, and by the time anyone notices, the agent has already done the damage. There's a helper here called inheritable permissions. Instead of granting the same baseline to every agent one at a time, you grant it once on the blueprint and the agent's inherited. The platform keeps you honest. With a few guardrails a blueprint can inherit from only a limited number of resource apps, and there's a cap on how many scopes each app can pass down. Some high privilege scopes are blocked from inheritance entirely. The habit to build is to start with a short, specific list of scopes and expand only when a real need shows up.

11:30 Broad permissions granted to unblock a pilot are exactly the ones that never get cleaned up afterward. One habit worth stealing from security teams is the aggregate view. Don't judge an agent by a single permission. Add up everything it can do across roles, tools and systems because that total is the real power the agent holds, and it's usually bigger than any one setting suggests. Credential hygiene belongs in the same conversation. Prefer managed identities or certificates over client secrets, keep secrets out of production, and rotate certificates at least once a year. Also, prefer delegated permissions where the agent acts as a signed in user over broad application permissions that let it act on its own across the whole tenant. The pitfalls that catch people out. Everything so far assumes you set agents up the right way, and that's the part people skip.

12:12 Let's talk about what goes wrong in real tenants, because these mistakes show up again and again, and most of them stay quiet until an audit or an incident drags them into the light. Each one is really a failure to treat an agent like a first class identity. Start with the shortcut building an agent as a plain app registration or service principle outside the framework feels fast and works fine at first. What you give up is the sponsor, the life cycle rules, and the clean audit trail that agent specific logging gives you. What you're left with is an agent that's really just an app in a costume. Watch for this with AI coding assistants, because they tend to reach for the old application pattern by default. Sharing one identity across several agents is another quiet one. Once two agents where the same account. You can't tell their work apart in the logs, and retiring one means you're also cutting off the others.

12:54 Then there's blueprint creation itself because a blueprint holds the keys, the person who creates it becomes an owner. So a tenant that leaves this open to everyone has a governance hole dressed up as a convenience. It's also a separate setting from the one that controls app registrations, which is how it slips past people who lock down app creation years ago. Treating the blueprint as a minor object is a related mistake. Security researchers found that a blueprint owner can add credentials to the blueprint and then impersonate the agent identities underneath it, which means a blueprint whose agents hold high impact permissions becomes a real takeover target. That's a research finding rather than a statement from Microsoft, but it's worth knowing aiming user policies at agents is another trap because agents can't pass an MFA prompt. Broad user rules can either break your agents or leave them uncovered, and neither outcome is what you want, right?

13:39 Agent specific policies. Instead, permission creep is the slow one where teams grant broad access to get a pilot moving and never narrow it afterward. Even though an agent can be handed roles that genuinely matter. Then there's the orphan, an agent whose sponsor left, whose description is blank and that nobody has signed into for months, which is exactly the kind of identity an attacker likes best. The common thread is simple agents are easy to create and easy to forget, and every one of these pitfalls comes from forgetting that an agent is an identity you have to look after. Get that right and the rest of the model falls into place. The recap and one question. So here's where we've landed. An AI agent is a new kind of account. It gets its own identity, and a blueprint holds the keys for every agent of its kind. You govern the whole thing with tools you already know, conditional access to decide what's allowed, sponsors and access packages to keep ownership, current lifecycle policies to clean up and least privileged to keep each agent small.

14:30 Before you go, sit with one question in your own tenant, which AI agent could nobody name today and who should be its sponsor? The answer tells you where your governance really stands.