The Lander | AlienGiraffe
The Lander · on every device

Coding-agent-native. On every device.

The Lander is the AlienGiraffe service on each laptop. It finds every AI client and MCP server, keeps the catalog and policy in force, and records every session natively: sub-agents, tool calls, skills, tokens, cost.

Backed by StartX (X25) Presented at OWASP
Local AI apps
Claude CodeCursorCodexClaude DesktopChatGPTCopilotGemini CLIJetBrains AIWindsurfClineZedAiderWarpAmpOllamaLM StudioGooseOpenCodeClaude CodeCursorCodexClaude DesktopChatGPTCopilotGemini CLIJetBrains AIWindsurfClineZedAiderWarpAmpOllamaLM StudioGooseOpenCodeClaude CodeCursorCodexClaude DesktopChatGPTCopilotGemini CLIJetBrains AIWindsurfClineZedAiderWarpAmpOllamaLM StudioGooseOpenCode

Shadow AI

Finds what's there. Then what's unsanctioned.

Every AI client, MCP server, and skill on the laptop, attributed to a person. Works on day one, before you've proxied a single call.

Inventory report-only

Devices

42

AI clients

6

MCP servers

31

Unsanctioned

9

ClientFoundOwnerStatus
Claude Code 3 MCP servers · 4 skills j.doe@acme Approved
Cursor GitHub · PAT in .env m.ruiz@acme Unsanctioned
Claude Desktop Slack · bespoke connector s.park@acme Unsanctioned
ChatGPT Gmail · Calendar connectors r.iyer@acme Pending
Codex postgres-mcp · 2 skills a.chen@acme Approved
Gemini CLI Jira · OAuth j.doe@acme Pending

Attributed to a person

Every AI client, MCP server, skill, and credential on the laptop, tied to who set it up.

Report-only by default

Inventory starts on first check-in. Nothing is proxied or blocked until you say so.

Unsanctioned gets flagged

Anything not in your catalog is surfaced. Alert on it first, stop it when you're ready.

Catalog & policy · scale

Publish once. Every device picks it up.

Approve an MCP server, a skill, or a policy in the Connector and the Lander applies it on every machine automatically: installed, scoped, proxied, and enforced. Update the catalog or a policy and the fleet follows, no tickets, no per-laptop setup.

  • 1-click install of approved MCPs and skills into every client
  • Applies policy changes the moment you publish them
  • Keeps versions and defaults in sync across the fleet
  • The catalog Tool-call policy
Search… ⌘K

MCP Servers

org-approved · 42 devices

Servers your organization has configured. Install the ones you want on your client.

GitHub

http

Installed 3 clients · 42 devices

Google Drive

http

Installed 2 clients · 40 devices

Notion

http

Configured Install

Slack

http

Installed 2 clients · 39 devices

Snowflake

http

Approval required Request access

Linear

http

Installed 1 client · 26 devices

Confluence

http

Approval required Request access

Postgres (read replica)

stdio

Installed 1 client · 18 devices
Skills pr-reviewdeploy-checklistmigrate-schema

Coding-agent-native telemetry

Every session, natively. That's what you optimize from.

Not proxy logs. The Lander records the session as the agent sees it: turns, sub-agents, tool calls, skills, tokens per turn, cost, and the PR it produced. That's the data you need to route models, trim context, and promote what works.

Session claude-code 2.1 · acme/payments · fix/billing-retry j.doe@acme

  • Turn 1 Add idempotency keys to /charges

    3 tool calls · 12.4k tok
    Read charges/handler.tsmcp · linear.get_issue PAY-231Edit charges.ts

    sub-agent tests-runner · 3 turns

    18.4k tok
    bash · pnpm testRead retry.test.ts

  • Turn 2 Fix the failing retry test

    2 tool calls · 9.1k tok
    Edit retry.test.tsbash · pnpm test

  • Turn 3 Open a PR

    1 tool calls · 2.3k tok
    mcp · github.create_pr
Skills used migrate-schemapr-review
tokens 61.2k in · 4.1k out cost $3.12 outcome PR #482 merged

Sub-agents, tools, and skills

The whole tree, not just the top-level prompt. Every turn carries its tool calls and tokens.

Tied to the repo and the PR

Sessions land on the branch and the pull request they produced, merged or not.

Cost per session, per merged PR

Tokens priced from public datasets, attributed to the person, the team, and the outcome.

Catch the combination

Read data here, post externally there. Two fine permissions that shouldn't meet in one session.

Instrumentation was the hardest part. Getting local hooks into everything was complex, but indispensable. You have to understand your own use cases before you know where to optimize.

Andrew S.

VPE, Platform & DevTools

Works with your gateway

Already on LiteLLM? Keep it.

LiteLLM governs the model call. The Lander governs the tool call and the device. Run it alongside LiteLLM: the Lander enforces your gateway on every machine so it can't be bypassed, adds the MCP servers and skills running locally, and ships session telemetry into the same pipeline. Or run the Lander as a LiteLLM extension.

Enforce the gateway on every device

The Lander pins each machine to your gateway, so no client routes around it.

Cover the MCP side

Tool calls, local MCP servers, and skills, which a model gateway never sees.

One telemetry pipeline

Session data lands next to your gateway logs, in the sink you already run.

Deployment

SaaS to kick the tires. Kubernetes for the fleet.

One signed package. Nothing to configure on the device. Report-only by default.

Personal · free

SaaS

The Lander on your machine, data in our cloud. One device, one user, no proxying.

Teams

Kubernetes, in your cloud

The control plane runs inside your infrastructure; we never see the data. Rolled out with Jamf, Intune, or any MDM. Users sign in once with SSO.

Personal is free and hosted. One device, one user, on a personal or business account.

FAQ

Frequently asked questions