Control Plane & Endpoint Agent

Alien Giraffe splits responsibilities between a centrally operated control plane and a fleet of lightweight endpoint agents. Understanding this split explains why the two halves are installed in completely different ways.

Control plane — AlienGiraffe Connector

The control plane is the service your team operates. It is the same AlienGiraffe Connector deployment used across the Alien Giraffe platform, and it provides:

• Device registry — every endpoint that checks in, with its identity, owner, status, and version.
• Inventory store — which AI agents and MCP servers exist on each device.
• Observability ingestion & analytics — the event pipeline and the aggregates behind the dashboards.
• Fleet, agent, and MCP views — the dashboard surfaces under /admin/*.
• AuthN/AuthZ and audit — local or Auth0 login, role-based access, and an audit trail of administrative actions.

It runs as a Go API plus a Next.js dashboard backed by Postgres. Installation is unchanged from the rest of the platform — Docker Compose or Kubernetes, configured with a10e.toml. See Install the control plane.

Endpoint agent — Lander

Lander is a single, dependency-free Go binary that runs as a headless background service on each managed machine (a launchd user agent on macOS). It has no UI and is centrally managed — once registered, it takes all of its instructions from the Connector and is not operated by local commands. Its job is to:

• Discover the AI agents installed on the host and the MCP servers each one is configured to use.
• Install the MCPs the Connector approves, writing them into the agent’s config already routed through the proxy.
• Mirror (proxy) the resulting MCP traffic so every tool call is captured — see MCP mirroring.
• Audit that traffic to local, rotating JSONL logs, and flag config changes made outside the Connector.
• Report device registration, inventory, and observability events to the control plane.

Because it must land on many machines you do not log into individually, Lander is built for fleet distribution via MDM — Microsoft Intune, Jamf Pro, or Kandji. See the Lander install guide for a single host, then the MDM guides for rollout.

The trust boundary

flowchart LR
  subgraph Untrusted["Endpoint (user-controlled)"]
    L["Lander\ndevice key + cert"]
  end
  subgraph Trusted["Control plane (you operate)"]
    API["API\nverifies signatures"]
    DB[("Postgres")]
  end
  L -->|"signed requests\n(X-Device-Signature)"| API --> DB

The endpoint is not trusted by default. On first run, Lander generates an ECDSA P-256 key pair and a self-signed certificate, stored locally with restrictive permissions. Every request it sends to the control plane is signed with that key, and the control plane records the certificate fingerprint so it can attribute and verify subsequent reports from the same device.

This boundary drives two important properties:

• Secret-safe inventory — Lander reports MCP names and transports, never the command, arguments, or environment variables that configure them (those can carry tokens). See Security & audit.
• Best-effort, non-blocking reporting — registration and inventory run in a background loop with exponential backoff. If the control plane is unreachable, the local proxy and audit logging keep working; reporting catches up later.

Why two install paths

	Control plane (Connector)	Endpoint agent (Lander)
Where it runs	Your servers / cluster	Every developer machine
How you install it	Docker Compose / Kubernetes + a10e.toml	MDM (Intune / Jamf / Kandji); manual for a single host
Cardinality	One deployment	Hundreds or thousands
Identity	Operated and trusted by you	Self-registers, verified by signature
UI	Dashboard	None (headless)

Next: how endpoints become tracked devices in Devices & fleet.