The short version

  • An agent's real reach is its effective permissions, not the list on its app registration.
  • Effective permissions come from several places at once: direct grants, inheritance, groups and the identity it runs as.
  • Work out the whole path before go-live, and again after every change.
  • Stop inheritance where it is not needed, and grant at the narrowest point that works.
  • Compare what the agent was granted with what it actually used, then remove the rest.

Effective rights, then

On a NetWare file server, access to a folder rarely came from one place. A user might hold a trustee assignment on the folder itself, inherit rights granted higher up the tree, receive more through group membership, and gain everything a colleague had through security equivalence. The rights that mattered were the effective rights: the sum of all of them, less anything an inherited rights filter blocked.

Most of the access problems we untangled in that era had the same shape. Nobody had granted the wrong thing on purpose. Several reasonable grants, made years apart by different people, added up to something nobody intended.

Effective permissions, now

An AI agent in Microsoft 365 has exactly the same problem, at far greater speed. Its reach is the sum of its application permissions, any delegated access it uses on a person's behalf, the groups and roles its identity belongs to, and the sharing already in place on the content it can see. An agent that summarises a SharePoint site with delegated access inherits every stale sharing link and generous group that person has accumulated.

The difference is that an agent acts on what it can reach, quickly and at scale, and it can be instructed by the content it reads. A permission nobody noticed for years becomes a path someone else can use in minutes.

Work out the path, not the grant

  • List every source of access: application permissions, delegated scopes, directory roles, group memberships and sharing on the content itself.
  • Trace the effective result for the data the agent will touch, not just the permissions on its registration.
  • Grant at the narrowest point that works: a named site rather than every site, a scoped mailbox rather than every mailbox.
  • Stop inheritance where it is not needed. A dedicated site or library for agent work is often simpler than filtering a busy one.
  • Keep the agent's identity separate from people's accounts, so its effective permissions can be reasoned about on their own.

Measure what it actually uses

Assigned permissions describe what an agent could do. Sign-in and audit logs show what it did. After a few weeks in production, compare the two and remove what was never used. We did the same with file server rights thirty years ago, for the same reason: unused access is only ever useful to the wrong person.

What we would do differently

Start with the data, not the agent. Decide which sites, mailboxes and records the job genuinely needs, then build the narrowest identity that reaches exactly those. Working backwards from the data makes the effective permissions obvious.

Planning an agent that needs access to your data?

Talk to an engineer