Can an AI gateway control what coding agents do on a laptop?
A gateway governs the traffic routed through it. Shell commands, file reads, and stdio MCP calls never take that path, so the question is which layer each control sits at.
No. An AI gateway can control the model and MCP requests that are routed through it, and it cannot control the shell commands, file reads, and local stdio MCP calls that a coding agent performs on a laptop, because none of those actions cross the gateway. What a gateway does cover is real and worth keeping, so the useful question is which layer each control sits at.
What a gateway can see, and what it cannot
| Activity on the laptop | Model or MCP gateway | Endpoint agent |
|---|---|---|
| Model calls to a base URL you set to the gateway | Sees and can allow, deny, or rewrite the request | Sees the call only if the agent's traffic also passes a local policy service |
| Model calls straight to a vendor API from a local CLI | Not visible | Sees the process and the tool version, and sees the request when the agent's traffic passes the local policy service |
| Remote MCP servers the client routes through the gateway | Sees the JSON-RPC request, the tool name, and the arguments | Sees the same call at the endpoint, and still sees it when the client bypasses the gateway |
| Remote MCP servers the client calls directly | Not visible | Sees the connection and the tool call at the point of egress |
| Local stdio MCP servers | Not visible. There is no network hop to intercept | Sees the configuration, the spawned process, and the tool call |
| Shell commands run by the agent | Not visible | Sees the tool call before it runs when enforcement is on, and records it |
| File reads and writes | Not visible | Sees the read or write as a tool call, and can deny it when the data in context is above the tool's clearance |
| Agent behavior while offline | Not visible | Policies evaluate locally, so decisions still apply |
That is how a chokepoint behaves, and where the control sits decides what it can reach. Claude Code will launch a stdio server from .mcp.json and never send a packet about it, and the same holds for Cursor, the Codex CLI, and Copilot. Anthropic is direct about the limits of its own centralized controls: server-managed settings, it says, are "a client-side control, not a security boundary".
Where a gateway is the right control
Plenty of programs should own the gateway layer, and nothing here argues for removing one.
A gateway is the right place for model spend control, for a model allowlist, for pinning which provider and region a request goes to, for central custody of provider API keys so developers never hold them, and for logging prompts and completions of traffic you have routed. If your agents all run in a hosted environment, or every client is configured to point at your endpoint, then the gateway sees the model path in full and its logs are the record of that path. If your MCP servers are all remote and all registered with the gateway, the same applies to tool calls.
The vendor documentation is honest about the boundary. Anthropic's MCP reference describes servers configured in local user scope and project scope files, which is a client-side list. OpenAI's Codex MCP documentation describes servers added to ~/.codex/config.toml, again local to the machine. Neither is registered anywhere a gateway can read.
The laptop is where the actions happen
A coding agent's work is a loop of model calls and tool calls. The tool calls are the part with consequences: a shell command that runs terraform apply, a read of ~/.aws/credentials, an insert into production, a push. Every one of those is executed by a process on the endpoint, under the developer's identity, with whatever permissions that identity holds.
That leads to three questions a gateway cannot answer on its own.
- Inventory. Which agents, versions, and MCP servers are running on laptops right now, including the stdio servers nobody registered? A gateway lists what is registered with it.
- Policy. Is this specific tool call allowed for this identity, on this endpoint, with this data in context? A gateway can rule on a routed request; a local shell command has no request to rule on.
- Audit. What did the agent do, in the order it did it, including the calls that never left the machine? Gateway logs cover the gateway, and the rest of the record does not exist.
What the local layer has to do
To answer those three questions the control has to sit where the call is made, inside the endpoint, and it has to run before execution rather than after.
That is the architecture Alyria uses. Alyria Beacon is a signed, user-space daemon, with no kernel driver, that inventories the AI tooling and MCP server configuration on each machine. Policy decisions come from Lyra and are evaluated by a local policy service, so a call is allowed or denied on the endpoint, deterministically and without a cloud round trip, which means the decision still applies when the laptop is offline. Stdio servers with no network path are covered by the same rule as routed ones, because the check happens at the invocation rather than at a network boundary.
Three properties matter in a security review. Enforcement is opt-in and starts in monitor mode, so you can see what the policy would have decided over real usage before anything is blocked. The agent deploys read-only, and inventory and observation intercept nothing. Every decision is signed and streamed into one audit chain, so the record includes the rule, the tool, and the reason alongside the call.
The same layout applies when a gateway is in place. The gateway keeps its role on routed traffic, the endpoint covers what the gateway cannot reach, and the policy is authored once. The architecture page lays out how the pieces meet.
A worked example
Take a developer who runs Claude Code in a terminal on a laptop, with Cursor open in the same repo and Codex in another window. The gateway fronts model calls for a hosted assistant, and the developer's local CLIs talk straight to the vendor APIs. Under the repo there is a .mcp.json that adds a Postgres server pointed at a staging database, and in ~/.cursor/mcp.json a filesystem server scoped to the home directory.
What the gateway can tell you: the hosted assistant's spend, its model choices, and the prompts sent through it.
What it cannot tell you: that the Postgres server is pointed at a database with production-shaped data, that the filesystem server can read ~/.ssh, that Codex is three versions behind, or that a shell command in the last hour copied a .env file to /tmp.
What the endpoint layer answers: all four, from the inventory, the policy decisions, and the audit record, and the same policy engine decides the shell command and the tool call.
Deciding for your fleet
Choose a gateway first if every agent is hosted and every server is remote, if your problem is cost and model governance, or if you are consolidating provider credentials. Add the endpoint layer when any of the following is true: developers run CLIs locally, stdio MCP servers exist, agents hold credentials that can reach sensitive data, or an auditor has asked what an agent did on a laptop.
Most fleets end up in the second case, and running both layers is not a duplication of effort. The gateway governs the requests it sees, the endpoint governs the actions that never become requests, and the audit trail needs both to answer a question about one incident.
If you want to know which of those two gaps you actually have, the Agent Exposure Report inventories one pilot cohort and shows the agents, versions, and MCP servers the gateway never saw.