When governance creates the risk.

Your governance register says a team is accountable for that AI agent. Your directory can only name a person — and naming them hands them the agent’s permissions.

An auditor asks who owns the service principal that syncs your finance data. You open Entra, look at the Owners blade, and there is a name. The control is evidenced, the finding is closed, everyone moves on.

The problem is that the name in that field was never an accountability record. It is a grant of power, and it may be a considerably larger one than the person it names has anywhere else in your tenant.

What ownership actually means in a directory

Microsoft is not vague about this. Their documentation states that owners have the same permissions as application administrators, scoped to an individual application. It then adds a warning that deserves more attention than it usually gets:

The mechanism is documented too. Look at the permissions a member user holds over objects they own and you will find microsoft.directory/applications/credentials/update on owned app registrations, and microsoft.directory/servicePrincipals/credentials/update on owned enterprise applications.

Those two entries are the whole story. An owner can add a client secret or certificate to the thing they own. With that credential they can authenticate as the application itself, and the tokens they get back carry every application permission the tenant has consented for it. No interactive sign-in, no approval step, no trace that looks unusual.

So a user with no directory roles at all, who owns a service principal holding Mail.ReadWrite.All, can read and write every mailbox in the organisation at a time of their choosing. Nothing is misconfigured. Every part of that sequence is a supported, documented feature working exactly as designed.

Where governance meets how the system actually works

Every governance framework worth following asks you to establish accountable ownership for the identities in your environment. It is sound advice and you should follow it. But the frameworks describe ownership as a label, and directories implement ownership as a capability, because a directory exists to decide who may change what. The two words are the same and the meanings are not.

That gap produces three practical collisions, all of them visible in Microsoft’s own documentation.

You cannot name the team

Responsibility in a real organisation sits with a team. Entra will not accept one: users can be assigned as owners of enterprise applications, but groups cannot be. So the governance answer is Platform Engineering and the only recordable answer is one named individual. Every register that says a team owns something is describing a relationship the directory cannot hold.

The record and the grant are the same field

Because there is one field, documenting accountability and granting escalation are the same action. Assign an owner for audit purposes and you have handed that person the ability to mint credentials for the application. Leave the field empty to avoid that and you have an ownerless app, which is its own finding. There is no configuration that satisfies both readings.

Microsoft’s recommended mitigation makes the tension sharper rather than softer. Their guidance is to maintain at least two owners per application, so ownership survives a departure. That is good operational advice and it also doubles the number of people who can authenticate as the app.

When the owner leaves, the record leaves with them

People change jobs. Ask Microsoft what to do about an application whose owner has left and the documented answer is to go to the audit log and look for other users who might have been involved in configuring it — while noting there are limits on how long audit logs are retained. Your accountability record for a production identity has become an archaeology exercise against a log with an expiry date.

The same documentation recommends using the serviceManagementReference property on the application object to reference team contact information from your enterprise service or asset management database, so that you still have a team contact even if an individual leaves.

Read that again as an admission and it is remarkably candid. The directory cannot express durable, team-level accountability, so the advice is to store a pointer to somewhere that can. It is the right advice. It also concedes that governance ownership and directory ownership are two different records, and that only one of them belongs in Entra.

Most organisations never populate that property. The ones that do usually find it holds a stale ticket number and nothing that would help at three in the morning.

Two records, kept apart on purpose

AIRM treats governance ownership and directory ownership as separate things, because they are.

Governance ownership lives in AIRM. You assign an accountable team, a named business owner and a technical contact, the purpose the identity exists for, and a review cadence. That record grants nobody any access. It survives a departure, because a team does not resign. It is the thing you hand an auditor, and it is the thing that tells an on-call engineer at 3am who to wake when an agent starts behaving strangely.

Directory ownership stays where it is, in Entra, and AIRM watches it as a risk signal rather than as evidence of good governance. We resolve what each owner could actually do if they chose to: their effective privilege is their own roles combined with the full application permission set of every service principal they own. A non-administrator owning an identity with tenant-wide write scopes is surfaced as a finding with the specific scopes named, because that is a privilege escalation path regardless of whether anyone intends to use it.

Then we look for the disagreements between the two records, which is where the interesting findings live. The agent whose governance owner left in March while their Entra ownership stayed behind. The identity with a diligent register entry and no directory owner at all. The service principal that four people own, three of whom have no idea they do.

None of that is exotic. It is the ordinary residue of a real organisation running real systems, where people move teams, projects get handed over, and the field that was filled in to close an audit finding two years ago is still quietly granting someone the keys to every mailbox.

← Back to the blog