Agents on Routers and Appliances
July 16, 2026 · InfraScout Team
An assessment that stops at the edge of the server estate has a gap where the network usually is. Routers, firewalls, wireless controllers, and purpose-built appliances hold a great deal of what an audit wants to know, and they run Linux — just not the Linux the agent was built for.
Two changes make them reachable.
A MIPS build
The agent now ships for 32-bit little-endian MIPS alongside x86-64 and ARM64. That covers the MediaTek and Ralink-class hardware behind a large share of OpenWrt devices — consumer and prosumer routers, purpose-built network appliances, and the assessment hardware plenty of security teams keep on a shelf.
It appears as a download option in the portal once a release includes the binary, with its own hash to verify like every other platform.
Getting it to build turned up an unrelated dependency that was pulling in a Windows-specific library unconditionally, which fails to compile for MIPS at all. That is now behind a platform boundary — a small fix that also means the non-Windows builds carry less that they never used.
Enroll these with a token
The one-command enrollment path needs an interactive browser sign-in, which is not a realistic expectation on an embedded device. Use the token path for these hosts.
The services inventory stops assuming systemd
Shipping a binary is the easy half. The first OpenWrt host we enrolled connected fine and then flagged every inventory snapshot as partial, because the services collector shelled out to systemctl, and OpenWrt does not have systemd. No systemctl, so an error, so a snapshot marked incomplete — on a host where nothing was actually wrong.
The collector now works out which service manager the host runs and reads it natively:
| Manager | Where you find it |
|---|---|
| systemd | Mainstream server and desktop distributions |
| procd | OpenWrt and derivatives |
| OpenRC | Alpine, Gentoo |
| SysV / BusyBox init | Older and minimal systems |
Detection is done by probing for the binaries and directories a manager actually needs, not by reading the host's distribution identity file. That distinction matters on embedded hardware: a stripped image may not carry a meaningful distribution identity at all, while the files a running service manager needs are necessarily present. Probe order matters too — a systemd marker beats a leftover systemctl binary, and the presence of OpenWrt's message bus alone is not enough to conclude OpenWrt without the init framework beside it.
What each manager can report differs honestly rather than being padded out. Startup type is a Windows concept and stays absent. A SysV host can enumerate its services and which are enabled without being able to report a trustworthy running state, so the status comes back as unknown instead of being guessed at. And a host running no recognized service manager reports an empty service list with a clean snapshot — the honest answer, and no longer a partial-collection flag on a host that simply has nothing to report.
Try it
If you have OpenWrt-class hardware in scope, download the MIPS binary from the Agents page and enroll it with a token. Then ask the AI what services are running across your network appliances and see what comes back.
See Deploy on Linux for the embedded notes, and Inventory Tools for what the services inventory reports per platform. Questions? info@infrascout.cloud.