Agent Groups
Agent groups let you organize your fleet into logical collections. You use groups to scope assessments ("assess all Linux servers"), control which users can see which agents, and quickly target a category of host without specifying individual agent IDs. Every agent can belong to multiple groups, and InfraScout keeps group membership consistent as your fleet grows or changes. This page explains how groups work; to create and manage them in the portal, see Manage agent groups.
Static Groups
A static group is one you maintain by hand. You create the group in the dashboard under Agents → Groups → New Group → Static, then add agents to it individually. Static groups are a good fit for environment-based collections that don't change often — "Production," "DMZ," or "Finance Department" are typical examples. Because membership is explicit, what's in the group is always exactly what you put there.
Dynamic Groups
Dynamic groups have rules. InfraScout evaluates every enrolled agent against those rules and automatically includes or excludes agents based on their properties. The membership list stays current as agents are enrolled, updated, or removed — you don't have to manage it manually.
Create a dynamic group in the dashboard under Agents → Groups → New Group → Dynamic, then define one or more rules. Each rule tests a specific agent property against a value using an operator.
The agent properties available as rule fields are:
| Field | Description | Example values |
|---|---|---|
os_family | Operating system family | windows, linux, darwin |
os | Full operating system name | Windows Server 2022, Ubuntu 22.04 |
arch | CPU architecture | amd64, arm64 |
version | Agent version | 1.4.0 |
hostname | Host's fully qualified hostname | dc01.example.com |
display_name | Human-readable name set in the dashboard | Primary Domain Controller |
capabilities | Capabilities reported by the agent | powershell, ldap, daemon_start |
os_family and os are distinct: os_family is the broad platform (windows, linux, darwin), while os is the full product name reported by the host, such as Windows Server 2022. Pairing them is how the built-in groups separate Windows Servers from Windows Clients — both match os_family windows, but Servers additionally require os to contain Server while Clients require that it does not.
Rule Operators
Each rule pairs a field with an operator and a value. InfraScout supports the following operators:
| Operator | Meaning | Example |
|---|---|---|
eq | Exact match | os_family eq windows |
in | Matches any value in a list | os_family in [windows, linux] |
contains | Field contains the string | hostname contains .corp. |
regex | Field matches a regular expression | hostname regex ^dc\d+ |
has | Agent reports this capability | capabilities has powershell |
Any operator can be negated. For example, you can express "hostname does not contain .test" or "os family is not windows" using the negated form of the relevant operator.
Match Mode
A dynamic group's match mode controls how multiple rules combine. Set the match mode to "All" and every rule must match — this is AND logic. Set it to "Any" and at least one rule must match — this is OR logic.
For example, to create a group for Windows domain controllers you might add two rules: os_family eq windows and hostname regex ^dc. With match mode set to "All," only agents that satisfy both rules are included. Agents running Linux, or Windows hosts whose hostnames don't start with dc, are excluded automatically.
Default Groups
Every InfraScout tenant starts with five groups that are seeded and maintained automatically:
| Group | Included agents |
|---|---|
| All Hosts | Every enrolled agent |
| Windows Servers | Windows agents running a Server edition |
| Windows Clients | Windows agents running a Client (desktop) edition |
| Linux Hosts | All Linux agents |
| macOS Hosts | All macOS agents |
These groups are system-owned. Their membership criteria cannot be edited, but you can configure visibility on them to control who can see the agents they contain. All Hosts matches every registered agent and always carries the default inventory and update policies, so every agent resolves to a policy even when it belongs to no other group.
Policy Targeting
Groups are also how central configuration reaches your fleet. You never attach an inventory policy or an update policy to an individual agent — you attach it to a group, and every agent in that group inherits it. A group with no policy attached simply doesn't take part in this.
Because an agent can belong to several groups, more than one policy can apply to it. InfraScout resolves the conflict by picking the highest-priority policy among all of the agent's groups, breaking ties alphabetically by policy name. Higher numbers win, and the system default policies sit at the lowest priority — so any custom policy you target at a group overrides the default for the agents in it. This is what lets you, for example, give your domain controllers a tighter inventory schedule while every other host stays on the default.
For the policies themselves and their settings, see Inventory Policies and Update Policies.
On-Demand Inventory Collection
Groups are also a unit for ad-hoc work. Beyond the scheduled cadence, an administrator can trigger an immediate inventory collection for an entire group at once, without waiting for the policy interval to elapse. The trigger reports back which agents were enqueued and which were skipped — an offline host, for instance, is skipped and simply caught up by its next scheduled sweep. A single group-wide collection covers up to 500 agents.
Visibility
Visibility controls which Entra groups can see and interact with the agents in a group. You configure visibility at the group level, and every agent in that group inherits the setting. This lets you give a Windows team access to their servers without exposing Linux hosts to them, for example. Visibility is closed by default: a group with nothing assigned is visible to admins only, and you mark a group Everyone when it should be visible tenant-wide.
An agent's effective viewers are the union of the groups it inherits from every group it belongs to, plus any groups set directly on the agent — so belonging to a broadly visible group widens what a user can see. The one exception is block inheritance: turn that switch on for an individual agent and it stops inheriting from its groups entirely, staying hidden even when a parent group is marked Everyone. Use it for a sensitive host — a pentest VM or a jump box — that happens to sit in a group everyone else can see.
INFO
Visibility applies to agent discovery and interaction — it does not affect playbook execution permissions, which are controlled separately.
For the administration surface and the post-release checklist, see Groups (Admin).