llm-integration.eu

Claude Compliance API: audit logs and SIEM export 2026

What the Claude Compliance API exports, how to pull audit logs into a SIEM, and what CloudTrail, Bedrock invocation logging and Vertex audit logs record instead.

Updated 12 min readFacts verified on 1 October 2026

TL;DR

The Claude Compliance API is a REST feed at api.anthropic.com/v1/compliance/* for Enterprise and Claude Platform organizations. It keeps audit events for 6 years and, with the right key, returns chats, files and Claude Code transcripts. It does not cover Claude on Bedrock or Vertex. There you need CloudTrail, invocation logging and Cloud Audit Logs.

What does the Claude Compliance API export?

The Claude Compliance API exports three kinds of data: an Activity Feed of who did what and when, the content of claude.ai chats, files and projects, and transcripts of Cowork and Claude Code sessions. The Activity Feed alone never contains prompt text. Content needs a separate scope, and only Claude Enterprise tenants get content endpoints at all.

Anthropic’s Compliance API overview describes the API as programmatic access to the organization’s activity, chats, files, projects, sessions and users. Two key types unlock it, and they are not interchangeable:

Key Created in Reaches Prefix
Compliance Access Key claude.ai, Organization settings, API Every compliance endpoint, per selected scope sk-ant-api01-
Admin API key Claude Console, Settings, Admin keys Activity Feed only sk-ant-admin01-
Claude API key Claude Console, API keys No compliance endpoint sk-ant-api03-

Scopes are fixed at creation: read:compliance_activities, read:compliance_user_data, delete:compliance_user_data and read:compliance_org_data. The setup guide warns that a key with read:compliance_user_data can read every chat, file, project and session transcript in every linked organization, including content the primary owner has never seen. Treat it like a production database credential. If a workflow both reads and deletes, Anthropic recommends two keys, so a leaked read key cannot delete anything.

Who can switch it on matters for your rollout plan. In a Claude Enterprise tenant, only the primary owner enables the API, and it cascades to every linked organization. A standalone Claude Console organization enables it under Settings, Security and gets Activity Feed access only. The Help Center article adds that Public Sector Enterprise organizations are excluded, and that Amazon Bedrock and Google Vertex AI deployments are outside its coverage.

What is not in the export is as important as what is. The Compliance API FAQ lists the gaps: no prompt or response text from Claude API workloads authenticated with an API key, no Claude Code sessions run through Bedrock, Google Cloud or Foundry, no Claude Code cloud sessions, no thinking blocks, and no content that a user or your retention policy already deleted. Since 24 September 2026, file and artifact activities no longer carry a file name or title; you look those up by ID through the content endpoints.

The older audit log CSV export still exists. The audit log article limits it to Enterprise owners, the past 180 days, 27 event types and a download link that expires after 24 hours, with no chat titles or content. We would use it for a one-off check, never as the record a DPO relies on.

How do you pull Claude audit logs with the API?

You pull Claude audit logs with GET /v1/compliance/activities, an x-api-key header and anthropic-version: 2023-06-01. Events are queryable within 1 minute and kept for 6 years. Recording starts only when the API is enabled, so enable it before the first user signs in. Turning it off creates a gap that cannot be filled later.

Setup in practice:

  1. The primary owner enables the Compliance API in claude.ai under Organization settings, API.
  2. Create a key with only read:compliance_activities for the SIEM pipeline. Content and delete scopes go on separate keys.
  3. Store the key in your secrets manager. The secret is shown once, and keys do not expire on their own.
  4. Run a first call to confirm the scope works, then build the scheduled pull.
  5. Ingest compliance_api_accessed events too, so the SIEM records who queried compliance data.

The smallest working call, as documented:

curl --fail-with-body -sS "https://api.anthropic.com/v1/compliance/activities?limit=1" --header "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY" --header "anthropic-version: 2023-06-01"

For a scheduled job, we prefer the window pattern from Anthropic’s integration guide: fixed created_at.gte and created_at.lt bounds, paging inside the window with after_id, and an overlap that you deduplicate on the activity id. It keeps workers stateless.

import os, json, datetime as dt, requests

URL = "https://api.anthropic.com/v1/compliance/activities"
HEADERS = {
    "x-api-key": os.environ["ANTHROPIC_COMPLIANCE_ACCESS_KEY"],
    "anthropic-version": "2023-06-01",
}

def pull_window(gte: str, lt: str) -> None:
    params = {"created_at.gte": gte, "created_at.lt": lt, "limit": 5000}
    while True:
        r = requests.get(URL, headers=HEADERS, params=params, timeout=60)
        r.raise_for_status()
        page = r.json()
        for activity in page["data"]:
            print(json.dumps(activity))  # one JSON line per event for the SIEM forwarder
        if not page["has_more"]:
            break
        params["after_id"] = page["last_id"]

fmt = "%Y-%m-%dT%H:%M:%SZ"
lt = dt.datetime.now(dt.timezone.utc).replace(second=0, microsecond=0) - dt.timedelta(minutes=5)
gte = lt - dt.timedelta(minutes=70)  # 60-minute window plus 10 minutes overlap
pull_window(gte.strftime(fmt), lt.strftime(fmt))

Keep the upper bound at least 1 minute in the past. Anthropic warns that a created_at.lt too close to the present permanently drops activities that index late. The page size maxes out at 5,000, and every /v1/compliance/* call shares a budget of 600 requests per minute per parent organization, so an hourly job with one key has plenty of headroom. A second team pulling content with another key spends from the same budget.

How do you feed Claude audit logs into a SIEM?

Feed Claude audit logs into a SIEM by writing each Activity as one JSON event and joining on actor.user_id, not on email. Treat the feed as at-least-once delivery and deduplicate on id. For eDiscovery, archive content as you ingest it, because deleted chats and expired transcripts cannot be retrieved later.

The join keys Anthropic documents for correlation with Splunk, Datadog, Microsoft Sentinel or similar tools:

Compliance API field Join it with Note
actor.user_id Identity provider user ID Stable, survives email changes; primary key
actor.email_address Directory email Only when no stable ID exists
actor.ip_address VPN, proxy, endpoint logs Absent on some actor types
actor.user_agent Device inventory Identifies client app
created_at Any source Time-window correlation

Check actor.type before you read any of these. A scim_directory_sync_actor has no IP address, and an anthropic_actor has a null email. Anthropic also notes that claude_chat_viewed and similar view events count app loads, not human views. Do not build an alert that says “user read 400 chats” on that event type.

For audit-proof exports, log the starting cursor, the final last_id, the record count, the run time and the request-id of the last page. The list endpoints return no total count or checksum, so this run log is your completeness evidence. Add a content hash per record for chain of custody.

Retention drives the archive decision:

Data Kept by Anthropic Your action
Activity Feed 6 years Archive only if your horizon is longer
Chats, files, projects Your claude.ai retention policy (indefinite by default) Export before retention or user deletion removes them
Local session transcripts (Claude Code, Cowork) 6 years by default, or your custom period; 30 days with HIPAA readiness Export if your hold exceeds the period
Content hard-deleted via the API Not retained Archive before any DLP delete runs

What do Bedrock and Vertex log instead?

On Bedrock and Vertex the Compliance API sees nothing, so the cloud logs are your audit trail. CloudTrail records every Bedrock InvokeModel and Converse call as a management event, with caller and source IP but no prompt. Prompts and responses need Bedrock model invocation logging or Vertex request-response logging, both off by default.

Source Records Prompt content Default Retention
Claude Compliance API Activity, plus chats and sessions with content scope Content endpoints only Off until enabled 6 years for activity
AWS CloudTrail (Bedrock) Caller, time, IP, model ID No On, Event history 90 days in Event history; a trail for longer
Bedrock model invocation logging Full request, response, token counts, identity.arn Yes, up to 100 KB inline Off Until you delete the configuration
Vertex Admin Activity logs Configuration changes No Always on 400 days (_Required)
Vertex Data Access logs Reads and predictions, incl. endpoints.rawPredict Not documented as content Off 30 days (_Default), 1 to 3650 configurable
Vertex request-response logging Sampled requests and responses to BigQuery Yes Off, Pre-GA Your BigQuery table

The Bedrock CloudTrail page confirms that InvokeModel, InvokeModelWithResponseStream, Converse and ConverseStream are management events, which CloudTrail logs by default. The documented example entry shows modelId, the IAM identity, sourceIPAddress and the user agent, with responseElements set to null. The lookup-events reference limits lookups to the last 90 days, one attribute per call and two requests per second per account and Region:

aws cloudtrail lookup-events --region eu-central-1 --lookup-attributes AttributeKey=EventName,AttributeValue=InvokeModel --start-time 2026-10-01T00:00:00Z --max-items 50 --query "Events[].{time:EventTime,user:Username,event:EventName}"

Run it once per Region you call Claude from. For the SIEM, do not poll lookup-events. Create a trail to S3 and let the SIEM read the bucket.

Model invocation logging is the Bedrock answer to “what was said”. It writes to S3 or CloudWatch Logs in the same account and Region, inlines bodies up to 100 KB and moves larger ones to S3. Two limits matter for EU setups: it only captures bedrock-runtime, not bedrock-mantle, and logs stay until you delete the configuration, so you set the lifecycle rule yourself. The EU profile and Region choices behind this are in our Claude on AWS Bedrock EU guide.

On Google Cloud, Vertex audit logging lists endpoints.rawPredict under Data Access (DATA_READ), and Data Access logs are not written until you enable them. Claude on Vertex uses rawPredict and streamRawPredict, and request-response logging lists Anthropic Claude among the supported partner models, configured via REST only, with a sampling rate between 0 and 1. A Logs Viewer cannot read Data Access logs in _Default; your SIEM service account needs Private Logs Viewer. Regional setup is covered in our Claude on Vertex AI in Europe guide.

Which GDPR and AI Act duties do these logs cover?

Logs cover two GDPR duties directly: accountability under Article 5(2) and security testing under Article 32(1)(d). The AI Act log duty in Article 26(6) applies only to deployers of high-risk systems and, for Annex III use cases, from 2 December 2027. For most Claude chat use, GDPR is the binding reason to log.

Article 5(2) GDPR makes the controller “responsible for, and be able to demonstrate compliance”. An Activity Feed export showing who accessed which project, plus your key-usage trail, is that evidence. Article 32(1)(d) asks for a process to regularly test and evaluate security measures; the SIEM rules built on these events are part of it. Article 30 requires a record of processing activities, and your Claude entry should name every log store, because each of them holds personal data.

That cuts the other way too. Logs with prompt bodies are personal data, so Article 5(1)(c) data minimisation and 5(1)(e) storage limitation apply to your archive. Six years of activity metadata at Anthropic does not mean six years of prompt bodies in your S3 bucket. Write a retention period per source into your deletion concept.

The AI Act text, per the Commission’s AI Act Service Desk, obliges deployers of high-risk AI systems to keep logs automatically generated by the system, to the extent they control them, “of at least six months”. Article 113 schedules Chapter III Sections 1 to 3 for 2 December 2027 (Annex III) and 2 August 2028 (Annex I). A Claude chatbot for internal drafting is not high-risk. A Claude workflow that screens job applicants likely is. Our EU AI Act guide for LLM deployers walks through that classification.

Run it yourself or outsource?

Running this pipeline in-house means owning keys, a scheduler, a SIEM parser, archive storage and the deletion concept. It is a small system, but it fails silently when nobody watches it. Outsourcing makes sense when you lack a 24/7 security team; keep key ownership and archive location in your own hands either way.

What the in-house work consists of, in our estimate rather than a sourced figure:

  • Platform or security engineer: build the pull job, rotate keys, fix the parser when Anthropic adds activity types (the docs tell you to pass unknown types through).
  • SOC analyst: tune alerts on admin changes, key creation, compliance_api_accessed and data exports.
  • DPO or legal: set retention per source, approve deletion runs, answer data subject and eDiscovery requests.
  • Recurring checks: monthly completeness evidence, quarterly key rotation, a test that the Compliance API is still enabled.

Outsourcing to a managed security or managed Claude provider makes sense when your SIEM is already run by an MSSP, or when no one inside can be on call for a broken pipeline. It makes less sense for eDiscovery itself: legal holds and content exports touch privileged material, and we would keep those with legal and an internal admin.

If you do outsource, demand these points in writing:

  1. Access model: the provider gets an Activity Feed key only, never delete:compliance_user_data; content scope only on documented request.
  2. DPA under Article 28 GDPR, a current subprocessor list and the location of their log storage.
  3. SLA for pipeline failure detection and for eDiscovery turnaround, measured in hours.
  4. Evidence: monthly run logs with cursor, count and request ID, as described above.
  5. Exit: the archive sits in your account (S3, BigQuery or SIEM tenant), so changing provider does not mean losing six years of history.

How the Claude Enterprise plan compares with the cloud routes on audit trail and data location is in our Claude Enterprise vs Bedrock comparison.

FAQ

Does the Claude Compliance API include prompts?

The Activity Feed does not. Prompts and responses come from the chat, message and session endpoints, which need a Compliance Access Key with read:compliance_user_data and work only for Claude Enterprise content. Prompts sent through the Claude API with an API key are never exposed.

Does the Compliance API cover Claude on Bedrock or Vertex?

No. Anthropic’s Help Center excludes Amazon Bedrock and Google Vertex AI deployments, and the FAQ excludes Claude Code run through Bedrock, Google Cloud or Foundry. Use CloudTrail and invocation logging on AWS, Cloud Audit Logs and request-response logging on Google Cloud.

Compliance API vs audit log CSV export: which should we use?

The Compliance API. The CSV export covers 180 days, 27 event types and no chat content, and its download link expires after 24 hours. The API keeps activity for 6 years, filters by type and time, and can feed a SIEM automatically.

What does Claude audit logging cost?

The Compliance API pages we read list no separate fee; ask your Anthropic account team before you budget. On AWS, CloudTrail data events cost extra and invocation logs incur S3 or CloudWatch storage. On Google Cloud, request-response logging offers a sampling rate to reduce storage costs.

How long do we have to keep Claude logs?

No single number. The AI Act sets at least six months only for high-risk deployers. GDPR asks you to keep personal data no longer than necessary. Anthropic keeps activity for 6 years, CloudTrail Event history 90 days, Google’s _Required bucket 400 days.

Who can enable the Claude Compliance API?

In a Claude Enterprise tenant, only the primary owner, in claude.ai under Organization settings, API. An organization owner can create keys limited to their own organization. A standalone Claude Console organization is enabled by an admin under Settings, Security.

Sources

  1. Claude Platform docs: Compliance API (1 October 2026)
  2. Claude Platform docs: Set up the Compliance API (1 October 2026)
  3. Claude Platform docs: Query the Activity Feed (1 October 2026)
  4. Claude Platform docs: Design your compliance integration (1 October 2026)
  5. Claude Platform docs: Compliance API FAQ (1 October 2026)
  6. Claude Help Center: Access the Compliance API (1 October 2026)
  7. Claude Help Center: Access audit logs (1 October 2026)
  8. AWS docs: Bedrock model invocation logging (1 October 2026)
  9. AWS docs: Monitor Bedrock API calls using CloudTrail (1 October 2026)
  10. AWS docs: CloudTrail lookup-events with the AWS CLI (1 October 2026)
  11. Google Cloud docs: Agent Platform audit logging (1 October 2026)
  12. Google Cloud docs: Request-response logging (1 October 2026)
  13. Google Cloud docs: Logging quotas and retention (1 October 2026)
  14. AI Act Service Desk: Article 26 (1 October 2026)
  15. AI Act Service Desk: Article 113 (1 October 2026)
  16. EUR-Lex: GDPR (Regulation 2016/679) (1 October 2026)

Related guides