An Agent Waiting for Approval Should Not Be Invisible

August 14, 2026 · InfraScout Team

A bulk enrollment key requires by default that each host it enrolls be approved before it joins the fleet. That is the right default for a rollout you did not personally run on every machine — but the quarantine it creates had three sharp edges, and a host caught by all three could sit in limbo for days without anyone noticing.

They were invisible, not merely filtered

Agents awaiting approval were excluded from every list and every count by default. The only way to see one was to already suspect it existed and pick Pending Approval out of the status dropdown. No card, no count, no badge — and the existing "approve everything on this page" button could not serve as the hint either, because it was derived from the page you were already looking at. It appeared only after you had found the filter.

Three surfaces now tell you, and they read from one shared count so they cannot disagree:

• The Agents view carries a notice above the filter bar, with a Review action that switches the list to the quarantined hosts.
• The Agent Management navigation tab carries a count badge, so the number stays visible while you are off in Groups or Enrollment Keys.
• The dashboard shows the same notice to administrators, linking through.

One deliberate detail: if the count cannot be refreshed, the last known value stays on screen rather than dropping to zero. The request failed — the agents are still quarantined, and silently retracting a live warning would be worse than showing a slightly stale number.

Approving an agent now actually releases it

Approving a host cleared its quarantine flag and stopped there. Dynamic group membership is evaluated when an agent's stable facts change — its platform, version, hostname, capabilities — and those are written on the agent's first connection, which happens while it is still quarantined and evaluation is deliberately suppressed. Every connection after that compares identical and never re-triggers.

So the one window in which membership could be established was exactly the window quarantine exists to close, and it never reopened. The state was terminal rather than delayed.

That is worse than a missing group. Group membership also drives who can see an agent and which group-scoped commands can reach it, so a freshly approved host was invisible to every non-administrator and unreachable by anything addressed to a group — while heartbeating normally the entire time.

Approval now evaluates group membership before it answers you. A successful approval means the agent is genuinely released, not merely flagged, and that holds for a bulk approval of a whole rollout wave as much as for a single host.

The sixty-second reject storm

A quarantined host reported its inventory every sixty seconds and was refused every time, with an opaque internal error and no explanation. Because the retry clock only advanced on success, the host also ran a full collection — all software, all services, all certificates — every single minute, instead of every six hours. Across a stalled enrollment wave that is a real load on hosts that have not even joined yet.

The refusal now names its reason, and the agent backs off for thirty minutes rather than one, which lines up with how long approval takes to propagate. Instead of an error every minute forever, the agent's log reads:

WARN inventory report rejected by server, backing off  reason="agent pending approval"  retry_after=30m0s

Closing this also closed something quieter. A key that required approval and assigned a static group put the host into that group at provision time — which meant an inventory policy resolved, collection ran to completion, and an unapproved host's inventory was already being ingested. Exactly what quarantine exists to prevent. Inventory ingest was the one agent-facing surface with no approval check; it has one now.

A storming host is fixed by approving it

There is no release ordering to worry about here — an older agent against the updated server simply keeps retrying as it does today. But if you have a host currently reporting every minute, approving it stops the storm immediately, without waiting for its agent to update.

The enrollment directory is hardened

Separately, the directory holding an agent's private key and configuration was created with permissions that mean nothing on Windows, so it inherited whatever C:\ProgramData grants — which lets any local user drop files into it. The key and configuration inside were always individually protected and were never exposed by this; what was missing was the container around them. The rollout scripts hardened it, but enrolling a host directly did not, and that is a supported path.

Direct enrollment now applies the same protection, repairing the directory if it already exists. Two consequences worth knowing before you run it:

• --output-dir now defaults to the platform configuration directory — C:\ProgramData\InfraScout or /etc/infrascout — instead of the current directory. Every scripted path already passes it explicitly, so nothing in a rollout changes. Hand-run enrollment previously scattered private keys into whatever directory you happened to be standing in.
• Unelevated agent enroll now fails rather than quietly writing into the current directory. That is the intended posture — reporting a protected configuration directory that is not actually protected is worse than refusing — but it is a change if you had been enrolling without elevation.

One more thing to expect: on hosts enrolled by hand, the agent's log directory is now readable by administrators only. Script-installed hosts have behaved this way since signed installers shipped; this brings the rest into line.

See Fleet Rollout for the rollout path and Manage Agents for the approval queue.

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