Yes, on both. For monitoring-only use, the setting that matters most is the access level you give the server, covered at the end.

Linux. The packaged agent runs as root. Create a dedicated user and either change the systemd unit with "systemctl edit netxms-agent":

[Service]
User=nxagent
Group=nxagent

or let the agent drop privileges at startup, with this in nxagentd.conf:

UserId = nxagent
GroupId = nxagent

Use the systemd route if the user needs extra groups, such as adm for reading logs, because the agent applies only the primary group. Either way, this user needs write access to the agent's log file and data directory. CPU, memory, disk, filesystem, network and process metrics keep working. You lose SMBIOS hardware data (serial numbers, memory modules, etc.) and ICMP from the ping subagent, and the agent can only read files and logs that this user can read.

Windows. The installer always creates the service under LocalSystem, but the agent works under a limited account if you change it in the service properties afterwards. The account needs rights on the agent's etc, log and var folders. Anything that needs administrator rights stops working, such as System.Restart, and per-process metrics such as CPU time and I/O will quietly return 0 for processes of other users.

Both. Give the server read-only access and use an outbound tunnel, so the agent has no open port:

Servers = netxms.example.com             # read-only, remove the MasterServers line
ServerConnection = netxms.example.com    # outbound tunnel to the server
ListenPort = 0                           # no inbound listener

With this the server can read metrics, but it can't run actions, edit the agent's config, deploy policies or write files. The tunnel has to be bound to the node on the server side.

Note: the installer writes MasterServers, which is full access, so that line has to be removed. All config changes are then made locally on the host.