MCP Mirroring

Mirroring is how Alien Giraffe sees and governs MCP traffic without asking agents to emit telemetry. Lander sits between the agent and the MCP server it calls, so every call passes through it on the way in and out.

AI agent → Lander → MCP server

For every JSON-RPC request and response, Lander:

1. Attributes it to an agent and a device.
2. Governs it with the tool allow/deny policy the Connector set.
3. Audits it to a local log and streams an event to the Connector.
4. Forwards it to the real server.

Mirroring is not something anyone turns on by hand. When an MCP is installed from the Connector, the Connector tells Lander to provision it already routed through this path, so it begins with the first call and needs no separate step.

On this page: why proxy, the two transports, routing through your own proxy, tool-level control, lossless restore, and what gets captured.

Why proxy at all

MCP agents don’t emit a usable audit trail on their own. By sitting in the path, Lander can:

• see every tool call with its arguments and results,
• attribute each call to a specific agent and device,
• enforce the tool allow/deny policy the Connector set, and
• write a durable audit log locally and stream events to the Connector.

Crucially, it does this losslessly — the original MCP configuration is backed up atomically before Lander writes the proxied version, so the agent can be restored to its exact prior state whenever the Connector revokes the MCP.

Two mirroring modes

Lander uses one of two transports for the proxy, chosen per MCP by the Connector when it provisions the server.

stdio mode (default)

Lander writes the agent’s config so that, instead of spawning the real MCP server, the agent spawns Lander’s stdio proxy subprocess. That subprocess forwards JSON-RPC between the agent’s stdin/stdout and the real MCP server.

• Lightweight; a subprocess is spawned per MCP session.
• The agent’s identity is injected via the LANDER_AGENT_ID environment variable.
• No long-running daemon is required for the proxy itself.

sequenceDiagram
  participant Agent
  participant Proxy as Lander stdio proxy
  participant MCP as real MCP server
  Agent->>Proxy: JSON-RPC tools/call (stdin)
  Note over Proxy: attribute (LANDER_AGENT_ID)<br/>check tool policy<br/>append audit log
  Proxy->>MCP: forward request
  MCP-->>Proxy: result
  Note over Proxy: log result · emit event
  Proxy-->>Agent: JSON-RPC result (stdout)

HTTP-stream mode (daemon)

Lander writes the agent’s config to point at the local Lander daemon’s reverse proxy (http://localhost:8082/stream/proxy/<mcp-name>, via mcp-remote). The long-running Lander daemon (default port 8082) forwards to the real server.

• A single daemon serves all proxied MCPs.
• The agent’s identity travels in the X-Lander-Agent header.
• Requires the Lander daemon to be running (it is, as a launchd service).

Both modes support the same governance and audit features; they differ only in transport and process model.

Routing a catalog MCP through your own proxy

Organizations that already run an MCP proxy — a policy engine, a DLP gateway, a vendor proxy — can put it in front of any catalog MCP. The agent still talks only to Lander; the only change is that the entrypoint Lander forwards to is your proxy, which opens the connection onward.

AI agent → Lander → your MCP proxy → upstream MCP server

• Configured per MCP, on its catalog entry’s install spec (install_command / install_args, or install_url / install_headers). The device cannot override it.
• Enforced. If the entrypoint is unreachable or fails to start, the call fails closed with a JSON-RPC error and an error event. There is no direct or native fallback.
• Auth is respected as-is. Whatever authentication and authorization the proxy applies is left untouched.
• Observability is unchanged. Lander audits both sides of the hop: what it sends to the proxy and what it gets back.

See MCP proxy configuration for the full setup, auth flows, and failure modes.

Tool-level control

Each managed MCP carries a tool allow/deny policy, authored in the Connector — set when an admin approves the MCP and adjustable later under MCP Servers. Disabled tools are rejected at the proxy with a policy result of denied, which shows up in observability events with a deny reason. The rest of the server keeps working. The policy is pushed to Lander and applied locally; there is no local flag to edit.

Lossless restore

Before writing any agent config, Lander stores the original under originalConfig in ~/.lander.json. When the Connector revokes an MCP from a device, Lander puts the agent’s configuration back exactly as it was — the proxy is removed and the agent talks to the real MCP server directly again. Writes to ~/.lander.json are atomic (temp file + rename), so a crash mid-write can’t corrupt state.

What gets captured

For every proxied call, Lander records metadata and (unless redacted) full payloads to local JSONL logs, and emits an observability event to the Connector. The shape of that data is described in Observability events; the privacy controls are in Security & audit.

To do this end to end, follow Install an approved MCP.