Audit & Compliance

Alien Giraffe keeps two complementary records — an administrative audit trail in the control plane and per-MCP traffic logs on each endpoint — and gives you controls to balance forensic depth against data sensitivity. This guide covers using them. For the underlying model, see Security & audit.

Investigate a denied call

When a tool call is blocked, the observability event captures why. In Observability → Events (/admin/observability/events), filter by result = denied to find them, then read:

• deny_code and deny_reason — the machine and human explanation,
• rule_applied — the rule that produced the deny (for example, a tool disabled in the MCP’s Connector allow/deny policy),
• agent_type, actor_email, and mcp_name/tool — who tried to do what.

This turns “something was blocked” into “Claude Code on Dana’s Mac tried github.delete_repo, blocked by the disabled-tool rule.”

Review the administrative audit trail

Privileged actions in the control plane are recorded for accountability. In Admin → Audit Logs (GET /admin/audit-logs), filter by user, action, resource, or date range to review user management, role changes, settings changes, and other administrative operations. Each entry keeps the actor’s email even if the user is later deleted, so the trail survives staff changes.

Catch manual config changes

The supported way to add or remove an MCP is through the Connector (Install an approved MCP), which keeps every server approved, policy-governed, and observed. Editing an agent’s configuration file by hand — for example, hand-adding a server to ~/.claude.json — bypasses that path: the MCP is unapproved, carries no tool policy, and would otherwise be invisible.

Lander treats this as an event to surface, not to silently accept. It watches each agent’s config file, and when it sees a change it didn’t make on the Connector’s behalf, it reports the modification to the audit trail as an unmanaged change. These entries appear in Admin → Audit Logs alongside the device and agent involved, so you can spot drift and follow up. Manual edits are discouraged; route all MCP changes through the Connector.

Retain endpoint traffic logs

The forensic record of exactly what an agent did lives on the endpoint as append-only JSONL:

~/.lander/logs/<mcp-name>/access.log   # metadata for every request
~/.lander/logs/<mcp-name>/query.log    # full tool payloads

For compliance retention, ship these off-box with your existing log pipeline (the JSONL format drops straight into most collectors). Logs are size-rotated (default 10 MiB, 5 files per MCP); collect them before rotation reclaims space.

Apply redaction controls

query.log can contain sensitive tool arguments and results. Tune what is captured from the Connector — globally or per MCP — as a logging/redaction policy that the Connector pushes to Lander and persists in ~/.lander.json (mcpServers.<name>.logging):

{
  "logging": {
    "enabled": true,
    "access": true,
    "query": false
  }
}

Setting	Posture
access: true, query: true	Full forensic capture (default)
access: true, query: false	Keep who/what/when/result; drop payloads — common for regulated data
enabled: false	Stop logging this MCP entirely

Setting query = false preserves the metadata trail and the observability events while discarding potentially sensitive payloads. Remember that inventory reported to the control plane never includes MCP commands, args, or env — secrets stay on the endpoint by design.

A practical compliance posture

1. Approve only the MCPs that touch sensitive systems, and disable their dangerous tools in the approval policy.
2. Set query = false for MCPs handling regulated data; keep full capture elsewhere.
3. Ship access.log (and query.log where retained) to your SIEM for retention.
4. Review Observability → Summary for token and denial trends; drill into Events for incidents.
5. Periodically review Admin → Audit Logs for unexpected administrative changes.

See also: Observability events and the event schema reference.