Where Alyria fits, and where it doesn't
Alyria governs coding agents at the endpoint: the Alyria Beacon sensor inventories every AI tool, MCP server and agent CLI on your Windows, macOS and Linux machines, and its local policy service evaluates Lyra policy on each model, tool and MCP call before it runs, writing every allow or deny into one signed audit chain that exports to your SIEM. It is built for the security or platform team rolling out Claude Code, Cursor, Codex or Copilot to developer workstations.
It is not an EDR and not a general vulnerability scanner, and it cannot control a machine it is not installed on. Below: what has to be in place before rollout, what Alyria does and does not do, and when another tool is the better choice.
Who it is for
Alyria is endpoint and fleet infrastructure for a specific buyer, not an install a developer makes on their own machine. If none of the three profiles below is yours, the alternatives section is the right place to start.
You are rolling coding agents such as Claude Code, Cursor, Codex or Copilot out to developer and operator workstations, and you carry the accountability when a prompt pulled from a repo turns into a production push.
Your machines are in MDM. You can push a signed daemon and a configuration profile, and you want agent governance to live in the same pipeline as the rest of endpoint management.
Engineering leadership wants the productivity. Security leadership wants the receipts. You need one place that shows every agent, every decision, and a signed audit chain you can hand an external auditor.
Prerequisites
What has to be true in your environment before a Beacon fleet is worth deploying.
The Alyria Beacon sensor is a signed, user-space daemon for Windows, macOS and Linux. Install it with your MDM, such as Jamf or Intune, or through your normal package pipeline, the same way you push any configuration profile. It deploys read-only and every enforcement plane starts in monitor mode under the configuration your MDM pushes.
Claude Code, Cursor, Codex, Copilot, and any agent that calls MCP servers or a model API. Control depth follows the agent surface: for Claude Code, Alyria installs itself as a managed PreToolUse hook through the agent's settings.json mechanism, so every tool call gets a synchronous allow or deny decision before it runs, and the hook contract Anthropic documents is what the managed hook sits on. Other agents are governed through the Alyria launcher, MCP routing and the egress plane.
Access is scoped by division and role resolved from your IdP over SSO. Every decision is attributed to a named person, not just a device.
The tenant exposes one MCP endpoint for your agents, pulls policy down to each Beacon, and runs Observatory for fleet dashboards. Fleet data is encrypted under an envelope key you control, with BYOK or HYOK.
What Alyria does
Four things. Each of them can be verified in your own environment.
On enrollment and on a schedule, the Alyria Beacon sensor lists the installed AI CLIs and tools, their versions, what is down-level, the local and shadow MCP servers it finds in agent configuration such as .mcp.json and the MCP entries in client settings, and the CVE exposure of that tooling. After you connect to your tenant, beacon status reports what it found. This posture also gates policy: a rule can refuse inference through a tool with an open critical CVE.
The local policy service evaluates every model, tool and MCP call against your Lyra policy, on the endpoint, offline, with no cloud hop. Policies start in monitor mode so you can see what would have been decided before anything is blocked.
Plane A mediates inference and MCP tool calls, including local stdio servers a cloud gateway never sees. Plane B observes processes and agent activity at the host with no kernel driver. Plane C controls network egress and injects secrets from Umbra as short-lived leases, so agent credentials are not stored on disk.
Every allow and deny is signed and streamed over OpenTelemetry into your SIEM or into Alyria Cloud, forming one tamper-evident chain that maps to OWASP ASI, NIST AI RMF and ISO/IEC 42001 language.
What Alyria does not do
Limits stated the way they are, because they decide the purchase as much as the features do.
Alyria governs agent actions: tool calls, inference and egress for enrolled agents. It does not hunt malware, watch processes that are not agents, or detect general compromise of the endpoint. Keep your EDR; they answer different questions and usually run side by side.
The Alyria Beacon sensor tracks CVE posture for your AI tooling specifically: agent CLIs, their runtimes, and MCP servers. Vulnerability management for the rest of the operating system and installed software is still your existing scanner's job.
Someone can still paste source into a public chat website, use an unmanaged laptop, or work from a personal device. Alyria decides what agents on enrolled, managed machines may do. It cannot decide what it cannot see.
Alyria resolves roles from your IdP, exports a tamper-evident audit chain to your SIEM, and brokers short-lived secrets from Umbra for governed flows. It does not replace any of those systems.
Beacon runs in user space. It is signed and its decisions are tamper-evident, but user-space controls can be defeated by a determined local administrator, so kernel-level host security remains your tamper baseline.
When another tool is the better choice
Some problems already have a good home. Here is where those answers live.
Reach for your EDR. Process trees, malware hunting and forensic timelines are an EDR's job and stay an EDR's job. Alyria adds the agent-intent layer on top: which tool call, which target, which policy, which identity, and one signed chain.
Reach for an MCP gateway. One deployment point and no endpoint agent at all. A gateway brokers HTTP between clients and servers, and that is all it sees. Local stdio servers, shells and direct-provider CLI traffic never cross it. The guide on the three layers goes through the comparison in detail.
Reach for OS application control. If the only question is signed versus unsigned at launch time, the application-control policy your operating system already ships is the cheaper answer. It cannot tell a legitimate code push from an injected exfiltration, but that is not the question it is asked.
Reach for a governed cloud runtime. Moving agents into a controlled environment and governing that environment is a legitimate architecture. This is the layer Statio, Alyria's runtime, covers: agents run inside a Beacon-governed node in your cloud, where model and tool calls are mediated by construction.
Reach for your existing scanner. OS patches, third-party applications and network services stay with the scanner you already run. Alyria's CVE view is scoped to the AI tooling installed on enrolled machines.
If you are weighing the layers against each other at the architecture level, read endpoint agent vs MCP gateway vs cloud runtime next.
Questions
- Does Alyria replace our EDR?
- No. Alyria governs agent actions: model calls, tool and MCP calls, network egress, and the signed audit chain behind them. Malware hunting, host forensics and threat detection stay with your EDR. The two are complementary.
- Which agents does it support?
- Claude Code, Cursor, Codex, Copilot, and any agent that talks MCP or calls a model API. Agents with a hook interface, such as Claude Code, get synchronous allow and deny on every tool call. Other agents are governed through the Alyria launcher and the egress plane.
- What do we need in place before rollout?
- Machines running Windows, macOS or Linux under your MDM, an IdP for identity, and a tenant. Install the Alyria Beacon sensor with your MDM, connect it with an enrollment token from Observatory, and apply your first Lyra policy in monitor mode.
- Will active enforcement break agent workflows?
- Not on day one. The Beacon deploys read-only and every policy starts in monitor mode, so the fleet keeps working while you review what would have been denied on the Observatory dashboards. You flip each policy to enforce when you are ready.
- Where does the audit data go?
- Beacons route signed events over OpenTelemetry into your SIEM or into Alyria Cloud, and the console can export the tamper-evident chain. Fleet data is encrypted under your keys.