Enrolling an Agent Is Now One Command
July 19, 2026 · InfraScout Team
Enrolling an agent used to be a transcription exercise. Open the dashboard, create an enrollment token, copy the token, copy the tenant ID, copy the agent ID, copy the enrollment URL, copy the gRPC address, assemble a six-flag command on the target host, run it, then install the service as a second step. Two of those values are UUIDs. Get one character wrong and the failure arrives several steps later.
There is now a shorter way:
sudo infrascout-agent enroll auto --api https://api.infrascout.cloudThat is the whole command. It signs you in, provisions the agent, enrolls it, installs the service, and starts it.
How the sign-in works
Running it prints a short code and a URL. Open the URL on any device — your laptop, your phone, whatever has a browser — enter the code, and sign in to Microsoft Entra ID as you normally would, MFA and Conditional Access included. This is the device authorization flow, the same one you have used to sign a TV or a console into a streaming service, and it exists precisely for the case where the machine needing access is not the machine with a comfortable browser on it.
The account you sign in with has to hold the InfraScout Admin role. That is checked server-side, so a sign-in without it is refused before anything is provisioned rather than leaving a half-created agent behind. If the token is simply invalid you get told that instead — the two failures used to produce the same message, which sent people looking at role assignments when the actual problem was an expired session.
Once signed in, the agent asks the server where to enroll and where to connect afterward. That is why --api is the only value you supply: the addresses were always derivable from the server, and there was never a good reason to make a human carry them.
What is not written down
The access token from the sign-in and the enrollment material both live only in memory. Neither is written to disk. Neither is logged. When the command finishes, what remains on the host is the agent's own certificate, key, CA chain, and configuration file — the same output a token enrollment produces, and nothing more.
A couple of safeguards are worth knowing about because they concern how the service ends up running.
The enrollment URL has to be HTTPS, with loopback exempt for local development, and that check now applies to the token path too. Where you supply your own CA bundle, it is added to the system trust roots rather than replacing them, and it never applies to the Entra sign-in — that always uses the system roots, because a custom trust anchor has no business influencing where your credentials go.
And re-running against a host that is already enrolled does the safe thing. An installed service is stopped and re-registered with the configuration that was just written, so a host can never quietly keep running under an old identity pointing at a different directory. On Windows that involved a genuinely annoying race — the service manager marks a removed service for deletion and then rejects the reinstall with an unhelpful "already exists" — so the command now waits for the deletion to actually complete before installing.
Put the binary somewhere only root can write
This applies to both enrollment paths and matters more than it looks. Service installation registers the binary at its current path and then runs it with full system privileges. Enroll from a home directory or a downloads folder and you leave a privileged service executing a file that any local user could replace. Move the binary to a root-owned location first — /usr/local/bin or the equivalent — and enroll from there.
The portal hands you both commands
The download dialog used to offer binaries and then stop, which left a gap: you had the file and no obvious next step, because the only enrollment snippet in the portal lived on a different screen and needed a token you had not created.
It now generates the complete sequence. Pick your platform and architecture and you get two separately copyable blocks — one to download the binary, one to enroll it — with your own API address already filled in. The download command matches the platform rather than assuming: wget on Linux, curl on macOS (stock macOS ships no wget, so a wget snippet would simply fail on a clean Mac), and Invoke-WebRequest on Windows. Each binary is listed with its SHA-256 hash so you can verify what you downloaded before running it.
Configuration at enroll time, not afterward
Some hosts need more than an identity. An agent that queries Active Directory needs LDAP settings; one that will host MCP servers needs that enabled and bounded. Both used to mean editing a root-owned configuration file by hand after enrollment, then restarting the service.
Both enrollment paths now accept flags for those settings, so they are written as part of enrollment. The LDAP bind password is encrypted before it ever touches disk, and the flag combination is validated before the sign-in, so a typo in an option costs you a re-run rather than a wasted enrollment.
For hosts already in the field, every operator-modifiable setting now has its own command as well — infrascout-agent ldap set, infrascout-agent mcp-proxy set, infrascout-agent config set debug — each of which writes the value and restarts the service, with a flag to stage the change without restarting. A write that changes nothing skips the restart entirely, because bouncing a live connection to a production host over a no-op is not acceptable.
The identity fields are deliberately excluded from that. There is no setter for the server address, tenant ID, agent ID, or certificate paths: changing an agent's identity is what enrollment is for, so re-enroll rather than editing your way there.
Try it
Open the Agents page in the portal, click through to the download dialog, pick your platform, and copy the two commands. Move the binary somewhere root-owned first, then run the enrollment command and sign in when it prompts you.
The token path is still there and still supported — for unattended image builds, embedded hosts with no practical browser path, or deployments where whoever runs the installer does not hold the Admin role. See Deploy on Windows, Linux, or macOS for both. Questions? info@infrascout.cloud.