Claude Compliance API : journaux d'audit et SIEM 2026

TL;DR

La Claude Compliance API est une interface REST sous api.anthropic.com/v1/compliance/* pour les organisations Enterprise et Claude Platform. Elle conserve les événements d’audit 6 ans et, avec la bonne clé, restitue chats, fichiers et transcriptions Claude Code. Elle ne couvre pas Claude sur Bedrock ou Vertex : là, il faut CloudTrail, la journalisation des invocations et Cloud Audit Logs.

Que permet d’exporter la Claude Compliance API ?

La Claude Compliance API exporte trois types de données : un Activity Feed (qui a fait quoi, quand), le contenu des chats, fichiers et projets de claude.ai, et les transcriptions des sessions Cowork et Claude Code. L’Activity Feed seul ne contient jamais le texte des prompts. Le contenu exige un scope dédié et n’existe que pour les locataires Claude Enterprise.

La présentation de la Compliance API la décrit comme un accès programmatique à l’activité, aux chats, fichiers, projets, sessions et utilisateurs de l’organisation. Deux types de clés l’ouvrent, et ils ne sont pas interchangeables :

Clé	Créée dans	Accès	Préfixe
Compliance Access Key	claude.ai, paramètres de l’organisation, API	Tous les points de terminaison, selon le scope	`sk-ant-api01-`
Clé Admin API	Claude Console, Settings, Admin keys	Activity Feed uniquement	`sk-ant-admin01-`
Clé API Claude classique	Claude Console, API keys	Aucun point de terminaison de conformité	`sk-ant-api03-`

Les scopes sont fixés à la création et ne changent plus : read:compliance_activities, read:compliance_user_data, delete:compliance_user_data et read:compliance_org_data. Le guide de configuration prévient qu’une clé dotée de read:compliance_user_data lit chaque chat, fichier, projet et transcription de session de toutes les organisations liées. Traitez-la comme un identifiant de base de production. Si un flux doit lire et supprimer, Anthropic conseille deux clés distinctes, pour qu’une clé de lecture compromise ne puisse rien effacer.

Qui l’active compte pour votre gouvernance. Dans un locataire Claude Enterprise, seul le Primary Owner peut le faire, et l’activation s’étend à toutes les organisations liées. Une organisation Claude Console autonome l’active sous Settings, Security et n’obtient que l’Activity Feed. L’article du Help Center précise que les organisations du secteur public sont exclues, tout comme les déploiements via Amazon Bedrock et Google Vertex AI.

Ce qui manque compte autant pour le DPO que ce qui est exporté. La FAQ de la Compliance API liste les angles morts : aucun prompt ni réponse des charges de travail de l’API Claude authentifiées par clé API, aucune session Claude Code passant par Bedrock, Google Cloud ou Foundry, aucune session cloud Claude Code, aucun bloc de réflexion, et rien de ce qu’un utilisateur ou votre durée de conservation a déjà supprimé. Depuis le 24 septembre 2026, les événements sur fichiers et artefacts ne portent plus de nom de fichier ; on le retrouve par identifiant via les points de terminaison de contenu.

L’ancien export CSV existe toujours. L’article sur les journaux d’audit le réserve aux Owners Enterprise, sur 180 jours et 27 types d’événements, avec un lien de téléchargement valable 24 heures et sans titres ni contenu des chats. Utile pour un contrôle ponctuel, insuffisant comme preuve face à la CNIL ou à un auditeur.

Comment récupérer les journaux d’audit Claude via l’API ?

On récupère les journaux d’audit avec GET /v1/compliance/activities, l’en-tête x-api-key et anthropic-version: 2023-06-01. Les événements sont interrogeables en 1 minute et conservés 6 ans. L’enregistrement ne démarre qu’à l’activation : activez l’API avant la première connexion. Toute désactivation crée un trou impossible à combler ensuite.

La mise en place en cinq étapes :

Le Primary Owner active la Compliance API dans claude.ai, paramètres de l’organisation, API.
Créez pour le flux SIEM une clé avec le seul scope read:compliance_activities. Les scopes de contenu et de suppression vont sur des clés séparées.
Rangez la clé dans votre coffre de secrets. Elle n’est affichée qu’une fois et n’expire pas d’elle-même.
Vérifiez le scope par un premier appel, puis construisez la collecte planifiée.
Ingérez aussi les événements compliance_api_accessed, pour que le SIEM trace qui a consulté les données de conformité.

L’appel minimal documenté :

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"

Pour une tâche planifiée, nous retenons le modèle par fenêtre temporelle du guide d’intégration : bornes fixes created_at.gte et created_at.lt, pagination dans la fenêtre avec after_id, léger chevauchement et dédoublonnage sur l’id de l’événement. Le worker reste sans état.

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))  # une ligne JSON par événement pour le collecteur SIEM
        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)  # fenêtre de 60 minutes plus 10 minutes de chevauchement
pull_window(gte.strftime(fmt), lt.strftime(fmt))

Gardez la borne haute au moins 1 minute dans le passé. Anthropic avertit qu’un created_at.lt trop proche du présent perd définitivement les événements indexés en retard. Une page contient au plus 5 000 événements, et tous les appels /v1/compliance/* partagent 600 requêtes par minute par organisation parente. Une collecte horaire a donc de la marge. Une deuxième équipe qui extrait du contenu avec sa propre clé consomme le même budget.

Comment alimenter un SIEM avec les journaux d’audit Claude ?

Écrivez chaque événement comme une ligne JSON dans le SIEM et faites la jointure sur actor.user_id, pas sur l’adresse e-mail. Le flux est livré au moins une fois : dédoublonnez sur id. Pour l’eDiscovery, archivez le contenu dès la collecte, car les chats supprimés et les transcriptions expirées ne sont plus récupérables ensuite.

Les clés de jointure documentées par Anthropic pour Splunk, Datadog, Microsoft Sentinel ou équivalent :

Champ de la Compliance API	À joindre avec	Remarque
`actor.user_id`	Identifiant utilisateur de l’IdP	Stable, même si l’e-mail change ; clé principale
`actor.email_address`	E-mail de l’annuaire	Seulement sans identifiant stable
`actor.ip_address`	Journaux VPN, proxy, poste	Absent pour certains types d’acteurs
`actor.user_agent`	Inventaire des postes	Indique l’application cliente
`created_at`	Toute source	Corrélation par fenêtre temporelle

Vérifiez d’abord actor.type. Un scim_directory_sync_actor n’a pas d’adresse IP, un anthropic_actor pas d’e-mail. Les événements claude_chat_viewed et apparentés comptent des chargements d’application, pas des lectures humaines. Une alerte du type « l’utilisateur a lu 400 chats » sur cette base produit des faux positifs, et vos représentants du personnel vous le reprocheront.

Pour un export opposable, consignez le curseur de départ, le dernier last_id, le nombre d’enregistrements, l’heure d’exécution et le request-id de la dernière page. Les points de terminaison de liste ne renvoient ni total ni somme de contrôle : ce journal d’exécution est votre preuve d’exhaustivité. Une empreinte par enregistrement assure la chaîne de conservation.

La durée de conservation décide de ce que vous archivez vous-même :

Données	Conservées par Anthropic	Votre action
Activity Feed	6 ans	Archiver seulement si votre horizon est plus long
Chats, fichiers, projets	Selon votre durée de conservation claude.ai (illimitée par défaut)	Exporter avant suppression par la règle ou l’utilisateur
Transcriptions de sessions locales (Claude Code, Cowork)	6 ans par défaut ou votre durée ; 30 jours avec HIPAA readiness	Exporter si votre gel juridique dure plus longtemps
Contenu supprimé définitivement via l’API	Non conservé	Archiver avant tout effacement DLP

Que journalisent Bedrock et Vertex à la place ?

Sur Bedrock et Vertex, la Compliance API ne voit rien : vos journaux cloud sont la piste d’audit. CloudTrail enregistre chaque appel Bedrock InvokeModel et Converse comme événement de gestion, avec l’appelant et l’IP source, mais sans prompt. Pour les prompts et réponses, il faut la journalisation des invocations Bedrock ou la journalisation requêtes-réponses Vertex, désactivées par défaut.

Source	Enregistre	Contenu des prompts	Par défaut	Conservation
Claude Compliance API	Activité, plus chats et sessions avec le scope contenu	Via les points de terminaison de contenu	Inactive jusqu’à activation	6 ans pour l’activité
AWS CloudTrail (Bedrock)	Appelant, heure, IP, identifiant du modèle	Non	Actif, Event history	90 jours en Event history ; un trail au-delà
Journalisation des invocations Bedrock	Requête, réponse, jetons, `identity.arn`	Oui, jusqu’à 100 Ko en ligne	Inactive	Jusqu’à suppression de la configuration
Journaux Admin Activity Vertex	Changements de configuration	Non	Toujours actifs	400 jours (`_Required`)
Journaux Data Access Vertex	Lectures et prédictions, dont `endpoints.rawPredict`	Non documenté comme contenu	Inactifs	30 jours (`_Default`), de 1 à 3650
Journalisation requêtes-réponses Vertex	Échantillon de requêtes et réponses dans BigQuery	Oui	Inactive, Pre-GA	Votre table BigQuery

La page Bedrock sur CloudTrail confirme que InvokeModel, InvokeModelWithResponseStream, Converse et ConverseStream sont des événements de gestion, journalisés par défaut. L’exemple documenté montre modelId, l’identité IAM, sourceIPAddress et l’agent utilisateur, avec responseElements à null. La référence lookup-events limite la recherche aux 90 derniers jours, à un attribut par appel et à deux requêtes par seconde par compte et par région :

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

Lancez-la pour chaque région depuis laquelle vous appelez Claude. Pour le SIEM, n’interrogez pas lookup-events en boucle : créez un trail vers S3 que le SIEM lit.

La journalisation des invocations répond, sur Bedrock, à la question « qu’a-t-on dit ? ». Elle écrit dans S3 ou CloudWatch Logs, dans le même compte et la même région, garde les corps jusqu’à 100 Ko dans l’entrée et déporte les plus gros dans S3. Deux limites comptent en Europe : seul bedrock-runtime est capté, pas bedrock-mantle, et les journaux restent tant que la configuration existe. La règle de cycle de vie alignée sur votre durée de conservation RGPD est à votre charge. Le choix de région et de profil UE est détaillé dans notre guide Claude sur AWS Bedrock en Europe.

Sur Google Cloud, la page journaux d’audit Vertex classe endpoints.rawPredict en Data Access (DATA_READ), et ces journaux ne sont écrits qu’après activation explicite. Claude sur Vertex passe par rawPredict et streamRawPredict, et la journalisation requêtes-réponses cite Anthropic Claude parmi les modèles partenaires pris en charge, configurable en REST uniquement, avec un taux d’échantillonnage entre 0 et 1. Le rôle Logs Viewer ne lit pas les journaux Data Access du bucket _Default : le compte de service du SIEM a besoin de Private Logs Viewer. La configuration régionale figure dans notre guide Claude sur Vertex AI en Europe.

Quelles obligations RGPD et AI Act ces journaux couvrent-ils ?

Les journaux couvrent directement deux obligations du RGPD : la responsabilité (article 5, paragraphe 2) et la procédure de test régulier de la sécurité (article 32, paragraphe 1, point d). L’obligation de journaux de l’AI Act, article 26, paragraphe 6, ne vise que les déployeurs de systèmes à haut risque, à partir du 2 décembre 2027 pour l’annexe III.

L’article 5, paragraphe 2, du RGPD impose au responsable du traitement d’être en mesure de démontrer sa conformité. Un export de l’Activity Feed montrant qui a accédé à quel projet, plus la trace d’usage de vos clés, constitue cette preuve. L’article 32, paragraphe 1, point d, exige une procédure pour tester et évaluer régulièrement les mesures de sécurité ; les règles SIEM bâties sur ces événements en font partie. Enfin, votre registre des activités de traitement (article 30) doit citer chaque stockage de journaux, puisque chacun contient des données personnelles.

L’inverse vaut aussi. Des journaux contenant des prompts sont des données personnelles : minimisation (article 5, paragraphe 1, point c) et limitation de la conservation (point e) s’appliquent à votre archive. Six ans de métadonnées chez Anthropic ne justifient pas six ans de prompts dans votre bucket S3. Fixez une durée par source dans votre politique de conservation.

Le texte de l’AI Act, consultable sur l’AI Act Service Desk de la Commission, impose aux déployeurs de systèmes d’IA à haut risque de conserver les journaux générés automatiquement, dans la mesure où ils les contrôlent, pendant au moins six mois. L’article 113 fixe l’application des sections 1 à 3 du chapitre III au 2 décembre 2027 (annexe III) et au 2 août 2028 (annexe I). Un chat Claude interne d’aide à la rédaction n’est pas à haut risque. Un flux Claude qui trie des candidatures l’est probablement. Notre article sur l’AI Act pour les entreprises utilisant des LLM détaille cette qualification.

Exploiter en interne ou externaliser ?

Exploiter la chaîne en interne, c’est porter clés, ordonnanceur, parseur SIEM, archive et politique de conservation. Le système est petit, mais il tombe en panne sans bruit si personne ne le surveille. L’externalisation se justifie sans équipe sécurité disponible 24 h sur 24. Dans tous les cas, gardez la maîtrise des clés et l’emplacement de l’archive.

Ce que représente le travail interne, selon notre estimation et non un chiffre sourcé :

Ingénieur plateforme ou sécurité : construire la collecte, faire tourner les clés, adapter le parseur quand Anthropic ajoute des types d’événements (la documentation demande de laisser passer les types inconnus).
Analyste SOC : régler les alertes sur les changements d’administration, la création de clés, compliance_api_accessed et les exports.
DPO ou juridique : fixer les durées par source, valider les suppressions, traiter les demandes d’accès et d’eDiscovery.
Contrôles récurrents : preuve d’exhaustivité mensuelle, rotation trimestrielle des clés, test que la Compliance API est toujours active.

Confier la chaîne à un prestataire de sécurité managée ou de Claude managé a du sens si votre SIEM est déjà exploité par un MSSP, ou si personne en interne ne peut assurer l’astreinte d’un pipeline en panne. Cela en a moins pour l’eDiscovery elle-même : gels juridiques et exports de contenu touchent des données sensibles, que nous laisserions au juridique et à un administrateur interne.

Si vous externalisez, exigez par écrit :

Modèle d’accès : le prestataire reçoit une clé Activity Feed seulement, jamais delete:compliance_user_data ; scope contenu uniquement sur demande documentée.
Contrat de sous-traitant au sens de l’article 28 du RGPD, liste à jour des sous-traitants ultérieurs et lieu de stockage de ses journaux.
SLA de détection des pannes de collecte et de délai de réponse eDiscovery, en heures.
Preuves : journaux d’exécution mensuels avec curseur, volume et request-id, comme décrit plus haut.
Réversibilité : l’archive se trouve dans votre compte (S3, BigQuery ou locataire SIEM), pour qu’un changement de prestataire ne coûte pas six ans d’historique.

La comparaison de l’offre Claude Enterprise avec les routes cloud, traçabilité comprise, figure dans notre article sur le prix de Claude Entreprise en Europe.

FAQ

La Claude Compliance API contient-elle les prompts ?

L’Activity Feed, non. Prompts et réponses passent par les points de terminaison de chats, messages et sessions, qui exigent une Compliance Access Key avec read:compliance_user_data et ne valent que pour le contenu Claude Enterprise. Les prompts envoyés à l’API Claude avec une clé API ne sont jamais exposés.

La Compliance API couvre-t-elle Claude sur Bedrock ou Vertex ?

Non. Le Help Center d’Anthropic exclut Amazon Bedrock et Google Vertex AI, et la FAQ exclut Claude Code passant par Bedrock, Google Cloud ou Foundry. Sur AWS, utilisez CloudTrail et la journalisation des invocations ; sur Google Cloud, Cloud Audit Logs et la journalisation requêtes-réponses.

Compliance API ou export CSV des journaux d’audit : lequel choisir ?

La Compliance API. L’export CSV couvre 180 jours et 27 types d’événements, sans contenu des chats, et son lien expire après 24 heures. L’API conserve l’activité 6 ans, filtre par type et période, et alimente un SIEM automatiquement.

Combien coûte la journalisation d’audit de Claude ?

Les pages de la Compliance API que nous avons lues n’indiquent aucun tarif distinct ; interrogez votre interlocuteur Anthropic avant de budgéter. Sur AWS, les événements de données CloudTrail sont facturés en plus et les journaux d’invocation génèrent du stockage S3 ou CloudWatch. Sur Google Cloud, le taux d’échantillonnage réduit le coût de stockage.

Combien de temps conserver les journaux Claude ?

Il n’y a pas de durée unique. L’AI Act impose au moins six mois aux seuls déployeurs de systèmes à haut risque. Le RGPD interdit de garder des données personnelles plus longtemps que nécessaire. Anthropic garde l’activité 6 ans, l’Event history de CloudTrail 90 jours, le bucket _Required de Google 400 jours.

Qui peut activer la Claude Compliance API ?

Dans un locataire Claude Enterprise, seul le Primary Owner, dans claude.ai, paramètres de l’organisation, API. Un Organization Owner peut créer des clés limitées à sa propre organisation. Une organisation Claude Console autonome est activée par un administrateur sous Settings, Security.

Sources

Claude Platform docs : Compliance API (1 octobre 2026)
Claude Platform docs : configurer la Compliance API (1 octobre 2026)
Claude Platform docs : interroger l'Activity Feed (1 octobre 2026)
Claude Platform docs : concevoir l'intégration (1 octobre 2026)
Claude Platform docs : FAQ Compliance API (1 octobre 2026)
Claude Help Center : Access the Compliance API (1 octobre 2026)
Claude Help Center : Access audit logs (1 octobre 2026)
AWS docs : Bedrock model invocation logging (1 octobre 2026)
AWS docs : surveiller les appels Bedrock avec CloudTrail (1 octobre 2026)
AWS docs : CloudTrail lookup-events avec l'AWS CLI (1 octobre 2026)
Google Cloud docs : journaux d'audit Agent Platform (1 octobre 2026)
Google Cloud docs : journalisation requêtes-réponses (1 octobre 2026)
Google Cloud docs : quotas et conservation Logging (1 octobre 2026)
AI Act Service Desk : article 26 (1 octobre 2026)
AI Act Service Desk : article 113 (1 octobre 2026)
EUR-Lex : RGPD (règlement 2016/679) (1 octobre 2026)