EDR allow-list for anyray-connect

Everything an endpoint-security team needs to approve anyray-connect: its credential scheduler, the legacy compatibility daemon where present, their file paths, and the network posture — regenerable on any machine with one offline command.

Connect installs a per-user scheduler that extends the same gateway key with a fresh device proof. Older gateways and zero-touch MDM bootstrap can also use the loopback compatibility daemon. Both are unprivileged and run as the signed-in user. What each one is for: Credential heartbeat. What the agent as a whole can and cannot see: the transparency page.

Services and unit files

Service	macOS (launchd)	Linux (systemd --user)	Windows
Legacy compatibility daemon	label ai.anyray.connect.fallback · ~/Library/LaunchAgents/ai.anyray.connect.fallback.plist	anyray-fallback.service · ~/.config/systemd/user/anyray-fallback.service	not installed
Credential scheduler	label ai.anyray.connect.refresh · ~/Library/LaunchAgents/ai.anyray.connect.refresh.plist	anyray-refresh.timer + anyray-refresh.service · ~/.config/systemd/user/	Task Scheduler task \AnyrayConnectKeyRefresh (no unit file — held in the Task Scheduler store)
Service logs	~/.anyray/logs/connect-daemon.log, ~/.anyray/logs/connect-refresh.log	journald	—

The logs capture the services' stdout/stderr and carry error class names only — never request content or keys.

The label still says fallback

Compatibility unit files already on enrolled machines keep the historical spelling — renaming the label would strand every installed unit. The provider-direct lane it was named for no longer exists.

Binaries and process signatures

Install method	Executable path
connect.sh installer (macOS/Linux)	~/.anyray/bin/anyray-connect
npm / npx	a versioned runtime copy under ~/.anyray/bin/
Fleet-managed installs	a fleet-stable path chosen by the admin, typically /usr/local/bin/anyray-connect

Both services launch the same binary with a distinguishing first argument, so their process command lines are:

Process command lines

anyray-connect __anyray-fallback-proxy    # the key-refresh daemon
anyray-connect __anyray-refresh           # the scheduler tick (~every 30 min)

The security-review sheet (below) prints the live executable path for the machine it runs on, so allow-list from the sheet rather than from this table when they differ.

Network posture

State these as properties of the agent, not observations:

• No listener on current direct installs. The scheduler sends only an outbound credential heartbeat to your org's gateway.
• Loopback-only compatibility listener. When needed, the daemon binds 127.0.0.1 exclusively — port 8785 by default, or the next free port. It never binds a routable interface and accepts no remote connections.
• Outbound-only, to your own gateway. The heartbeat and compatibility daemon talk HTTPS to your org's Anyray gateway and nothing else. The daemon relays AI requests byte-for-byte; its single mutation is filling in a gateway key header.
• No privilege, no interception. No kernel/system extension, no CA certificate, no machine-wide proxy or DNS change; everything runs as the logged-in user.

The CLI (not the daemon) additionally reaches app.anyray.ai for enrollment and certificate renewal, and github.com/anyrayHQ/install for self-update downloads — the complete outbound table is on the transparency page.

Regenerate the sheet locally

Print the allow-list from any machine

anyray-connect doctor --security-review

The command is a pure printer: no probing, no gateway, no key. It works on a machine whose services are already quarantined — the machine that needs it — and prints nothing about the seat's traffic.

Why heuristic scanners flag it

To survive a reboot the scheduler must be a login item; compatibility installs add the daemon. On macOS today each login item is an unsigned launchd LaunchAgent with KeepAlive — the same shape a persistence implant uses. Heuristic detections (for example SentinelOne's persistence_deception class) act on the resemblance: the scanner stops the process and quarantines the plist. anyray-connect doctor detects that state and prints an Endpoint security section listing the files that are gone; the recovery steps walk through unblocking the seat. Machines that must run nothing in the background can use anyray-connect --no-key-refresh, which installs no service at all.

Signed tray app replaces these LaunchAgents

The macOS persistence swap is built in and activates only on a signed build of the Anyray Connect desktop app. At startup the app verifies its own bundle — codesign --verify --deep --strict plus a Developer ID TeamIdentifier — and only a build that passes enables its login item and runs anyray-connect __anyray-persistence --adopt-tray. The CLI independently repeats the signature check, then retires ai.anyray.connect.fallback and ai.anyray.connect.refresh and records the app as the persistence owner; an unsigned or ad-hoc-signed build (every development build today, and every build until the signing lane ships releases) never enables autostart and never adopts. The swap changes who launches the background work, not what runs: the app respawns the key-refresh daemon when it dies and triggers the same __anyray-refresh on the same ~30-minute cadence. It also self-heals — if the adopted app is later deleted or stops passing the signature check, the next anyray-connect run (including the ~30-minute refresh tick) reinstalls both LaunchAgents and clears the takeover, so a machine is never left with no launcher. On tray-managed machines the allow-list then shrinks to one signed app bundle, and the unsigned-KeepAlive signature this page works around disappears.