Group & Domain Management is where SITEY turns a flat list of machines and web addresses into named sets that the rest of the platform can address.
An agent group is a named collection of installed SITEY agents. A domain group is a named list of domain names that web scanners take as targets.
Scheduled scans, bulk scans, autonomy policy scope and the mutation kill switch all point at these groups instead of at individual hostnames. So the grouping you do once becomes the control surface for everything downstream.
The problem
Without grouping, every operation is a list of hosts somebody pasted by hand. The 2 a.m. scan window targets a spreadsheet snapshot from three months ago. When a new domain-controller is built, nobody remembers to add it to the weekly authenticated scan, and it stays unscanned until an auditor finds it. When you want automated patching enabled on the lab but not on the payment estate, there is no object in the system that means “the payment estate”. So the choice becomes all machines or none, and most teams pick none.
The same gap shows up in reverse during an incident. A change breaks something on one segment and you want to stop automated remediation on just that segment while keeping the platform diagnosing everywhere else. If the only switch is global, you pay for one segment’s problem with blind coverage across the whole fleet.
How it works
- Build a group from what is already discovered
The group builder lists every agent the platform knows about, with hostname, IP, OS and online/offline status. You filter by all, online, offline or unassigned, search by hostname, IP or OS, select the hosts you want and give the group a name. Group names are compared exactly: a second group with an identical name is rejected rather than silently merged, while two names that differ only in capitalisation are treated as two separate groups. Online and offline here mean the agent’s last check-in measured against a configurable liveness threshold, not a live connection test at the moment you look.
- Membership is validated, not trusted
Every agent identifier written into a group is checked against the agent table first. Unknown identifiers are rejected with an explicit error instead of being stored as dead membership rows. Membership is therefore limited to hosts that already have a registered SITEY agent: a host that has only been seen by network discovery, with no agent installed on it yet, cannot be saved as a group member. This matters because group membership is the input to autonomy scope: a group padded with identifiers that match nothing would quietly blur the boundary of what automation is allowed to touch.
- Edits apply as a difference, not a rebuild
When you save a changed membership list, the platform adds only the members that are new and removes only the members you dropped. It does not clear the group and re-insert it. That detail is deliberate: a delete-then-recreate pattern leaves a window in which the group is empty, and any policy or kill switch scoped to that group would briefly have no members.
- Groups become scan targets
A scheduled scan is attached to one group and a set of scanner tools. When the schedule fires, the scheduler resolves the group to its current members, keeps the ones that are online at that moment, and creates one scan job per agent per tool. Nothing is pinned to the host list that existed when the schedule was written, so a machine added to the group yesterday is included the next time that schedule fires. Members that are offline when the schedule fires are skipped for that run and noted in the server log only, so read a schedule as covering whatever is reachable at that hour rather than as a guarantee of full group coverage. Bulk scanning lets you pick several agent groups and several tools in one action and records a scan job for each group and tool pair, and it includes two built-in virtual groups, resolved live from the operating system each agent reports.
WindowsLinux - Domain groups feed web scanning
Domain groups are created by pasting a list of domains: comma, tab or whitespace separated. Each domain then appears in the asset list as its own entry of type domain, and counts toward total assets alongside agents and discovered hosts. On the scanning screen you pick a domain group and launch web scans against every domain in it. Some scanners take the whole list as a single scan, others are run once per domain, depending on the tool.
What you can do
Create, rename, re-scope and delete named agent groups, with membership validated against registered agents.
Filter and search the candidate host list by status, hostname, IP or OS while building a group.
See per-group online and offline counts, and a fleet-wide coverage figure showing what share of agents and discovered hosts belong to at least one group.
Find ungrouped machines with a dedicated unassigned filter, so new endpoints do not sit outside every policy unnoticed.
Attach a recurring scan schedule (daily, weekly, monthly or cron) to a group and let it resolve members at run time, targeting the ones that are online when it fires.
Queue a bulk scan across several agent groups and several scanners in one action, including the built-in Windows and Linux virtual groups.
Scope an autonomy policy to specific groups, so automated remediation applies to the estate you chose and nowhere else.
Stop mutating remediation for selected groups while diagnosis continues, without disabling autonomy globally.
Preview a policy’s real reach before saving: how many agents fall in scope, how many are exempt, how many would actually be changed, and a warning when non-test machines are included.
Maintain domain groups as reusable web-scan target lists, and remove a domain together with its associated vulnerability and scan records.
Reach any group directly from the sidebar, which lists your custom groups as navigation entries.
Who it is for
who own the segmentation and need scan windows that follow the estate rather than a stale host list
who need to narrow or widen automated action during an incident without touching the global switch
rolling out automation gradually, lab first, then staging, then a production segment at a time
who need a defensible answer to “which parts of the estate are under automated remediation, and which are not”
who need scan scope expressed as named environments they can describe in an audit rather than as IP lists
Why it matters
Grouping is what makes the rest of the platform safe to switch on.
The realistic path to autonomous remediation is not a single decision. It is a sequence of small, reversible ones, and each of those needs a named boundary to apply to. A group gives you that boundary, plus the ability to take it back: scope a policy to one group, watch it, then add the next.
It also removes a recurring class of silent failure. A host that belongs to no group is a host that no schedule scans and no policy covers, and it will not announce itself. The unassigned filter and the coverage figure turn that invisible gap into a number on screen. And because schedules resolve membership at run time, onboarding a machine into a group is the single action that enrolls it in every scan cadence attached to that group: no second step, no forgotten checklist item.
Works with
- Agent Management, the agents that become group members are deployed and monitored here
- Asset Inventory, agents, discovered hosts and domain-group entries all surface as assets
- Scan Management, schedules and bulk runs that take a group as their target
- Autonomous Operations, policy scope and the group-level mutation kill switch
Frequently asked questions
Can one machine belong to several groups?
Yes. Membership is stored per group-and-agent pair, and scope matching looks for any overlap between a host’s groups and the groups listed on a policy or kill switch. A host in any one of the listed groups is in scope. This lets you keep an OS-based grouping and an environment-based grouping over the same machines.
Who is allowed to change groups?
Creating an agent group, changing its membership, and deleting it all require an administrator account. This is deliberate: because group membership decides where automated changes may run, allowing a read-only account to empty a protected group would defeat the controls sitting above it. Reading the group list is available to any signed-in user. Domain groups follow a different rule today: any signed-in user can create or delete a domain group, while removing an individual domain entry requires an administrator, because that action also deletes the vulnerability and scan records attached to that domain.
Do groups control who can see which data?
No. Groups scope automation and scan targeting, not visibility. Any signed-in user can read the group list. If you need to restrict what different people can see and do, that is handled by roles and permissions, not by group membership.
What happens when I remove an agent from a group?
Only the membership record changes. The endpoint agent stays installed and keeps reporting; nothing is uninstalled and no history is deleted. What does change is scope. If that group was the target of an autonomy policy or a mutation kill switch, the host leaves that scope immediately, so it is worth checking policy coverage after a large re-grouping.
Group & Domain Management is included in every SITEY deployment, running on your own infrastructure alongside the rest of the platform. If you want to see how group-scoped policies, scheduled scans and staged automation fit your estate, the full module set and deployment options are on the pricing page.