← All posts

The Claude Code audit trail has three layers. Anthropic operates two of them.

Dimitris Moraitis · ·6 min read
  • AI agent governance
  • audit trail
  • Claude Code
  • MCP firewall
  • human-in-the-loop approvals

Sooner or later, every team rolling out coding agents gets the same question from security: can we audit what these things are doing? It arrives about Claude Code first because Claude Code is usually first through the door, but the question is really about the whole fleet: Codex CLI, Cursor, Gemini CLI, OpenClaw, whatever ships next quarter.

The good news is that the vendor side of this story has gotten genuinely strong. The uncomfortable news, and the conclusion two independent analyses reached this year, is that the vendor side is two layers of a three-layer story, and the third layer is one you have to operate yourself.

Layer 1: the org control plane

Anthropic's Compliance API is the control-plane layer, available to Claude Enterprise organizations. It gives you a programmatic activity feed of authentication, administrative, and platform events, queryable within a minute and retained for six years, plus content endpoints for chats, files, and projects, and session transcripts for Claude apps including Claude Code. There is a healthy ecosystem of SIEM integrations on top of it.

This layer is good, and it keeps getting better. If you run Claude Enterprise and have not enabled it, do that first.

But notice what it is: retrospective evidence, produced and held by the vendor, about the vendor's own surfaces. Recording starts when you enable it and covers Anthropic products. It has nothing to say about the Codex CLI session that ran yesterday, or the Cursor agent a contractor uses, and it does not sit between an agent and a dangerous action. It reports; it does not enforce.

Layer 2: the operational plane

Claude Code also exports OpenTelemetry: metrics, events, and correlation back to the prompt that triggered them. Piped into your observability stack, this is how you build usage dashboards and investigate incidents.

General Analysis, in their detailed walkthrough of the Compliance API's coverage and gaps, are precise about what this layer is and is not: OTel is event-shaped operational data, useful for incident investigation, but it is not a schema-stable audit record. Telemetry is something the agent emits. Audit evidence is something your infrastructure produces about the agent. Those are different trust postures.

Layer 3: the plane you operate

Both analyses land in the same place. General Analysis concludes that a complete audit story needs three layers: the Compliance API at the org control plane, OpenTelemetry at the operational plane, and an on-device proxy or LLM gateway at the network and tool plane. Run all three or you have holes. Paper Mountain's guide to shipping the Compliance API into a SIEM publishes a coverage matrix that makes the same point row by row: the Compliance API covers Claude Code partially, and the row that fully covers what a coding agent actually does on a machine is the on-device proxy and gateway layer, the one no vendor runs for you.

That third layer is where the questions security actually asks get answered:

  • Which tool calls ran, with which arguments, and which policy allowed each one?
  • Who approved the risky ones, and what justification did they give?
  • Can we block or pause an action before it executes, not read about it afterward?
  • What did this team's agents spend, across every vendor, not just one?

Vendor-side layers cannot answer these, structurally. Enforcement has to sit in the path of the action, and only infrastructure you operate sits in that path. This is also the only layer that is vendor-neutral by construction: the same policy that governs Claude Code governs any MCP-compatible agent next to it.

What the third layer looks like when it is purpose-built

You can assemble this layer from parts: a forward proxy, an MCP gateway, egress rules, log shipping, a SIEM correlation project. Teams do. But the assembled version tends to govern traffic while the questions above are about decisions. This is the layer Preloop is built to be, as the open-source AI agent control plane:

  • An MCP firewall in the path of every tool call. Ordered allow / deny / require-approval / require-justification rules with CEL conditions on tool arguments, not just tool names. Native tool calls, Claude Code's Bash and Edit, Codex shell commands, are hooked before execution and governed by the same pipeline, which matters because those calls never cross a network proxy at all.
  • A human in the loop when policy demands one. The action pauses; a reviewer gets the tool, arguments, agent reasoning, and matched policy, and taps approve or deny on mobile, watch, Slack, Mattermost, email, or webhook. Async-safe, so the agent is not held open on a network hook.
  • Session timelines instead of log streams. One timeline per agent session: every model call, tool call, matched policy, approver, justification, and dollar, with replay. That is the artifact you hand to a security review.
  • Cost per team, reconciled. Spend attributed per agent and session, subscription-aware pricing for OAuth-covered traffic, and in Preloop Cloud and Preloop Enterprise, reconciliation against the provider's own billing APIs.
  • One-command onboarding. preloop agents discover finds local Claude Code, Codex CLI, Cursor, Gemini CLI, OpenClaw, and OpenCode configs, backs them up, and rewrites them to route through Preloop.

If you prefer to build the third layer as pure infrastructure, the strongest open source option at that level is agentgateway, a Linux Foundation proxy for MCP, A2A, and LLM traffic with excellent performance. It governs the traffic plane rather than the agent control loop, and the two approaches are complementary rather than competing; we wrote an honest comparison in Preloop vs agentgateway.

Run all three

The mistake both analyses warn about is treating "we enabled the Compliance API" as the finished story. It is a third of one. To secure Claude Code, and to govern coding agents as a fleet rather than one vendor at a time:

  1. Enable the Compliance API and ship its feed to your SIEM. This is the org-plane record, and it is not optional.
  2. Export OpenTelemetry into your observability stack for dashboards and incident work.
  3. Operate the third layer yourself: policy in the path of tool calls, approvals where automation is not enough, session-level evidence, and cost attribution, for every agent you run, not just the ones whose vendor ships a compliance feed.

The first two layers arrive with your vendor contract. The third one is a deliberate choice, and it is the one that decides whether your audit trail describes what happened or determined it.

Preloop is the open-source AI agent control plane: MCP firewall, AI model gateway, per-call human approvals, session observability, and audit trail, self-hosted under Apache 2.0. The control plane reference covers how the layers fit together.