Agent Installation
The Sielum agent is a native Go binary that runs directly on developer workstations — not in Docker. It needs direct access to the host OS to detect processes, network connections, and read AI client configuration files.
Prerequisites
| Requirement | Notes |
|---|---|
| Linux (amd64/arm64), macOS (amd64/arm64), or Windows (amd64) | Cross-platform |
| Outbound network access to Sielum on port 443 | gRPC + mTLS — no inbound ports required |
curl and administrator (sudo) access on the endpoint | Needed by the installer |
Install via the dashboard
The only supported way to install the agent is the install command generated for you in the dashboard. There is no manual binary download or separate enrollment step — the command handles everything.
- In the dashboard, open the Install Agent page (it's also part of the Setup Assistant during onboarding).
- Select the operating system of the endpoint — Linux, macOS, or Windows.
- Copy the generated one-line command. Your enrollment token is already filled in.
- Run it on the workstation you want to monitor.
The command downloads the agent binary, enrolls the endpoint (obtaining a device certificate), writes the configuration, and registers the agent as a system service that starts automatically.
The First Login & Setup guide walks through the whole flow, including where to find the install command and how the first endpoint connects.
Verify the agent is running
After running the command, confirm the service is up:
# Linux
systemctl status sielum-agent
journalctl -u sielum-agent -f
# macOS
sudo launchctl list | grep sielum
# Windows (PowerShell)
Get-Service SielumAgent
Within about a minute the endpoint appears under Endpoints in the dashboard, with detected AI agents under Agents.
Privileged vs. user mode
The installer registers the agent in privileged mode by default, which enables firewall rule enforcement. On workstations where firewall control is not needed, the agent can run in user mode (monitoring only, no elevated privileges).
| Feature | Privileged mode | User mode |
|---|---|---|
| Process monitoring | ✅ | ✅ |
| API connection monitoring | ✅ | ✅ |
| MCP server detection | ✅ | ✅ |
| Config change detection | ✅ | ✅ |
| Config enforcement | ✅ | ✅ |
| Firewall rule enforcement (IPv4 + IPv6) | ✅ | ❌ |
For firewall enforcement on Linux, the agent requires CAP_NET_ADMIN. The systemd unit sets AmbientCapabilities=CAP_NET_ADMIN with CapabilityBoundingSet limiting it to exactly this capability. Firewall blocking is dual-stack: IPv4 rules go through iptables, IPv6 through ip6tables. On macOS, pf handles both address families; on Windows, the Windows Filtering Platform (WFP) does.
Multi-user scanning (service mode)
When the agent runs as a system service, the service account's home directory is not a developer's home. To avoid scanning the wrong directory, the agent automatically detects all active developer home directories:
- Linux/macOS: parses
/etc/passwdand returns all homes for login users (UID ≥ 1000, valid shell, existing directory) - Windows: scans
C:\Users\for existing user directories
Each adapter is scoped to the correct home directory at runtime, so detection, config collection, and enforcement all target the actual developer environment, not the service account.