An auditor asks who can change a customer's credit limit. Not who did, but who can, and in Dynamics 365 that answer is spread across the security model.
It comes through a security role, a team someone joined years ago, a business unit, a manager in the hierarchy, or a column security profile. By hand, you open the role editor, one role at a time.
In the demo environment, thirty principals can write credit limit. Most are Microsoft's own service accounts, on the list because they hold the privilege. A marketing connector that was never given the role directly gets write twice: through the sales team, and through the hierarchy, as the ERP sync's manager.
The path is a direct role, a team, or the hierarchy. The scope says how far it reaches: Org is every record in the environment, BU + children is their business unit and everything beneath it, User is only their own records and those shared with them. Credit limit isn't column-secured, so table-level write reaches it; if it were, Pathix would narrow this list to the people holding a profile.
One Pathix call returns the thirty principals, and the path each one took. With the Dataverse MCP alone, your agent reads roles, teams and business units, and works out the hierarchy itself.
A read-only metadata scan of your environment that reads the logic inside the components: compiled plugins, flow definitions, workflow XAML and scripts.
How it works →Or check it by hand: the integration account problem→All questions →
The detail behind the answer, for the reader who needs it.
Every privilege in Dataverse carries a scope, and the scope is what decides whether a grant is routine or a problem. The same privilege on the same table means one record or the entire environment depending on it, so Pathix reads the scope on every grant rather than reporting that the privilege exists.
Their own records only.
Every record in their business unit.
Their business unit and everything beneath it.
Every record in the environment.
These are the platform's own depth names, the values a role actually stores. The classic role editor labeled the same four User, Business Unit, Parent: Child Business Units, and Organization, and Pathix shows them as User, BU, BU + children and Org.
A Local or Deep scope means nothing until you know where the principal sits in the tree and who reports to them. Pathix walks the business-unit structure and the manager hierarchy, and it applies the platform's documented depth cap on that rollup rather than implying the walk goes on forever.
Access reached through a team is identical in effect to access held directly, and it is the path that survives an offboarding checklist. Pathix resolves both and labels which one a given grant came through, so a review can tell a decision from an inheritance.
All of it read-only, through the documented API, by an application user holding a least-privilege role Pathix ships and documents.
Every role, every privilege it grants, and the scope of each grant: Basic, Local, Deep, Global, or Filtered, the depth Dataverse sets with a record filter. The scope is the part that decides whether a privilege is routine or a problem.
Users, application users (the integrations), and teams, each with its type and its enabled or disabled state. Disabled is tracked because a disabled account that still holds roles is one of the conditions worth catching.
Roles held directly, and roles reached through a team. Both paths grant the same access, and the team-mediated one is the path access reviews miss.
The business-unit tree and the manager hierarchy that widens a Local or Deep scope into real reach. The hierarchy rollup has a documented depth cap, which Pathix applies rather than pretending the walk is unbounded.
Which columns are secured, which profiles grant read, update or create on them, and who is a member of each profile.
Share counts and the tables shared, in aggregate. Pathix never stores which records were shared: that question is a deliberate handoff back to Dataverse, and the boundary is a design decision rather than a gap.
The environment-level switches that change what the rest of this means, including audit configuration and hierarchy settings.
How Pathix itself is deployed and constrained is on Security, and what it stores about your principals is on Your data. Filtered grants, the fifth privilege depth, are covered in the record filter guide.
Permissions and dependencies are kept as two separate projections and never merged into one edge. A role that grants write access to a column is not a writer of that column, and letting a permission appear in a dependency list as though it were would create exactly the confusion an access review exists to remove.
The single point where they touch is a runtime access grant: logic that programmatically shares a record is an action rather than a permission, so it is recorded as an edge, and only on the security projection.
Pathix reads the security model as it was configured at scan time and resolves what a principal is able to reach. It did not observe a request being allowed or denied, and an answer here is a statement about configuration, not about something that happened.
Manual record shares come back as counts and the tables involved. Pathix never stores which records were shared. That question belongs to Dataverse and is a deliberate handoff, which is also why a permissions review here cannot leak record contents.
The answer reflects the environment as of the scan that produced it. A role assigned an hour ago shows up on the next scan, and the view says which scan it came from rather than implying it is live.
Resolving access is the investigation. Every scan also runs the deterministic checks over the same model without being asked: a role shared between a human and an integration, a disabled account still holding its roles, an integration able to rewrite the security model, a column secured with nothing granting access. Those are cataloged as findings, with the control they map to, rather than repeated here.
A 30-minute walkthrough on a pre-scanned demo environment. No access to your tenant, nothing to install.