Security & Audit

Alien Giraffe is designed so that an untrusted endpoint can report rich telemetry to a trusted control plane without leaking secrets and without being able to spoof another device. This page covers the security model end to end.

Device identity and signing

On first run, Lander establishes a cryptographic identity for the endpoint:

• It generates an ECDSA P-256 key pair and a self-signed certificate under ~/.lander/certs/ — device.key (mode 0600) and device.crt (mode 0644).
• It derives a certificate fingerprint (SHA-256 of the certificate).

Every request to the control plane — registration, inventory, and events — is signed with the device key over a canonical payload (certificate_fingerprint, body_sha256, timestamp) and carried in the X-Device-Signature header. The control plane records the fingerprint at registration and verifies subsequent reports against it, so:

• a device cannot impersonate another device, and
• the control plane can attribute every event to a verified origin.

Registration is idempotent: if the device is already registered with the same certificate and owner, Lander skips the call.

Authenticated enrollment

Device signing establishes which device is calling; it says nothing about whose device it is. Enrollment therefore requires a second, independent proof: the user authenticates to the Connector — Lander prompts for this itself, opening a browser in the user’s GUI session — and POST /v1/devices/register carries that user’s bearer token alongside the device signature.

• Ownership comes from the token’s subject. A body-supplied owner email is accepted for wire compatibility but never consulted, so an endpoint cannot enroll a device as another person by asserting their address.
• Both proofs are required, and neither replaces the other — the signature proves the device, the token proves the human.
• Only registration is user-authenticated. The reporting endpoints (/v1/devices/inventory, /v1/devices/events) remain certificate-authenticated and are unchanged, so an enrolled device keeps reporting without a live user session.
• The credential is stored at ~/.lander/credentials.json (mode 0600, refused if permissions loosen) and can be revoked with lander auth logout. See Lander Configuration.

Because ownership is now proven rather than claimed, the usage, observability events, and audit entries attributed to a person are attributable in a way self-asserted email could not support. The authenticated user is also recorded in the audit entry for the registration itself.

Secret-safe inventory

The single most important data-handling rule: Lander never reports the things that carry secrets.

When it reports an agent’s MCP configuration in inventory, it includes only the MCP name, enabled flag, and transport. It deliberately omits the command, args, and env of each MCP server — those frequently contain API tokens, connection strings, and credentials. Secrets stay on the endpoint.

Audit logging

Two layers of audit exist, serving different audiences:

Administrative audit (control plane)

The control plane records administrative actions to an audit log, queryable at GET /admin/audit-logs with filters for user, action, resource, and date range. Captured actions include user creation/activation/deactivation, role and settings changes, and other privileged operations. Each entry records the actor (user id + email, denormalized so it survives user deletion), action, resource type/id, details, status, and timestamp.

MCP traffic audit (endpoint)

On the endpoint, Lander writes append-only JSONL logs per MCP under ~/.lander/logs/<mcp-name>/ — access.log (metadata for every request) and query.log (full payloads). These are the forensic record of exactly what each agent did. They are size-rotated and retained for off-box collection by your log pipeline.

Unmanaged config changes (endpoint → control plane)

Because MCPs are meant to be installed and governed through the Connector, anything that changes an agent’s configuration outside that path is worth surfacing. Lander watches each agent’s config file; when it detects a change it did not make on the Connector’s behalf — someone hand-editing ~/.claude.json, say — it reports the modification to the control plane as an unmanaged change, attributed to the device and agent. These entries appear in the administrative audit trail so operators can spot drift. Manual edits are discouraged; the supported path is the Connector.

Redaction controls

Because query.log can contain sensitive tool arguments and results, payload logging is controllable from the Connector as a logging/redaction policy (global default, or per MCP). The Connector pushes it to Lander, which persists it in ~/.lander.json under the logging block (or per MCP under mcpServers.<name>.logging):

Key	Effect
enabled	Master switch for logging an MCP
access	Write metadata logs (default true)
query	Write full-payload logs (default true; set false to redact arguments/results)
level	Log level (debug/info/warn/error)
maxBytes / maxFiles	Rotation size and retained file count

Setting query = false keeps the metadata trail (who called what, when, with what result) while discarding the potentially sensitive payloads — a common posture for MCP servers that handle regulated data.

Role-based access control

The control plane enforces RBAC on every administrative surface:

Role	Capabilities
user	Authenticate; baseline access
admin	View the fleet, agents, MCPs, observability, audit logs; manage users
super_admin	Everything admin can do, plus the most privileged operations (e.g. creating local users, resetting passwords)

Authentication is via local username/password or Auth0 (OIDC/JWT), selected in a10e.toml. Admin endpoints (/admin/*) require an admin role; the most sensitive require super_admin. See Control Plane Configuration for how to configure the provider.

Operational safety properties

• Atomic config writes — ~/.lander.json updates use temp-file-plus-rename so a crash can’t corrupt state.
• Graceful shutdown — the daemon drains in-flight proxied requests (up to a timeout) before exiting.
• Non-blocking reporting — if the control plane is unreachable, the proxy and local audit keep working; reporting retries with exponential backoff.
• No inbound MCP surface — Lander exposes no MCP tools of its own and accepts no local control commands for managed operations; it is driven entirely by the Connector over its authenticated, signed channel.