Tool Groups Now Answer to Your Entra Groups

July 30, 2026 · InfraScout Team

Until now, scoping tools to particular teams was only half possible. Custom and external tool groups could be pointed at specific Entra security groups, but the built-in groups — Remote Agents, Microsoft Identity, Defender, and the rest — were tenant-wide: on for everyone or off for everyone. If your service-desk team needed the agent tools but had no business reading Conditional Access policies, there was no way to say so.

Now there is. Built-in groups take the same visibility scoping as everything else, administered from the same shield, and enforced on every path a caller can take.

Do this before you announce the release

External tool groups are created closed, which is the correct default but means non-admins reach zero third-party MCP tools until you scope them. Open Tool Groups, find each external group your users rely on, and attach the security groups that should have it — or mark it Everyone. Do this first; otherwise the first thing your users notice is a capability that quietly went missing.

One scoping model, everywhere

Every tool group now carries the same three-state posture you already know from agents and playbooks: Everyone, scoped to named security groups, or admins only. The shield icon reports which. Attach a group and its members can use those tools; remove it and they cannot.

Four groups are exempt and always available: Sessions, Insights, Persistent Memory, and Chart Display. These are the mechanics of running an assessment and presenting its results, not a reach into your infrastructure — scoping them would break the act of doing an assessment rather than narrowing what one can touch. Every other built-in group is scopable, and that set is wider than the old core list: Remote Agents and Inventory could never be hidden before, and now they can be scoped like anything else.

Membership within a built-in group stays fixed. You decide who reaches the Microsoft Intune group; you do not compose which tools are in it. That is what custom groups are for, and they remain freely composable.

Enforced, not filtered

The distinction that matters is where the scoping is applied.

A scoped-out group's tools are not merely hidden from a picker. They are absent from the tool list a connected MCP client receives, and a call naming one of them is refused before it runs. The AI never learns the tool exists, so it never proposes an action that will be denied.

Refusals are deliberately indistinguishable from each other. A tool hidden by scoping, a tool withheld by your role tier, and a tool name that never existed all produce the same response, and they take the same time to produce it. Anything else would turn error messages into a map of the catalog for anyone with any level of access.

Every check fails closed. A group whose visibility cannot be resolved is treated as closed, not open.

Two behavior changes worth knowing

Groups you had already hidden are now hidden in chat too. Previously, hiding a built-in group removed its tools from what MCP clients saw, but portal chat carried on offering them. That inconsistency is gone: a hidden group is hidden everywhere. If your tenant had groups hidden, your non-admin users lose those tools in chat as well. The direction is safe — this closes a gap rather than opening one — but it is a real change in what people can do.

Third-party tools are now scoped on every path. Custom groups could previously be pinned in a way that fell through to the tenant's full set of external tools, which had the perverse effect that revoking a group's access could yield strictly more tools than granting it. Every path now scopes third-party tools to what the caller can actually see. This is the change behind the warning at the top of this post.

How it stacks with roles

Group scoping and role tier are independent, and a call clears both or it does not run.

Scoping decides which groups you can reach. Your role decides whether you get a group's write-capable tools or only its read-only half. A group shared broadly and containing both kinds offers a standard user the reads and an operator everything.

The practical upshot for administrators is that you can stop maintaining read-only variants of groups. Compose a group around a job to be done, mix read and write tools freely, and let the role tier sort out who gets which half. When someone needs to make changes, change their role.

What to do in your tenant

Scope your external groups first, as above. Then open Tool Groups and review the built-in groups now that scoping them is possible — each one carried over the posture it had, so a group that was visible is still visible to everyone. That is the right migration, but it is a starting point, not an answer: the question "who in this tenant should be able to read Defender data through an AI client" now has a place to be answered, and it is worth answering deliberately.

The Tool Annotations and Role Scoping page covers how the three gates fit together.

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