Sécuriser Claude Code : API Compliance, visibilité locale et gouvernance des identités

Saviez-vous que 68,6 % des agents IA découverts dans les environnements professionnels sont des agents locaux, selon Token Security ? Parmi eux, Claude Code d’Anthropic se distingue par sa capacité à exécuter des commandes bash, lire des fichiers et interagir avec des outils MCP directement sur le poste de travail du développeur. Sécuriser Claude Code devient une priorité absolue pour les équipes de sécurité, d’autant plus qu’Anthropic a récemment dévoilé de nouveaux endpoints dans son API Compliance pour offrir une visibilité accrue sur ces sessions locales. Mais cette visibilité seule ne suffit pas : elle expose un problème plus vaste de gouvernance des identités et des accès. Comment concilier productivité des développeurs et maîtrise des risques ? Cet article vous guide à travers les trois couches de collecte de données essentielles, les techniques d’analyse des transcriptions et le rôle clé de l’identité pour transformer la télémétrie en gouvernance actionnable.

Le défi de la sécurité des agents locaux : pourquoi Claude Code change la donne

Claude Code n’est pas un simple chatbot. C’est un harness sophistiqué qui orchestre les interactions entre l’utilisateur et le modèle de langage (LLM). Contrairement à une interface web classique, il s’exécute sur le poste de travail du développeur, hérite de ses identifiants, de ses permissions et de sa position réseau, et peut lancer des commandes système, accéder au système de fichiers et se connecter à des services tiers via des serveurs MCP, des skills et des plugins. En d’autres termes, le cerveau (le LLM) tourne dans le cloud d’Anthropic, mais les mains et les pieds (le harness) opèrent sur votre endpoint. C’est ce basculement du navigateur vers le terminal qui bouleverse le modèle de sécurité traditionnel.

Un design non conventionnel

Dans une enquête commanditée par Token Security auprès de 418 professionnels IT et sécurité, 68 % estimaient avoir une visibilité élevée sur leurs agents IA. Paradoxalement, 82 % avaient découvert un agent dans l’année écoulée dont la sécurité, l’IT ou la gouvernance ignoraient l’existence. Ce contraste illustre le fossé entre la perception et la réalité. Avec Claude Code, il n’existe pas de console centrale pour superviser les configurations locales, les identités et les accès, ni le comportement à l’exécution. Avant août 2026, les contrôles natifs d’Anthropic offraient une visibilité très limitée sur ce que faisaient réellement ces agents, obligeant les équipes à recourir à des extensions tierces pour un minimum de gouvernance.

« La télémétrie montre ce qui s’est passé, mais la gouvernance nécessite de relier ces signaux au propriétaire, à l’intention, aux identités, aux accès et aux permissions. » - Cette réflexion d’un chercheur en sécurité résume parfaitement le défi. Les logs d’activité seuls ne peuvent pas dire si l’accès d’un agent est légitime. Il faut une approche multicouche.

Les trois couches de collecte de données pour gouverner Claude Code

Pour sécuriser efficacement Claude Code, trois sources de données doivent être combinées. Chacune apporte une perspective différente, mais aucune ne suffit isolément.

Layer 1 : Les paramètres gérés (Managed Settings), la base politique

Anthropic propose un mécanisme de contrôle appelé managed settings. Il s’agit d’un fichier JSON (sur Mac et Linux) ou d’entrées de registre (sur Windows) qui définit des règles prenant le pas sur toutes les autres configurations (globales, projet, utilisateur). Via le plan entreprise de Claude Code, vous appliquez ces politiques depuis l’interface d’administration ; sans ce plan, votre MDM peut déployer le fichier sur chaque endpoint.

Les règles disponibles incluent :

• des listes d’autorisation et de blocage pour des serveurs MCP spécifiques ;
• des expressions régulières sur les commandes bash ;
• la désactivation de l’exécution de commandes par les skills, etc.

Ces paramètres sont efficaces pour établir une ligne de base, mais ils sont statiques. Ils ne tiennent pas compte du contexte ni de l’intention. Comme un rocher au milieu d’une rivière, ils perturbent le flux sans l’arrêter complètement. Un développeur peut avoir besoin d’exécuter une commande légitime qui n’est pas dans la liste, ou une commande dangereuse peut passer si elle correspond à un pattern autorisé.

Layer 2 : L’API Compliance d’Anthropic

Jusqu’à récemment, l’API Compliance d’Anthropic couvrait principalement les actions de claude.ai (interface web et Claude Desktop), avec une couverture très faible de Claude Code. Le 11 août 2026, Anthropic a introduit de nouveaux endpoints dédiés aux sessions locales :

Ces endpoints offrent une visibilité sans précédent sur les interactions entre le harness et le modèle. Chaque message est structuré en trois types de blocs : text, tool_use, tool_result. Ils capturent les prompts utilisateur, les commandes bash, les lectures et écritures de fichiers, ainsi que les appels aux serveurs MCP. Comme le modèle ne conserve aucun état côté serveur, le harness renvoie l’intégralité du contexte à chaque tour. Tout ce qui atteint le modèle est donc logué dans l’API Compliance.

« C’est assez incroyable pour la gouvernance et la supervision », commente un expert en sécurité des agents IA. En traitant correctement ces transcriptions, vous pouvez inventorier les skills, les serveurs MCP et les plugins utilisés par chaque agent.

Attention : ces transcriptions peuvent contenir des données sensibles (PII, secrets, données clients). Leur stockage devient une source de données sensibles à part entière. Traitez-les comme telles, conformément au RGPD.

Layer 3 : Ce que seul l’endpoint peut révéler

L’API Compliance et OpenTelemetry capturent ce que les agents font. Mais ils ne voient pas ce qui réside sur le disque : fichiers de configuration, skills et plugins installés (sauf s’ils ont été utilisés dans une session), processus lancés en dehors d’une session. C’est là qu’un agent de sécurité sur l’endpoint (EDR) devient indispensable.

Un agent endpoint peut :

• récolter les fichiers de configuration (Token Security trouve en moyenne plus de 10 fichiers de configuration par agent local) ;
• extraire les fichiers .md des skills et plugins ;
• corréler les logs EDR pour détecter des commandes bash risquées provenant d’agents ;
• surveiller les processus fils lancés par Claude Code.

Mais l’EDR apporte des preuves, pas un modèle de gouvernance. Il ne peut pas relier l’activité d’un agent à son propriétaire, son intention, ses identifiants et ses permissions. La combinaison des trois couches est donc nécessaire, mais pas encore suffisante.

Analyser les transcriptions de session pour une visibilité granulaire

Pour obtenir une journalisation d’actions atomiques à partir des sessions Claude Code, il faut traiter les transcriptions de l’API Compliance. Chaque message se décompose en blocs text, tool_use ou tool_result. Voici comment en extraire des informations exploitables.

Commandes bash

Le cas le plus simple : chaque commande apparaît comme un tool_use avec "name": "Bash" et la ligne de commande complète dans la valeur input.

Serveurs MCP

Les appels aux serveurs MCP se présentent comme un tool_use dont le nom est mcp__<server>__<commande>. Les serveurs propriétaires utilisent des noms lisibles (Jira, Slack, Notion). Les serveurs connectés par l’utilisateur apparaissent sous forme d’UUID ; on retrouve le service via le suffixe de commande ou une table de correspondance que vous maintenez. Chaque appel représente un identifiant permanent sur cet endpoint. Selon Token Security, 35,1 % des serveurs MCP découverts sont issus de la communauté ou d’origine inconnue.

Skills

Les skills ne sont pas nommés explicitement, mais on peut les inférer. Quand un skill s’exécute, le harness envoie son contenu (SKILL.md) au modèle, soit en injectant le contenu directement, soit en émettant une commande Read sur son chemin. Cette lecture révèle le nom du skill et son emplacement : le champ input du tool_use contient le chemin, et le tool_result contient le contenu.

Plugins

Les plugins sont plus complexes car ils regroupent plusieurs extensions (skills, scripts). On retrouve leur nom via les conventions de chemin, lorsqu’un fichier .md ou un script du plugin est lu dans le contexte.

Exemple de bloc tool_use pour une commande bash :

{
  "type": "tool_use",
  "name": "Bash",
  "input": "cat /etc/passwd",
  "tool_use_id": "tu_01"
}

Toute cette analyse peut être automatisée sans toucher aux prompts utilisateur, en se basant uniquement sur les blocs tool_use et les lignes de commande.

OpenTelemetry : un complément nécessaire à l’API Compliance

OpenTelemetry (OTel) est un standard open source pour les traces, métriques et logs d’événements. Tous les harnesses courants l’intègrent nativement ; il suffit de le configurer. OTel capture des actions que l’API Compliance ne voit pas :

• les hooks qui s’exécutent localement entre la décision du modèle et l’exécution réelle de l’outil (ils peuvent bloquer une commande ou un prompt) ;
• les décisions de permission d’outils et leur auteur (politique, hook, utilisateur) ;
• les changements de mode bypassPermissions / auto qui sont logués dans OTel mais pas dans l’API Compliance.

OTel a été conçu pour journaliser des actions atomiques, tandis que les transcriptions de session sont des JSON longs et denses, sans variateur de verbosité. Si vous ne souhaitez pas collecter et stocker des transcriptions très volumineuses, OTel peut être l’outil plus léger (en attendant mieux).

Limite importante : si vous exécutez Claude Code avec un modèle qui n’est pas celui d’Anthropic (via Bedrock, Foundry, Google Cloud), l’API Compliance ne couvre pas ces sessions. OTel reste alors indispensable.

De la télémétrie à la gouvernance : le rôle central de l’identité

Les trois couches de collecte (managed settings, API Compliance, endpoint) fournissent une télémétrie riche, mais elles ne répondent pas à la question fondamentale : cet accès est-il légitime ? Un administrateur qui examine les transcriptions ne peut pas distinguer un plugin malveillant téléchargé depuis Internet d’un plugin légitime écrit par un ingénieur de l’entreprise. Pour combler ce fossé, il faut du contexte issu de l’organisation : corréler les skills et plugins qui tournent sur les endpoints avec ceux que vos dépôts internes gèrent effectivement. Cela augmente la confiance dans la légitimité.

La gouvernance des identités est le plan de contrôle qui transforme les données d’endpoint et de session en une sécurité actionnable pour les agents IA. Concrètement, cela signifie :

• Relier chaque agent à son propriétaire : savoir quel développeur a lancé la session, avec quels identifiants.
• Cartographier les accès : lister les identités, credentials, permissions et chemins d’accès utilisés par l’agent.
• Évaluer la justification : déterminer si l’accès est nécessaire au regard de la tâche.
• Appliquer le moindre privilège : réduire les permissions au strict nécessaire.
• Révoquer les accès lorsque l’agent n’est plus utilisé ou que son objectif est atteint.

Sans cette couche identitaire, vous accumulez des logs sans pouvoir les interpréter. Avec elle, vous pouvez détecter un skill malveillant et obtenir immédiatement une carte de chaleur de tous les endpoints où il s’exécute, puis agir rapidement.

Mise en œuvre : étapes actionnables pour sécuriser Claude Code

Voici une feuille de route pratique pour déployer une gouvernance efficace de Claude Code dans votre organisation :

1. Déployer les paramètres gérés via MDM : créez un fichier managed-settings avec les règles de base (blocage de serveurs MCP non approuvés, interdiction de certaines commandes bash). Distribuez-le sur tous les endpoints via votre solution de MDM.

2. Activer l’API Compliance et collecter les transcriptions : configurez l’accès aux endpoints de l’API Compliance pour votre équipe sécurité. Mettez en place un pipeline de collecte et de stockage sécurisé des transcriptions, en respectant les obligations RGPD (chiffrement, durée de conservation limitée).

3. Déployer un agent de détection sur les endpoints : utilisez un EDR ou un agent spécialisé (comme Token Security) pour collecter les fichiers de configuration, les skills et plugins installés, et les logs de processus. Corrélez ces données avec les transcriptions.

4. Mettre en place l’analyse automatisée des transcriptions : développez ou intégrez un outil qui parse les blocs tool_use pour extraire les commandes bash, les serveurs MCP, les skills et les plugins. Alimentez un inventaire centralisé des agents et de leurs composants.

5. Intégrer la gouvernance des identités : connectez les données collectées à votre référentiel d’identités (Active Directory, Okta, etc.) pour associer chaque session à un utilisateur, ses rôles et ses permissions. Établissez des règles de détection : par exemple, alerter si un agent utilise un serveur MCP inconnu ou exécute une commande bash sensible avec des credentials à privilèges élevés.

6. Établir un processus de réponse : définir des playbooks pour les incidents impliquant Claude Code : isolement du poste, révocation des accès, analyse forensique des transcriptions.

7. Former les développeurs : sensibilisez les équipes aux bonnes pratiques : ne pas saisir de secrets en clair dans les prompts, utiliser des variables d’environnement, étiqueter les projets contenant des données sensibles.

Conclusion : vers une gouvernance complète des agents IA locaux

Sécuriser Claude Code ne se résume pas à activer une API ou à déployer un EDR. C’est un défi multidimensionnel qui exige de combiner politiques statiques, télémétrie d’exécution, collecte locale et, surtout, gouvernance des identités. Les nouveaux endpoints de l’API Compliance d’Anthropic représentent une avancée majeure, mais ils ne sont qu’une pièce du puzzle. Sans la capacité à relier chaque action à un propriétaire, une intention et un contexte d’accès, vous restez aveugle face à la légitimité des comportements.

Dans un environnement où 82 % des organisations ont déjà découvert un agent IA inconnu, il est temps d’agir. Commencez par auditer vos déploiements de Claude Code, déployez les trois couches de collecte, et investissez dans une solution de gouvernance des identités adaptée aux agents. La sécurité de votre entreprise en dépend.