See Who Can Access What, and Why ​

October 3, 2026 · InfraScout Team

Visibility in InfraScout is built from Entra security groups. Agent groups pass their visibility on to the agents they contain, and workflows run under their own service accounts. Each piece is simple. Put together, they make "who can actually run commands on this domain controller?" hard to answer from the shield editor alone. Access Paths answers it directly. It shows every path that grants access, one hop at a time, from the person or service account to the resource. It works the other way round too: pick a user and see everything they can reach.

Access Paths is for administrators only, and it is read-only. It explains access and changes nothing. You still change access in the shield editor, as before.

Who Can Access This? ​

Every agent, agent group, playbook, tool group, AI provider and Entra connector now has a Who can access? button next to its visibility shield. It opens a panel with that resource already selected. The panel draws the answer as a graph, with a text list beside it that says the same thing in words:

person or service account → Entra group → agent group → resource

Each path is labeled with how it grants access. A group can be named on the resource directly, or reach it through an agent group or a custom tool group. Everyone grants access to the whole tenant. Each Entra group lists its members, along with the role each person was last seen with. Hover over a node to highlight only the paths that go through it. This is the fastest way to tell why one person shows up on a server you expected to be locked down.

The panel also shows access that never goes through the resource's own visibility list, because it still counts:

  • Workflow pins. A workflow that uses an Entra connector or an AI provider uses it under its service account, without a visibility check. The panel shows this as a workflow pin, linked to that service account.
  • Default and memory rollup connections. The tenant's default AI provider serves every workflow that doesn't name its own provider. The memory rollup connection processes every user's memory. Both carry a badge saying so.
  • Custom tool groups. A custom tool group gives anyone who can see it the tools of the groups it includes. The panel shows that as an extra hop.
  • Administrators. Admins bypass visibility entirely. They are listed in a separate section, so they never hide inside a group.

Paths that don't currently grant access are still shown, with a label that explains why. Blocked means the agent has block inheritance turned on. Pending approval means the agent is waiting in the approval queue, and its paths take effect once you approve it. Drift means a grant is still in effect on an agent although no current agent group explains it any more. It is highlighted, because that access is real until InfraScout cleans it up.

What Can They Reach? ​

The Users tab under Roles has a new What can they reach? button in each person's row. It opens the same panel from the other direction. There is one tab each for agents, agent groups, playbooks, tool groups, AI providers and Entra connectors, and every resource on a tab comes with the paths that grant it.

On the Agent and Tool group tabs, paths are grouped by grant, so a user with access to hundreds of agents doesn't get hundreds of nodes. You see one node per grant instead, such as "48 agents · via Windows Servers". Select it, and the list beside the graph shows exactly those 48 agents. This makes it easy to spot the one broad grant that gives someone more than you meant to.

For a user seen as an administrator, every resource is listed, because the Admin role bypasses visibility. The list also shows the paths their groups grant. Turn on Without the Admin role to see what they would keep if you removed the role. That is the question an access review usually asks next.

What the panel shows matches what InfraScout enforces. If a user appears under "Who can access?" for a resource, that resource appears under "What can they reach?" for the user, and the other way round. Both views are built from the same visibility rules that decide what the user sees when they sign in.

Where the Data Comes From ​

Every answer shows when Entra groups last synced. Two limits are worth knowing:

  • Only direct group members count. Nested Entra groups are not expanded, either in Access Paths or in enforcement. A person who belongs to a group only through another group does not get access.
  • Roles are as last observed at sign-in. InfraScout records each person's role when they sign in to the portal or connect an MCP client. Recording starts with this release, so anyone who hasn't signed in since shows as role unknown until they do. For the same reason, the administrators section is labeled as observed, not authoritative. Your Entra app role assignments remain the source of truth.

Try It ​

Open any agent on the admin Agents page and select Who can access? next to its shield. Then find your own row on the Users tab and select What can they reach? to check that the two views agree. Access Paths covers both views in detail. Groups (Admin) explains the visibility model underneath.

Questions or feedback? Reach us at info@infrascout.cloud.