Agent 365 for fintechs: getting a grip on agent identities

Microsoft Agent 365 gives fintechs one place to find, govern and secure every AI agent and its Entra Agent ID, but the agent identity is only one layer. Without strong identity controls, data loss prevention and secure devices underneath it, an agent simply inherits your weaknesses.

Agent 365 has been out since May, and the question I keep hearing from fintech security leads is some version of "right, so is this the fix for all the agents popping up in our tenant?"

If I'm honest, my answer is yes and no. Microsoft Agent 365 is the best thing Microsoft has shipped for agent governance so far, and if you're a fintech with agents popping up in Copilot Studio, Azure and whatever the engineering team knocked together last sprint, you should be looking at it. But I've been in enough tenants to know what happens when people buy the shiny control plane and skip the boring bits underneath. So I'll be straight about both.

What is Microsoft Agent 365?

Microsoft Agent 365 is Microsoft's control plane for AI agents. It gives IT and security teams one place to find, govern and secure every agent in the organisation, whether it was built in Copilot Studio, bought from a partner like ServiceNow or Workday, or written in-house and registered manually.

It went generally available on 1 May 2026. UK list price is £11.50 per user per month (ex VAT, paid yearly on an annual commitment), and it's also bundled into the new Microsoft 365 E7 at £81.60 per user per month. The licensing quirk worth knowing is that you license the humans, not the agents. Agents acting on behalf of a licensed user are covered, so you're not paying per bot. (Which is nice! I fully expected a per-agent meter.)

What do you actually get?

Microsoft describes four main areas:

• An agent registry, which is an inventory of every agent in the tenant, whether Microsoft built it, a partner built it or you did.
• Access control that enforces least privilege over which users, data, tools, MCP servers and other agents each agent can reach, with IT-controlled onboarding and policy templates.
• An agent map showing how agents connect to each other and to the rest of your estate, plus usage analytics.
• Security and governance that hooks into the stack you already know. Entra handles identity and access, Defender handles posture and threat protection, Purview looks after the data agents use and create, and Intune applies guardrails on endpoints.

That last one matters more than the other three put together, and I'll come back to it.

What is Microsoft Entra Agent ID?

Microsoft Entra Agent ID gives each AI agent its own first-class identity in Entra, separate from your users and from the app registrations and service principals people have been bodging agents onto for the last couple of years. Agent 365 is the console. Agent ID is the identity layer underneath it.

There are three concepts worth getting your head around.

An agent identity is the identity a single agent instance signs in with. One agent, one identity, so you can see exactly who did what and switch off one agent without breaking the others.

An agent identity blueprint is a template that defines the permissions, credentials and policies for a type of agent. Every agent created from it inherits them. Disable the blueprint and every agent under it is blocked straight away, which is about as close to a big red button as you're going to get.

A sponsor is the named person (or group) accountable for the agent's purpose. Microsoft's guidance is that every blueprint and every agent identity has one, plus a technical owner.

On top of that, Conditional Access for agents and ID Protection for agents rolled out worldwide over July and August 2026. They're licensed through Agent 365 (paired with at least Entra ID P1 or Microsoft 365 E3) or through Microsoft 365 E7. In practice that means you can block an agent unless your conditions are met, and block it automatically when Entra flags it as risky. One gotcha: the agent risk condition needs Entra ID P2 while it's in preview, so check that before you promise it to anyone.

Why should a fintech care about agent identity?

Because your regulator, your auditors and your enterprise customers all end up asking the same question... who's accountable for this thing?

The FCA's Senior Managers and Certification Regime is built around named individuals being accountable. An agent with tenant-wide access and no owner is the opposite of that. DORA expects you to understand and manage your ICT risk, and an agent quietly holding access to customer data is ICT risk whether it's on the register or not. And it won't be long (if it hasn't happened already) before enterprise security questionnaires start asking how you govern AI agents. "We've got a few in Copilot Studio, I think" isn't going to cut it.

The sponsor model gives you a clean answer to that. Every agent has a person's name against it, a purpose and a review date.

How does Agent 365 help you get a grip on agent identities?

Agent 365 lets you run the same joiner, mover, leaver discipline for agents that you (hopefully) already run for people. This is the order I'd tackle it in:

1. Find what you've already got. Use the registry to pull every agent into one list. You'll find some you didn't know about. Everyone does.
2. Move agents onto proper agent identities. Build them from a blueprint, not a standard app registration with a client secret pasted into a config file. Microsoft's own best practice guidance says exactly this.
3. Put a sponsor's name on every one. If nobody will own it, it doesn't go live.
4. Scope access to the bare minimum. Specific sites, specific APIs. For fleets of similar agents, use access packages so access is time-bound and approved rather than granted directly and forgotten about.
5. Wrap Conditional Access around them. Target the blueprint so current and future agents inherit the policy, block on high agent risk, and run everything in report-only first so you don't knock over a production flow at 4pm on a Friday.
6. Give them a lifecycle. Sponsors confirm every 6 to 12 months that the agent's still needed. Expire inactive agents. Go hunting for orphaned ones every quarter.
7. Watch them. Get agent sign-ins and audit logs into Defender or Sentinel, with alerts on spikes in token requests, new permissions and calls to APIs the agent has never touched before.

There's nothing clever in that list. It's the same identity hygiene I bang on about for humans, pointed at a new type of identity.

Why isn't the agent ID enough on its own?

The agent ID governs the agent. It does nothing about the person the agent works for, the data it can reach or the device it runs on. And most agents in a fintech today act on behalf of a person, using that person's access, from that person's laptop.

What really drives this home for me is how little Conditional Access can do to an agent identity. When the token belongs to the agent, you get one control (block) and one condition (agent risk). That's it. You can't make an agent do MFA, and Microsoft's own docs tell you not to require a compliant device for it, because it can't complete interactive remediation.

So when an agent works through the on-behalf-of flow, the user's own Conditional Access policies are doing a big chunk of the protecting. If that user is on SMS MFA, sitting on standing admin rights and signing in from a personal laptop nobody manages, a beautifully governed agent identity on top doesn't change much.

There's another gap people miss. Conditional Access can't govern an agent that reaches resources with an API key, because that path never goes through Entra at all. If someone's wired an agent to a third-party API with a key in an environment variable, Agent ID has no idea it exists.

It's a bit like fitting a fancy new lock to the safe while the office door's propped open with a fire extinguisher.

What foundational controls have to be in place first?

Before Agent 365 is worth the licence, you need strong identity controls for your people, data loss prevention on your data and secure, managed devices. They're the foundation layer every agent control sits on, and if any of them is weak, the agent inherits the weakness.

Strong identity controls

Strong identity means phishing-resistant MFA (passkeys or FIDO2 keys) for everyone, not just admins. It means a proper Conditional Access baseline with legacy authentication blocked, PIM for every privileged role so nobody holds standing Global Admin, and a leavers process that actually works. That last one matters more now, because when an agent's sponsor leaves the business, somebody needs to pick it up.

Pretty much every Entra posture check I do turns up the same problems: over-privileged accounts, Conditional Access with holes in it, and access nobody ever took away. An agent working for one of those accounts gets all of that, at machine speed.

Data loss prevention

An agent can only see what its user can see. The trouble is, in most tenants, users can see far more than they should. That SharePoint site somebody shared with "Everyone except external users" three years ago? Your agents will find it, and quicker than any person would.

For a fintech that's KYC documents, card data, customer PII and board packs. Get sensitivity labels on the sensitive stuff, put Purview DLP policies in place that cover Copilot and agent interactions, and use DSPM for AI to see where the oversharing is and what's being fed to agents. Labels travel with the data, so a restricted document stays restricted whether a person or an agent picks it up.

Secure devices

Conditional Access can't demand a compliant device from the agent, so the device control has to sit on the human. Require compliant, Intune-managed devices for anyone using agents against sensitive data, with Defender for Endpoint on every one of them.

This matters even more with local agents. Developers running coding agents and local MCP servers on their laptops have tokens, repos and sometimes production credentials sat on that machine. If it's an unmanaged Mac with no EDR, that's where I'd be worried, not the Copilot Studio bot in HR. Microsoft is extending Intune guardrails to agents on endpoints as part of Agent 365, but Intune can only enforce on devices it actually manages.

Where should a fintech start with Agent 365?

Start with an honest look at your foundations, then bring Agent 365 in on top. In practice I'd go:

1. Baseline the foundations. Check MFA strength, Conditional Access coverage, PIM, labelling and device compliance. Fix the gaps that would make an agent dangerous first.
2. Get the licensing straight. Agent 365 on its own needs at least Entra ID P1 or Microsoft 365 E3 for agent Conditional Access, and agent risk needs P2. If you're already on E5 (£51.60 per user per month) and want the lot, run the numbers on E7 at £81.60, but bear in mind E5 plus Agent 365 bought separately comes to £63.10, so E7 only stacks up if you'll actually use the extras it bundles in.
3. Inventory every agent. Registry first, then go through your app registrations and service principals for the ones built the old way.
4. Pilot with one blueprint. Pick a low-risk agent type, set up the blueprint, sponsor, scoped access and Conditional Access in report-only, and learn from it before you roll out wider.
5. Write it down. Add agents to your risk register, your access review cycle and your incident response plan. That's what an auditor, or a customer's security team, will ask to see.

Frequently asked questions

Do we need Agent 365 to secure AI agents in Microsoft 365?

Entra Agent ID is the identity layer, but the agent-specific Conditional Access, ID Protection and governance features are licensed through Agent 365 or Microsoft 365 E7. If you want to actually control your agents rather than just name them, you'll need one of the two.

How is Microsoft Agent 365 licensed?

Per user. UK list price is £11.50 per user per month (ex VAT, annual commitment), or it's included in Microsoft 365 E7 at £81.60 per user per month. Agents acting on behalf of a licensed user don't need a licence of their own, which keeps the maths a lot simpler than I expected.

Can Conditional Access make an AI agent use a compliant device?

No. For an agent identity, Conditional Access can block access or act on agent risk, and that's the lot. Device compliance and MFA have to be enforced on the person using the agent, which is exactly why the foundations matter so much.

Does Agent 365 make a fintech compliant with FCA or DORA expectations?

On its own, no. It gives you inventory, accountability and control evidence that supports your compliance story, but regulators and auditors look at the whole picture, including how the data and devices underneath are protected. (Usual caveat... I'm not a lawyer, so check the regulatory detail with your compliance team.)

What's the biggest mistake to avoid with Agent 365?

Buying it and treating it as your AI security strategy. It's one layer. If identity, DLP and device controls aren't solid underneath, all you've really got is a very well-organised list of your risks.

Wrapping up

I'm properly pleased Microsoft has built this. Agents finally get treated as identities with owners and lifecycles, which is what I've been nagging clients about for a while. Just don't let it become the shiny thing that distracts you from the basics. Strong identity, DLP and secure devices first, then Agent 365 on top, and you'll be in a far better place than most.

If you're a fintech trying to work out where agents fit into your security strategy, or you want a second pair of eyes on your foundations before you switch Agent 365 on, give me a shout. It's exactly the kind of work we do in our identity and access management consultancy. And if you want this sort of thing landing in your inbox, it's what I write about every week in Tame Your Cloud 😄

Paul Sanders is the founder of Yobah, a cyber security strategy and identity and access management consultancy for fintech scale-ups, based in Manchester and serving FCA-regulated firms across the UK.