Every scope you take, I’ll be watching you

On why an agent inventory ALONE cannot tell you what your agents can do.

TL;DR

An agent registry tells you that an agent exists and who owns it, which is not the same as knowing what it can do, because capability

lives in the consent grant, an object that ties three parties together where every primitive in your IGA ties only two. Since the entitlements those grants resolve to sit in the IGA rather than in the tenant, the question of whether an agent can do more than the person using it can only be answered with both worlds in the same graph.

_________________________

When we extended our identity data model to cover agents, we added two core node types: one for the agent, and one for the consent grant that lets it act.

The second does the work, and the reason has little to do with agents being a new kind of principal. It is that a consent grant records a relationship between three parties, while every primitive in an IGA records a relationship between two.

The belief worth correcting is that an agent inventory tells you what your agents can do. It doesn’t, and that gap is not a maturity problem a better registry will close.

The agent node is the half you already model

Microsoft hands you agents in two shapes. An agentUser is user-shaped, while an agentIdentity is service-principal-shaped. Strip the branding off both and you have a principal with attributes, a status, and a pointer to a responsible human, which you already model, because a service account is a principal with attributes and an owner, and so is an agent.

This is why a registry answers less than it appears to. It establishes that an agent exists and who owns it, which is a census, and a census does not describe capability.

Everything you already govern is a two-party relationship

Take any primitive in your IGA and look at its shape rather than its name. A group membership is account → group. A role assignment is identity → role. Even segregation of duties is a constraint over pairs: A and B must not both be held. Two endpoints and one edge is the vocabulary.

That vocabulary is complete for a human being. Marco holds the SAP role, and nothing further needs recording, because the subject of the permission and the actor exercising it are the same person. For an agent they are two different parties, and that separation is what the data model has to absorb.

A consent grant has three parties

In Microsoft Graph a delegated permission is an oauth2PermissionGrant entity. Four fields carry the meaning:

• clientId : the agent, the thing acting
• resourceId : the API being acted against
• principalId : the human whose authority is being used
• scope : a space-separated string of what was permitted
• A fifth, consentType, is either Principal, meaning one user consented for themselves, or AllPrincipals, meaning an administrator consented for the entire tenant.

Read the four back as a sentence and you get: this agent, against this resource, on behalf of this human, for these operations. That is three parties where the governance vocabulary holds two, which is why the record cannot sit as an attribute on any one of them.

Marco has 340 entitlements and his agent has four scopes

Let’s make a quick example. Marco is nine years into a finance role, with two internal moves and an acquisition behind him. His identity carries 340 entitlements and in a given week he uses perhaps thirty. Someone builds him an agent to summarise supplier correspondence; it is registered properly, has an owner, and shows a green tick in the inventory. Its grant reads principalId = Marco, scope = Mail.Read Files.Read.All Sites.Read.All.

Four scopes looks modest until you resolve them through the third party. Files.Read.All and Sites.Read.All cover everything Marco can reach, a set nobody has enumerated in months and years, including that old project directory left him access to. The over-provisioning belongs to Marco rather than to the agent; what the agent changes is the utilisation rate, because all 340 entitlements are now reachable at machine speed instead of the thirty a person uses in a week.

The 340 entitlements are not in Entra

Resolving Marco’s four scopes requires something the tenant does not contain. principalId identifies him, and Files.Read.All says the agent reaches what he reaches, but the enumeration of what that actually grants, which applications, which roles, which segregation-of-duties rules he sits inside, lives in the IGA platform. That means SailPoint IdentityIQ, One Identity Manager, Oracle Identity Governance, OpenText, and a decade of home-grown role logic around them, most of it on-premises.

In IAMONES both worlds sit in the same graph: the classic IGA estate on one side, the agents registered in Microsoft Agent 365 on the other, and the consent record as the edge between them. That edge is what makes the traversal possible: from an agent, to the human whose authority it borrowed, to the entitlements that authority actually carries.

Is there an agent that can do more than the person using it?

This is the question that reveals the privilege leakage agent usage can introduce, and neither an IGA nor Agent 365 can answer it alone. An agent can itself be assigned to roles or groups, and that access adds to what it borrows from the person using it. When the sum reaches further than that person, the agent has become a path to access they were never granted.

The bottomline: Agent 365 knows the roles and groups the agent holds. The IGA knows what the person holds. Answering the question means comparing the two. Humans, non-human identities and now agents, answerable together because they are modelled together sitting in the same graph.