Skip to content
Run it

Rolling out Beacon

Push the signed agent with your MDM, enroll each host with a token from your tenant, confirm the first inventory, and stay in monitor mode until the data supports enforcement.

Beacon is a signed local daemon for Windows, macOS and Linux. A rollout is three moves: hand your MDM a package and an enrollment token, confirm the first hosts report their inventory, and keep everything in monitor mode until the inventory and the decisions look right.

Before the first host

  1. A tenant, and the Observatory URL your fleet reports to.
  2. An enrollment token issued from the console. Tokens are single-use and short-lived, and enrollment establishes the device identity. Nothing standing is stored on the endpoint.
  3. The signed installer. A single machine fetches it from https://get.alyria.ai/beacon; a fleet mirrors the same package into your software channel so your MDM can push it.
  4. A first ring. Five to ten machines you can walk to, not the whole fleet.

Windows

Push the signed MSI from that installer with two properties:

msiexec /i alyria-<version>-windows-x64.msi /qn OBSERVATORY=https://observatory.example ENROLLMENTTOKENFILE=C:\Windows\Temp\alyria-enroll.key
  • OBSERVATORY is the tenant endpoint the device reports to.
  • ENROLLMENTTOKENFILE is a path to the token file. Passing it as a file keeps the token out of the command line and out of the installer log.

The installer runs as Administrator. It creates the AlyriaBeacon service under a virtual service account, puts program files in %ProgramFiles%\Alyria and device state in %ProgramData%\Alyria. Then, on the host:

beacon verify
beacon status

beacon verify checks the binary signature and version. beacon status prints the inventory it found: the AI CLIs and tools on the machine, their versions, whether any are down-level, and any known CVE exposure.

macOS

Distribute the signed agent and its configuration profiles with your MDM. The agent's deeper observation runs in a system extension, so the rollout also approves that extension and grants the privacy preferences it needs, full disk access and the network filter, as profiles. Approve them in the same push; an extension waiting for a user click is a device you think is covered and is not.

Then confirm from the terminal:

beacon verify
beacon status

Linux

Install the package from your repository, then enroll from a root-owned token file:

sudo beacon connect \
  --tenant acme \
  --enroll-token "$(cat /root/alyria-enrollment.key)" \
  --mcp https://acme.mesh.alyria.ai
sudo systemctl status alyria
beacon verify
beacon status

One machine, no MDM

For a developer laptop or a fixture:

curl -fsSL https://get.alyria.ai/beacon | sh
beacon verify
beacon connect \
  --tenant acme \
  --enroll-token "$ALYRIA_ENROLL_TOKEN" \
  --mcp https://acme.mesh.alyria.ai

Confirm the host is in

Three checks, in this order:

beacon verify                                            # signature and version
beacon status                                            # inventory and CVE posture
beacon policy test --input ./samples/mcp-call.json       # the decision a policy would make

Compare beacon status with what the console shows for that device. If they disagree, stop and fix it before you add a second ring; a device whose inventory is wrong cannot be governed correctly.

Then check the parts that only appear over time: sessions, MCP servers, and decisions. Assignments in the console show where rules apply and the deployment status per device, which is the view to watch across rings.

Monitor first

Beacon deploys read-only. Installing it inventories and observes; nothing is enforced and nothing is intercepted. Policies that do make decisions start in monitor mode, where beacon records what it would have done without blocking, locally, deterministically, offline, with no round trip to the cloud.

Every tenant also receives the Alyria managed baseline of rules, reconciled into monitor mode. Promoting a rule to enforce is an admin decision in the console, and that reconciliation never overrides a rule an admin set to enforce or off.

The sequence that wastes the least time:

  1. One ring, monitor only.
  2. Read the inventory on two or three hosts. Confirm the tools your teams actually run are listed.
  3. Leave it a week. Read the decisions, not the dashboard counts.
  4. Promote the rules you have evidence for, one category at a time, and add the next ring.

Rolling to the next ring

Reuse the same enrollment flow and the same policy. What changes per ring is coverage and enforcement, not configuration. Watch three things before you widen: devices that enrolled late, MCP servers found on the ring but not expected, and decisions with a disposition you did not plan for. Anything in that list is a conversation with the team that owns the machines, not a console setting.

← Back to docs