How to log every Claude API call for compliance - native logs into your SIEM

The CISO walks into the AI rollout meeting around day forty, not day one. Pilot’s going well. Sales loves it. Engineering loves it. Then someone in compliance opens a ticket and asks the question that should’ve been asked at day zero: how do we prove who did what inside Claude?

There’s a small industry that’s spun up to answer that. Wire-level inspectors pricing themselves at six figures a year, reassembling TLS traffic to infer who sent what to which model. I think most of them are rubbish. Anthropic’s own audit log already captures every event you’d want, signed by them, with the exact actor IDs and conversation IDs the wire never sees. Running Tallyfy for ten years taught me to suspect any vendor that prices in six figures for what your own logs already say. The thing your auditor will look at is the native log. Not a reassembled one.

What Claude Enterprise exposes

Three surfaces. Each one answers a different audit question.

The Audit Logs API

This is the one the compliance team will ask for first. The Audit Logs API tracks 33 event types - SSO sign-in and sign-out, magic-link verification, project create and rename and delete, document create and delete, conversation create and rename and delete, user invite and delete, SSO config changes, domain verification, file upload, data export initiated and completed. Every entry carries the same nine fields: created_at, actor_info, event, event_info, entity_info, ip_address, device_id, user_agent, and client_platform. Pull the stream and you have the answer to four of the five questions every auditor asks: when did it happen, who did it, where from, and on what device. The fifth question - what exactly was said - is the one not in this stream. That is by design, and the right design for most compliance regimes, because conversation content is a wider liability surface than admin events and deserves its own evidence pipeline anyway. The list has grown from 24 event types in early 2025 to 33 today, which is the practical reason your forwarder needs a graceful unknown-event handler rather than a strict schema check. Anthropic will add more.

Plan for it.

Anthropic retains audit logs for 180 days inside their infrastructure. Export them through Organization Settings then Data and Privacy then Export Logs in the console, or pull them programmatically through the Compliance API using a Compliance Access Key tied to your Primary Owner. Pull on a five-minute cadence and watermark the timestamp you’ve already shipped, because Anthropic does not guarantee strict ordering across event types.

What is not in this stream: conversation content. The chat title and project title surface as identifiers in entity_info, but the prompt and response bodies themselves live in a separate Data Export tier gated to Primary Owners only. That is the design.

The Analytics API

The Analytics API shipped in beta in 2025 and answers a different question. Not “who did what” but “how is the seat being used, and what is it costing me.” It exposes conversation counts, messages sent, projects created, files uploaded, artifacts produced, skills and connectors invoked, Claude Code commits and pull requests and lines of code, DAU and WAU and MAU broken out by product, seat utilization rates, pending invites, and per-user token spend with breakdowns by product, model, region, and processing speed.

Auth is a separate x-api-key header generated from Analytics then API keys in the console, also gated to Primary Owners. Default rate limit is 60 requests per minute, with higher limits available on request to Anthropic Sales. Engagement metrics look back 90 days; usage and cost metrics look back 365 days inside 31-day query windows. Refresh runs every four hours, sometimes up to 24 hours for a full pass, with a 30-day reconciliation window for late-arriving events.

This is the stream that feeds the FinOps story - the per-user spend that your finance team needs to chargeback against cost centers. There’s a longer write-up on the ROI side at Claude usage monitoring if that’s the conversation you are stuck in.

OpenTelemetry for Claude Code

The third surface is per-session, not per-org. It only emits from Claude Code - not from claude.ai web chat, not from Claude Projects on Desktop. Inside Code it’s the richest stream you’ll get. The high-cardinality observability that Charity Majors and the Honeycomb team have argued for over the past decade lands inside an LLM workflow with this stream - one event per developer interaction, one set of attributes per session, queryable by user and by tool.

Set five env vars on the developer machine (or push them through an MDM-managed settings file so users cannot override them):

CLAUDE_CODE_ENABLE_TELEMETRY=1
OTEL_METRICS_EXPORTER=otlp
OTEL_LOGS_EXPORTER=otlp
OTEL_EXPORTER_OTLP_ENDPOINT=https://collector.example.com:4317
OTEL_EXPORTER_OTLP_PROTOCOL=grpc
OTEL_EXPORTER_OTLP_HEADERS=Authorization=Bearer ${OTEL_TOKEN}

You get four counter metrics out of the box: claude_code.session.count, claude_code.lines_of_code.count, claude_code.pull_request.count, claude_code.commit.count. Plus token and cost counters per session, plus tool-decision counters. Each event carries session.id, organization.id, user.account_uuid, user.account_id, user.email, terminal.type. Add OTEL_RESOURCE_ATTRIBUTES="department=engineering,team.id=platform,cost_center=eng-123" to attribute spend per cost center.

The gated content flags are off by default and the reason you would turn them on is forensic, not observational. OTEL_LOG_USER_PROMPTS=1 captures every prompt body. OTEL_LOG_TOOL_DETAILS=1 captures tool inputs. OTEL_LOG_TOOL_CONTENT=1 captures outputs. OTEL_LOG_RAW_API_BODIES=1 captures the full request and response payloads. Turning any of these on materially changes your compliance perimeter because prompt bodies become routine log content. Turn them on per workspace, per investigation, with sign-off from the data owner. Do not run them as a default. The same logic applies as for any high-fidelity capture inside an observability pipeline - the LLM monitoring observability piece walks through why default-on prompt capture is a known leak path.

Traces are still in beta. Set CLAUDE_CODE_ENHANCED_TELEMETRY_BETA=1 and OTEL_TRACES_EXPORTER=otlp to get the span hierarchy: claude_code.interaction parents to claude_code.llm_request and claude_code.tool, which parents to claude_code.tool.execution. Useful if you want to see latency breakdowns. Not yet what your auditor will be asking for.

The shipping architecture every vendor reuses

Does Anthropic ship pre-built SIEM connectors? No. They publish the streams; you wire them up. The shape of the pipeline is the same regardless of which SIEM you point it at. Only the last hop changes.

Five components. A pull worker for the two pull-mode APIs (Audit Logs and Analytics). An OTel collector for the push-mode stream. A raw immutable archive in object storage as the audit-grade evidence layer. A durable queue between collection and forwarding so the polling cadence is decoupled from the SIEM intake cadence. And a forwarder that reshapes the payload to whatever schema the SIEM wants.

The pull worker runs as a Lambda or an Azure Function on a five-minute cron for audit, and hourly for analytics. It maintains two watermarks: the last audit-log timestamp shipped, and the last analytics query window completed. On success it writes the raw JSON to S3 or Azure Blob with a write-once retention policy, and enqueues the event to SQS, Azure Queue Storage, or GCP Pub/Sub. The queue is the buffer pattern Jay Kreps formalized in his 2013 “The Log” essay - a uniform abstraction between asynchronous producers and consumers running at different cadences. On failure the worker backs off exponentially up to N retries, then routes to a dead-letter queue with a human alert.

The OTel collector is the standard OpenTelemetry Collector container. Receive OTLP gRPC on 4317, batch on the receive side, and export to either the SIEM’s native OTel ingest (if it has one) or to the same queue the puller uses. The OTel docs at opentelemetry.io cover the receiver and exporter config.

The forwarder is where the schema work happens. Map Anthropic’s actor_info.account_uuid to the SIEM’s user-identity field. Map event to whatever the SIEM calls action or operation. Tag every event with a source label so the SIEM rule library can scope detections to Claude events. Keep a frozen schema version in your config so when Anthropic adds a new event type (and they will), your forwarder fails open with an “unknown_event” tag rather than dropping it.

The raw archive in object storage is the bit that saves you during an audit. The SIEM is where you query and detect; the raw archive is where the auditor pulls evidence from. Same data, two retention tiers. The deployment-surface side of the same architecture story is in running Claude in compliance-heavy environments.

Where you ship the logs

Seven options, ranked roughly from biggest enterprise share down to do-it-yourself.

Splunk

Splunk’s HTTP Event Collector is the canonical ingest path. POST your event to https://<host>:8088/services/collector/event with Authorization: Splunk <token> and a JSON body containing time, event, host, source, sourcetype, and index. Splunk Cloud uses https://http-inputs-<host>.splunkcloud.com/services/collector with the same header pattern - the HEC docs cover the format.

Build a custom Technology Add-On (TA) for Claude events so your fields map to the Splunk Common Information Model. CIM gives you parsed, normalized field names that work with the Enterprise Security correlation searches your SOC already runs. Map actor_info.account_uuid to user, event to action, ip_address to src_ip, and tag every event with sourcetype=anthropic:claude:audit. That last bit is what lets your SOC scope detections to Claude without trawling the whole index.

For the OTel stream, Splunk Observability Cloud accepts native OTLP at ingest.<realm>.signalfx.com. The two paths can coexist - send the metric traffic to Observability for dashboards, and copy the log-shaped events to HEC for security correlation. The thing to confirm with your Splunk admin is index sizing. Per-user OTel events from Claude Code multiply quickly. Indexed-volume pricing is the gotcha. Cap it with a sampling policy on the OTel collector before it hits HEC.

Datadog

Datadog’s logs API takes JSON over HTTPS at https://http-intake.logs.datadoghq.com/api/v2/logs (or the EU variant at datadoghq.eu, plus regional variants for AP1, AP2 and others). Auth is the DD-API-KEY header. Payload is nested JSON; Datadog auto-parses service, source, ddsource, and ddtags. The Datadog logs API reference has the canonical schema.

The Datadog Agent runs an OTLP receiver natively. Configure the Agent once with otlp_config.receiver and point Claude Code’s OTel exporter at the Agent’s address. The Agent then forwards metrics and logs (plus traces, when enabled) to Datadog under your existing API key. No separate OTel collector required - which is the Datadog argument in two sentences.

Where Datadog earns the compliance line item is Cloud SIEM. The detection rules library is where your SOC will write Claude-specific rules. Mind you, Datadog also defaults to capturing prompt content in APM spans if you point Claude Code’s traces at it, so set OTEL_LOG_USER_PROMPTS=0 explicitly and turn on Datadog’s Sensitive Data Scanner with a custom scanner rule that scrubs anything matching obvious patterns. Same reason Sentry breadcrumbs were the bug in 2025 - the observability tools default to capture-everything, and you have to opt out of capturing the bits that matter.

Elastic

Elastic is the self-hostable answer if you want to avoid cloud-vendor lock-in. Two ingest paths. First, ship through Logstash’s HTTP input plugin on port 8080, where the plugin docs describe the receiver and Logstash handles parsing into ECS. Second, write directly to Elasticsearch with the _bulk ingest endpoint using NDJSON and an API key.

Map every field through the Elastic Common Schema. event.action is the Anthropic event type. user.id is the actor account UUID. user.email is the actor email. event.outcome is “success” or “failure”. source.ip is the IP. client.user_agent.original is the user agent. ECS gives you a single canonical schema across every log source, which is the bit that makes the Kibana correlation work without rewriting every rule per source.

Elastic’s APM server accepts OTLP natively, so the OTel stream lands at the same cluster as the audit logs. For mid-size companies running their own Elastic cluster, the operational cost is the trade. Index lifecycle management (hot, warm, cold, frozen) and a tiered storage policy keep the 180-day audit retention plus your usual log retention from blowing the budget. The cluster sizing is the thing that gets underestimated when teams compare this against Splunk’s per-GB pricing.

Sumo Logic

Sumo’s pattern is the Hosted Collector plus an HTTP Source. Each HTTP Source gives you a tokenized URL of the shape https://endpoint<N>.collection.<region>.sumologic.com/receiver/v1/http/<TOKEN> - the token lives in the URL, no separate header. Payload is NDJSON. The HTTP Source docs walk through the setup.

Where Sumo Logic earns its keep is Cloud SIEM. The included compliance dashboards cover PCI DSS, HIPAA, and SOC 2 out of the box, and you can build a Sumo App for Claude events that drops the same dashboards your team is already used to reading. The Sumo OpenTelemetry Distribution is a packaged collector you can drop in instead of stock OTel, which saves you the receiver-exporter wiring.

The compliance angle Sumo plays well is multi-tenant. If you are a managed service provider running Claude for several downstream clients, Sumo’s partition model gives you the per-tenant separation that other SIEMs make you build yourself. Less interesting if you only have one tenant to think about. Spot on if you are an MSP.

Microsoft Sentinel

Sentinel is the right answer when the rest of the security stack already lives on Microsoft 365. Two paths. The legacy one is the Log Analytics Workspace Data Collector API with HMAC-SHA256 signatures, which Microsoft is gradually deprecating. The current one is the Logs Ingestion API at https://<dce>.<region>-1.ingest.monitor.azure.com/dataCollectionRules/<dcr>/streams/<table>?api-version=2023-01-01 with an Entra ID OAuth bearer token. The Logs Ingestion API overview covers the data collection rule (DCR) and data collection endpoint (DCE) setup.

Define a custom table in Log Analytics called something like ClaudeAuditLogs_CL and map the Anthropic schema to it once. After that, your SOC writes Sentinel Analytics Rules in KQL against the custom table, and Workbooks for the visualization layer. Anomaly detection rules tied to user-level audit fields catch the things the wire-level inspector misses by design - things like “this user just exported every project’s conversation history at 3am” which only the actor-level audit log can see. Turns out, the wire never had a clean way to express that question in the first place.

Azure Monitor accepts OTLP natively through the Azure Monitor OTel Distro or any OTel collector with the Azure Monitor exporter. If your dev team’s Code traffic already flows through Azure Monitor and the audit logs land in the same Sentinel workspace, the cross-correlation queries get easy. That’s the strongest reason to pick Sentinel.

Arctic Wolf

Arctic Wolf is not a self-managed SIEM. It is Managed Detection and Response, and the trade is fewer dials in exchange for a 24/7 Concierge Security Team watching the events. Two ingest paths into the Observation Pipeline. One is a Virtual Log Collector on-prem doing RFC 5424 syslog over TCP/514. Other is a webhook token from the cloud side - JSON over HTTPS to a per-tenant endpoint Arctic Wolf provisions.

The pattern is: hand Arctic Wolf a sample Anthropic audit log payload, and their Concierge team builds the custom parser inside the pipeline. Your events become structured Observations rather than raw logs, and the parser is theirs to maintain. That includes maintaining it when Anthropic adds the 34th event type next quarter, which is the part most teams underestimate when they roll their own.

The compliance angle is that Arctic Wolf’s SOC is named in your audit narrative as the 24/7 monitoring control. For mid-size companies with no internal SOC and an auditor asking “who watches this,” the answer is a contracted service from day one rather than a hiring project that takes nine months. The tradeoff is vendor dependency and a slower path to changing detection logic. Fair trade if you do not have a Splunk admin in the building.

Roll-your-own

The cheapest cash option, the most internal ownership. A Lambda on a CloudWatch Events cron pulls Audit Logs every five minutes and Analytics hourly. It writes raw JSON to S3 with Object Lock enabled in Compliance Mode (or Azure Blob with immutable storage policies) for the audit archive. It enqueues to SQS. A second Lambda dequeues and writes structured records to whatever your team queries - Snowflake, or plain Athena over the S3 archive.

The thing this saves you from is per-GB SIEM pricing. The thing it costs you is every detection rule, every dashboard, every parser update, and every on-call handoff. Pat Helland’s older AWS work on log-structured architectures - “Immutability Changes Everything” is the canonical paper - covers the underlying pattern well; the implementation is the boring part. In advisory work with mid-size companies, I see this picked when the team has solid platform engineering and a small but durable security function. I see it abandoned within eighteen months when those people leave and the next team inherits a cobbled-together pipeline they cannot explain to the auditor.

If you go this route, consider Cribl Stream as a router. It sits between your forwarder and the destination, and lets you fork the same event stream into two places - say, S3 for the auditor and a smaller SIEM tier for the SOC. The cost saving is real if your SIEM is volume-priced and most of the events are forensic rather than alertable.

Three gaps in native logging

This is the calibration moment. Native audit logs solve the audit story. They do not solve the network story.

Or rather, two-and-a-half gaps. The third one is partial: the Audit Logs API does cover claude.ai web chat events at the admin-event grain. What it does not have is the per-prompt detail you get from Code’s OTel stream.

Conversation content. The prompts and responses themselves are not in audit logs. The Data Export gated to Primary Owners gets them out, but it’s a separate pipeline with separate retention and a separate audit narrative. If your control requires bodies (legal hold, FINRA Rule 17a-4 supervision, attorney-client review queues), build that pipeline alongside the audit one, not on top of it. Financial services compliance covers the FINRA piece in more depth.

Network metadata below the application layer. TLS SNI and source ASN, destination cluster routing - none of that is in the audit log because it lives below the application boundary Anthropic operates. If your control requires that detail (egress proxy reasons, data residency proofs), the answer is an egress firewall or a wire inspector, used as a complement to native logs, not a substitute. I’ve spent two minutes on a wire-level vendor demo and another forty looking at the audit log I already had, and the audit log won every time.

Per-prompt detail outside Claude Code. OTel only emits from Code, not from claude.ai web or Claude Projects on Desktop. The Audit Logs API covers those surfaces at the admin-event grain - “user X created conversation Y at time Z” - but the per-prompt token and tool-call detail you get out of Code is Code-only. If web chat is where most of your usage lives, you are paying for telemetry on the surface that produces it least.

Native logs and wire inspection answer different questions. The auditor asks “who did what.” The network team asks “what left the building.” Both are real. Only the first is a 33-event schema sitting under your console.

Start with the cheapest path that survives audit

If you have a SIEM already, point your Audit Logs and Analytics puller at it. That’s the work for the first week. Sentinel if you are M365, Splunk if you have a Splunk team, Datadog if your engineering org runs everything through Datadog already. Pick what your SOC will read at 2am, not what looked good in the RFP. The SIEM your team opens beats the one with the best demo every time.

If you have OpenTelemetry already (Datadog Agent, Honeycomb collector, Splunk Observability), bolt Claude Code into the same collector before you stand up a new one. The compliance value of the OTel stream is not enormous unless you turn on the gated content flags, and turning those on is a one-way door you should not walk through without sign-off from data owners.

If you have neither, the roll-your-own pattern with S3 Object Lock plus Athena queries gets you to AU-2, AU-3, A.12.4.1, and CC7.2 with one Lambda and a weekend.

It will not be pretty. It will pass.

The pattern composes upward later when budget appears for a real SIEM, because the raw archive is the bit the SIEM ingests from on day one of that migration anyway.

The audit story does not have to be expensive. It has to be defensible. The defensible version starts with the logs you already pay for, sitting in an Anthropic console you can pull from this afternoon. The wire-level inspector pitch is a category answer to a problem you do not have. Spend the budget on the SOC reviewing the events instead.

If you are stuck between options, Blue Sheen’s AI advisory services is where we work through these architectural choices with mid-size companies trying to ship Claude into compliance-heavy environments.