Endpoint agent vs MCP gateway vs cloud runtime
An MCP gateway can enforce only on the remote MCP traffic and model calls routed through it over HTTP: a local stdio server, a shell command, a file read or a direct-provider API call never crosses it, so it can neither see nor stop those. The Alyria Beacon takes the other architecture: it sits where the agent runs on the workstation and decides on every tool and model call locally, and Alyria Statio covers the remaining layer by running agents inside a governed environment in your cloud, where every model and tool call is mediated by construction.
The table below covers local stdio MCP calls, remote MCP traffic, shell commands, file reads, model calls and offline use, plus identity, audit and agent coverage, and the sections after it say when each layer is the right answer. It is written to be fair to gateways: when every agent already runs in infrastructure you control and speaks HTTP to remote servers, a gateway is the cheaper answer.
The three layers
Same purpose, different vantage point. Read each one as the answer to: what does this layer actually see, and what can it actually stop.
You point a client at a gateway URL. The gateway authenticates the client, brokers the MCP server's own credentials, applies policy to the calls it proxies, and logs them. It is one process to run, no endpoint install, and it works for anything that speaks HTTP to remote MCP servers. Its reach ends at its own port: a local stdio server on a laptop, a shell the agent spawned, or a CLI that calls a model API directly never crosses it.
Signed software on each machine where agents do work. The endpoint layer evaluates policy where the call originates: the tool call the agent is about to make, the model call it is about to send, and the network connection it is about to open. It sees the calls a gateway is not present for, including local stdio MCP servers and direct-provider CLI agents. Enforcement is local, so it keeps working when the machine is offline.
Agents do not run on laptops; they run inside a controlled environment in your cloud. The environment sees everything the agent does by construction: every tool call, every process, every byte that leaves the box. Nothing on the workstation is involved at all. The tradeoff is what it does to the developer experience: the work happens inside the runtime, not inside the repo clone on the laptop.
What each layer sees and can enforce
Left to right on desktop, top to bottom on mobile. Each cell states what the layer sees and what it can enforce.
| Surface | MCP gateway | Endpoint agent | Cloud runtime |
|---|---|---|---|
| Local stdio MCP calls | Never sees it a stdio server talks to the agent over stdin and stdout on the same machine, so no network path exists for a gateway to sit on | Sees and mediates policy is evaluated where the call is made, including servers the agent launches from its own .mcp.json or client settings | Replaced the governed environment supplies its own tools, so no laptop-local servers exist |
| Remote MCP traffic (HTTP) | Sees and brokers the gateway authenticates the client, holds the server's credentials, proxies the call and applies its own policy layer | Can mediate calls made by governed agents can be evaluated and governed at the endpoint before they leave the machine | Governed inside the box all traffic from the environment carries the runtime's egress policy |
| Shell commands | Never sees it tool execution happens in the agent's own process on the machine, not over a socket the gateway fronts | Observes and correlates user-space host telemetry records process launches, and governed tool calls are policy-checked through the managed hook or the Alyria launcher | Runs inside the box every process the agent spawns happens inside the governed environment |
| File reads on the workstation | Never sees it a read from a local path or the developer's home directory crosses no network boundary | Correlates to agent intent host telemetry and tool-call decisions tie a file access, such as a denied read of ~/.aws/credentials, to the tool call that asked for it | Scoped to the environment the agent reads what the environment mounts, not the developer's home directory |
| Model API calls | Sees proxied clients only a model gateway sees the calls clients route through it, and direct-provider SDK traffic does not pass it | Sees per agent session governed model calls, including direct-provider CLI agents, are evaluated through the managed hook and the local policy route | Sees all of them model calls happen inside the environment under its policy |
| Offline use | Cannot decide when the machine is offline the gateway is unreachable, so its enforcement pauses with it | Keeps working evaluation runs locally on the machine, so the decision does not depend on a network round trip | Not applicable agents run where the runtime runs; the workstation's offline state does not participate |
| Network egress | Only brokered connections governs what passes through the gateway itself, not the rest of the machine's traffic | Allow and deny at the wire an egress plane on the endpoint governs governed agents' outbound connections, with secrets from Umbra injected as short-lived leases | One policy per environment egress rules apply to everything that runs inside the box |
| Identity attribution | The client credential it can say which token reached it, not which person drove the session | SSO identity per session each session resolves through your IdP, and the signed chain carries that identity on every decision | The identity of the run whoever or whatever launched the run inside the governed environment |
| Audit evidence | Gateway request logs a record of proxied requests and responses at one hop | Signed, exportable decision chain every allow and deny is signed and streamed to your SIEM or console as one tamper-evident chain across the fleet | A full run record everything the agent executed inside the governed environment |
| Agents it covers | HTTP-speaking clients anything that can be pointed at a URL and speak MCP over the wire | Any agent on the machine Claude Code, Cursor, Codex, Copilot, framework agents and direct-provider CLIs on enrolled machines | Agents migrated into it running existing agents inside is a project you schedule, not a switch |
Where the specifics come from: the MCP specification defines the stdio and HTTP transports between a client and a local or remote MCP server; Anthropic documents the Claude Code hooks and settings.json mechanism that gives a security tool a synchronous, admin-locked decision point per tool call; and ngrok's AI Gateway documentation describes one gateway's enforcement surface over proxied traffic. Check each vendor's docs for the version you run; the surfaces move.
How to choose
Tradeoffs stated the way an engineer would state them to a peer.
One service, no endpoint install, and clean operations. If your agents run somewhere you already control and they only speak HTTP to remote MCP servers, a gateway may be all you need. Its limitation is structural: it never sees a laptop, a stdio server, or a shell.
You already run an MDM, so you know the cost of a per-machine agent. What you get is the point of use: the decision happens on the machine where the agent runs, on the call it is about to make, whether or not anyone is watching the gateway.
The agent's whole execution happens inside the controlled environment, so the runtime sees every action it can take and the workstation is out of scope entirely. The cost is the change itself: the work moves out of the developer's repo clone. Unattended work such as scheduled jobs and CI agents fits a runtime naturally; interactive work often stays on workstations.
There is no single correct answer between layers, because agents have different shapes. A practical posture: an endpoint agent on machines where people run agents, a gateway in front of remote MCP and model endpoints where that is useful, and a governed runtime for unattended work.
Beacon on the endpoints, Statio in the cloud
One tenant, one policy language, one audit chain across the two places agents actually run.
For the fleet that stays on real machines. The Alyria Beacon sensor is a signed, user-space daemon on every Windows, macOS and Linux endpoint, deployed read-only through your MDM. Its local policy service evaluates every model, tool and MCP call against your Lyra policy before it happens, and every decision lands in one signed audit chain. Policies start in monitor mode and go to enforce per policy when you trust them.
For agents you run in your own cloud, Alyria Statio executes agents inside the governed runtime on a Beacon-governed node, so model and tool calls are mediated by construction and the workstation is not part of the picture. Bring your model provider and choose where the runtime runs.
Not sure whether the problem is yours? Where Alyria fits, and where it doesn't covers the buyer side. For the hands-on path, start with install a Beacon and ship a first policy.
Questions
- Do I need all three layers?
- No. Each layer answers a different reach and threat model. Start from where your agents run today. If they run on developer workstations, control has to exist on those workstations. If they run inside infrastructure you own, a gateway or a runtime may cover you.
- Can a gateway stop a local stdio MCP server?
- No. A stdio server and the agent talking to it communicate over local pipes on the same machine, and that traffic never passes through a network gateway. Endpoint or runtime controls are the layers that see it.
- Is an endpoint agent and an EDR the same thing?
- No. An EDR watches processes and detects compromise of the host. An AI governance endpoint agent reads agent intent: which tool call, which resource, under which policy and identity. They are different surfaces and normally deployed side by side.
- Where does Alyria sit among the three layers?
- On both ends. Beacon, the endpoint agent, governs machines where people run Claude Code, Cursor, Codex and Copilot. Statio, the governed runtime in your cloud, covers agents that run unattended. One tenant, one policy language, one audit chain across both.