Skip to content
Run it

Permissions and what Beacon can see

The account Beacon runs as, what it inventories, the fields a decision records, and the boundary between observation and enforcement, so a security review can start from facts.

Most of a security review is one question: what does the agent read, and where does it go. This page answers that for the deployment described in Rolling out Beacon.

The account it runs as

On Windows, a virtual service account: NT SERVICE\AlyriaBeacon, managed by the Service Control Manager, with no password to rotate and removed when the service is removed. Program files live in %ProgramFiles%\Alyria with SYSTEM and Administrators full control and Users read. Device state lives in %ProgramData%\Alyria, protected so that the service account owns it.

On Linux, the system users _alyria and _alyria-gw with the group alyria, and the directories /var/lib/alyria (0700), /run/alyria (2750) and /var/log/alyria (0700).

On macOS the agent runs as a launch daemon, and its system extension carries the endpoint security and network filter entitlements you approved in the profile.

It is a user-space agent. There is no kernel driver, and on Windows no minifilter.

What it reads

Inventory is a catalog lookup, not a disk crawl. For each tool family it knows, Beacon checks specific locations and records what it finds:

  • Installs and versions. Known install paths, binaries and package names, so it can report the version and whether it is down-level.
  • MCP server entries. The client configuration files that describe a tool's MCP servers. Beacon takes the server names and the transport.
  • Provider signals. Environment variable names that indicate a provider is configured, such as ANTHROPIC_API_KEY. Presence, not value.
  • CVE posture. Known exposure for the versions it found, which is what beacon status reports.

The service account needs read access to those configuration paths for every user profile that runs agents. Grant that explicitly if your baseline does not already allow it, and nothing more.

What it does not read

  • No conversation content, prompts or model responses are collected as content.
  • No file contents outside the configuration locations above, and no index of your source trees.
  • No keystrokes, screen capture or clipboard.
  • No packet payloads. Egress decisions are allow or deny on the connection, not a copy of what crossed it.

What a decision records

A decision carries the fields the rule matched and the outcome: the policy bundle version, the disposition, the rule id, the severity, an optional rationale reference, the enforcement action, and a reference to the detection it acted on. Detection evidence is redacted and digest-only: codepoint categories and counts, pinned and observed fingerprints. The record is written to be shareable with an auditor without carrying the payload that triggered it.

MCP servers have identities

An MCP server is not trusted because it is named. Beacon pins each server's tool definitions per tool, so a changed description or a new tool appearing under an old name shows up as a detection with the pinned and observed digests attached. From the console you can accept the new fingerprint, reset one pin, or repair a store that has been tampered with, and each of those actions is itself recorded.

The three planes

The planes are opt-in and start in monitor mode:

  • Plane A, inference. Every model call evaluated by the local policy service. Lyra decides the model, the redaction and whether the call proceeds, locally, offline.
  • Plane B, runtime observation. Process and configuration telemetry from user space, which is how Beacon sees an agent that never touches a gateway.
  • Plane C, egress. Allow or deny for outbound connections and data egress, with secrets injected from Umbra as short-lived leases rather than stored on disk.

Where the network boundary is

Two things get called the gateway, so keep them apart:

  • Egress decisions (Plane C) are allow or deny for outbound connections. Beacon sees the connection, the destination and the outcome. It does not collect payload.
  • The local inference gateway is a loopback relay. When a client is routed through it, it handles the request it relays, so it sees the model and the request metadata. Traffic that never goes through it is not relayed and not inspected.

Neither one terminates TLS it did not originate.

What to grant, in one list

  • Read access to the tool configuration paths for each user profile that runs agents.
  • Egress to your Observatory and mesh endpoints.
  • On macOS, the approved system extension plus full disk access and network filter profiles, pushed as configuration.
  • Nothing else. Beacon does not need domain administrator rights and does not install a kernel driver.
← Back to docs