Getting Started
Alien Giraffe gives security and platform teams end-to-end observability and control over the AI agents running across their fleet — and the MCP (Model Context Protocol) servers those agents connect to.
Every coding and desktop agent (Claude Desktop, Claude Code, Gemini CLI, Codex CLI, and more) reaches tools and data through MCP servers. Alien Giraffe makes that traffic visible, attributable, and governable: which agent on which device called which tool, with what arguments, how many tokens it cost, and whether policy allowed it.
The two components
Section titled “The two components”Alien Giraffe is delivered as a control plane plus a lightweight endpoint agent.
Control plane (AlienGiraffe Connector)
Section titled “Control plane (AlienGiraffe Connector)”The API and dashboard you operate centrally. It registers devices, ingests observability events, and renders the fleet, agent, and MCP views. You install it the same way as the rest of the Alien Giraffe platform — Docker Compose or Kubernetes, configured with a10e.toml.
Endpoint agent (Lander)
Section titled “Endpoint agent (Lander)”A headless, centrally-managed daemon that runs on each developer machine or managed endpoint. It discovers the AI agents installed on the host, installs the MCPs the Connector approves, captures their traffic through a Connector-controlled proxy, writes local audit logs, and reports inventory and observability events back to the control plane. Nobody runs commands on it — it takes its instructions from the Connector. You roll it out to a fleet with your MDM — Microsoft Intune, Jamf Pro, or Kandji.
Install Lander on an endpoint →
The 5 W’s of agent observability
Section titled “The 5 W’s of agent observability”Alien Giraffe answers five questions about every MCP tool call:
- WHO — which AI agent, on which device, owned by which person, made the call.
- WHAT — which MCP server and tool was invoked, with what arguments and result.
- WHEN — the event time, session, and duration of the call.
- WHERE — the transport used (stdio or HTTP) and the endpoint it ran on.
- WHY — the policy decision (allowed, denied, or error) and the rule that applied.
How the data flows
Section titled “How the data flows”flowchart LR
subgraph Endpoint["Managed endpoint"]
Agent["AI agent\n(Claude, Gemini, Codex)"]
Lander["Lander daemon\ndiscover · mirror · audit"]
MCP["MCP server"]
Agent -->|MCP tool call| Lander
Lander -->|proxied| MCP
end
Lander -->|register · inventory · events| API["Control plane API\n/v1/devices/*"]
API --> DB[("Postgres")]
DB --> Dash["Dashboard\nfleet · agents · MCPs · observability"]
The endpoint agent registers the device, reports which agents and MCPs are present, and streams an observability event for every tool call. The control plane stores and aggregates these so the dashboard can show fleet-wide adoption, usage, and policy outcomes.
Next steps
Section titled “Next steps”- Stand up the control plane — follow the control plane install guide.
- Install the endpoint agent — try it on one machine with the Lander install guide.
- Roll it out to your fleet — use Intune, Jamf Pro, or Kandji.
- Install your first MCP — request and approve one from the catalog with the Install an approved MCP guide; it’s observed automatically.
- Watch the fleet — explore the dashboard in Monitor Agents & MCPs.
To understand the moving parts first, start with the Architecture overview.