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

Selon une enquête récente de Token Security et de la Cloud Security Alliance, 68,6 % des agents d’IA découverts dans les environnements professionnels sont des agents locaux. Claude Code, le harnais d’Anthropic, en est l’exemple parfait : il lit les fichiers, exécute des commandes shell, invoque des outils MCP et agit avec les identifiants de la machine du développeur. Pourtant, jusqu’en août 2026, les équipes de sécurité disposaient d’une visibilité très limitée sur ces activités locales. Avec l’introduction de l’API Compliance d’Anthropic, un nouveau chapitre s’ouvre. Mais les logs d’activité seuls ne suffisent pas à déterminer si l’accès d’un agent est légitime. Cet article vous guide à travers les trois couches essentielles pour sécuriser Claude Code, en combinant paramètres gérés, transcripts de sessions et gouvernance des identités.

Le défi des agents locaux : pourquoi Claude Code est différent

Contrairement à un chatbot web classique, Claude Code est un harnais (harness) sophistiqué. Il ne se contente pas de répondre à des questions : il orchestre des actions sur le poste de travail. Le modèle d’IA (le « cerveau ») tourne dans le cloud d’Anthropic, mais les « mains » (exécution de commandes, connexions MCP, lecture/écriture de fichiers) s’exécutent localement. Cette architecture atypique remet en cause le modèle de responsabilité partagée traditionnel des SaaS.

Harnais vs chatbot : une différence fondamentale

Dans un chatbot, le modèle reçoit une requête et produit une réponse textuelle. Dans un harnais comme Claude Code, le gestionnaire envoie au LLM le contexte complet de la session (historique, fichiers, outils disponibles). Le LLM ne conserve pas d’état ; c’est le harnais qui exécute les actions. Les logs de l’API Compliance capturent tout ce qui est communiqué au modèle, mais certaines actions locales (hooks, décisions de permissions) ne transitent jamais par l’API. C’est là que réside le premier angle mort.

« Les agents locaux ne sont pas une catégorie de niche. Ils représentent 68,6 % des agents d’IA découverts par Token Security dans les environnements clients. » - Token Security / CSA Survey, 2026

De plus, 82 % des répondants à cette même enquête avaient découvert un agent dont la sécurité, l’informatique ou la gouvernance ignoraient l’existence. La visibilité est le maillon faible, et Claude Code amplifie ce problème en raison de son exécution majoritairement locale.

Les trois couches de visibilité pour sécuriser Claude Code

Pour gouverner efficacement les agents locaux, trois couches de données sont nécessaires : les paramètres gérés (politiques), les transcripts de sessions (API Compliance) et la télémétrie des endpoints. Aucune couche ne suffit seule.

Couche 1 : Les paramètres gérés - la ligne de base politique

Anthropic propose un mécanisme de paramètres gérés (managed settings). Sur chaque endpoint installant Claude Code, un fichier JSON (sous Mac/Linux) ou une clé de registre (sous Windows) définit des règles qui prévalent sur les configurations globales, de projet ou utilisateur. Avec un plan entreprise, vous appliquez ces politiques via l’interface d’administration ; sans celui-ci, votre MDM peut écrire le fichier sur chaque poste.

Les règles disponibles sont variées :

• Listes d’autorisation/blocage pour des serveurs MCP spécifiques
• Expressions régulières sur les commandes Bash
• Désactivation des skills qui exécutent des commandes
• Autres restrictions

Limite : ces politiques sont statiques. Elles ne tiennent pas compte du contexte ou de l’intention de la commande. Comme le dit Dan Abramov, chercheur en sécurité : « Ce sont de gros rochers au milieu d’une rivière - ils perturbent le flux mais ne l’arrêtent pas. »

En pratique, une politique trop stricte bridera la productivité des développeurs ; trop laxiste, elle laissera passer des actions dangereuses. Les paramètres gérés sont un premier rempart, mais pas une solution complète.

Couche 2 : L’API Compliance d’Anthropic - les transcripts de sessions locales

Le 11 août 2026, Anthropic a dévoilé de nouveaux endpoints pour l’API Compliance, spécifiquement dédiés aux sessions locales de Claude Code. Ces endpoints permettent de récupérer les métadonnées et les transcripts complets des sessions.

Les messages sont structurés en trois types de blocs :

1. text : invites utilisateur, réponses de l’assistant
2. tool_use : appels d’outils (Bash, MCP, etc.)
3. tool_result : résultats des outils

Cela signifie que chaque commande Bash, chaque lecture/écriture de fichier, chaque appel à un serveur MCP est loggé, à condition qu’il soit passé par le modèle. Les actions qui n’atteignent jamais le LLM (hooks, décisions de permissions locales) sont invisibles pour cette API.

« Les transcripts de sessions locales peuvent contenir des données sensibles, y compris des identifiants, des secrets et des données clients. Leur stockage devient une source de données sensible en soi. Traitez-le comme tel. » - Note de l’article original

Pour exploiter ces transcripts, il faut les parser. Par exemple, les commandes Bash apparaissent comme un tool_use avec "name": "Bash". Les serveurs MCP sont identifiables par le préfixe mcp__<serveur>__<commande>. Les skills se déduisent via les lectures de fichiers SKILL.md, et les plugins via des conventions de chemin.

Limite : si vous utilisez Claude Code avec un modèle qui n’est pas celui d’Anthropic (par exemple via Bedrock ou Google Cloud), l’API Compliance ne couvre pas ces sessions.

Couche 3 : Ce que seul l’endpoint peut vous dire

L’API Compliance et OpenTelemetry (OTel) capturent ce que les agents font. Mais ils ne voient pas ce qui se trouve sur le disque : fichiers de configuration, skills et plugins installés (s’ils n’ont pas été utilisés), processus lancés en dehors d’une session. Un agent endpoint (EDR) peut collecter ces données, comme les fichiers JSON de configuration, les .md des skills, et corréler les logs EDR pour détecter des commandes Bash risquées.

Token Security découvre en moyenne plus de 10 fichiers de configuration par agent local. Ces fichiers peuvent révéler des identifiants, des URLs, des clés API. De plus, Claude Code stocke l’historique des sessions localement pendant 30 jours par défaut. Un attaquant ayant accès à la machine peut lire ces transcripts.

L’EDR fournit des preuves, mais 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. C’est là que la gouvernance des identités devient indispensable.

Analyse des transcripts : techniques pour exploiter les données

Parser les transcripts de l’API Compliance demande une approche méthodique. Voici comment extraire les informations clés sans toucher aux invites utilisateur.

Commandes Bash

Chaque commande apparaît comme un bloc tool_use avec "name": "Bash". La commande complète se trouve dans la valeur input. Exemple :

{
  "type": "tool_use",
  "name": "Bash",
  "input": { "command": "grep -r 'API_KEY' /etc/" }
}

Serveurs MCP

Les appels MCP sont formatés avec "name": "mcp__<serveur>__<commande>". Pour les serveurs officiels (Jira, Slack, Notion), le nom est lisible. Pour les serveurs connectés par l’utilisateur, un UUID peut apparaître. Il faut alors maintenir une correspondance UUID-nom ou se fier au suffixe de commande.

Chiffre clé : 35,1 % des serveurs MCP découverts par Token Security sont issus de la communauté ou d’origine inconnue. Un risque supplémentaire de code malveillant.

Skills et plugins

Les skills ne sont pas étiquetés directement. Mais quand un skill se déclenche, le harnais envoie son contenu (via un Read du SKILL.md) dans le transcript. Le chemin du fichier et le contenu sont visibles. Les plugins, plus complexes (fichiers multiples), se repèrent via des conventions de chemin quand un de leurs composants est lu.

Conseil pratique : corréler les skills et plugins découverts dans les transcripts avec ceux gérés dans vos dépôts internes. Cela permet de distinguer un skill légitime d’un skill malveillant téléchargé depuis l’internet.

Limites des trois couches et nécessité de la gouvernance des identités

Même en combinant paramètres gérés, API Compliance et collecte endpoint, un angle mort persiste : le contexte de l’entreprise. Un administrateur qui examine les transcripts ne peut pas faire la différence entre un plugin malveillant et un plugin écrit par un ingénieur autorisé.

La gouvernance des identités est le chaînon manquant. Relier chaque agent à son propriétaire, ses identifiants, ses permissions et ses chemins d’accès permet de déterminer si l’accès est justifié, de réduire les privilèges au strict nécessaire, et de révoquer l’accès quand l’agent n’est plus utile. Comme le résume l’article original : « La télémétrie montre ce qui s’est passé. La gouvernance nécessite de connecter ces signaux au propriétaire, au but, aux identités, aux identifiants, aux permissions et aux chemins d’accès de l’agent. »

Mise en œuvre pratique : étapes pour sécuriser Claude Code dans votre organisation

Voici une démarche actionnable inspirée des bonnes pratiques et des recommandations d’Anthropic, à adapter à votre contexte.

1. Auditer l’existant : utilisez votre EDR pour inventorier tous les endpoints où Claude Code est installé. Identifiez les fichiers de configuration (managed-settings.json, etc.).
2. Configurer les paramètres gérés : définissez des listes d’autorisation pour les serveurs MCP internes, bloquez les commandes Bash dangereuses via regex, désactivez les skills non approuvés.
3. Activer l’API Compliance : abonnez-vous aux endpoints de session locale. Mettez en place un pipeline de collecte et de parsing des transcripts (attention à la sensibilité des données).
4. Déployer un agent de collecte locale (ou renforcer votre EDR) pour récupérer les configurations hors session, les skills/plugins installés, et les logs de processus locaux.
5. Implémenter une gouvernance des identités : pour chaque agent, identifiez le compte utilisateur, les credentials utilisés, et les permissions effectives. Réconciliez avec votre IAM (Active Directory, Okta, etc.).
6. Corréler les données : reliez les transcripts, les logs EDR et les données IAM pour détecter les anomalies (skill inconnu, accès non justifié, utilisation de secrets en clair).
7. Automatiser la réponse : déclenchez des alertes lorsqu’un skill non référencé dans votre catalogue interne est utilisé, ou lorsqu’une session contient des données sensibles.
8. Réviser régulièrement : les agents et leurs permissions évoluent. Planifiez des audits mensuels.

Exemple concret : un développeur utilise Claude Code pour automatiser le déploiement. Son skill personnel, non répertorié, exécute un script qui lit des clés API dans un fichier .env. Grâce à la corrélation entre le transcript (commande cat .env) et la politique IAM (le développeur n’a pas le droit d’accéder à cette clé), l’alerte est déclenchée et le skill est bloqué avant d’atteindre la production.

Conclusion : une sécurité holistique pour les agents IA locaux

Sécuriser Claude Code ne se résume pas à activer l’API Compliance ou à durcir les paramètres gérés. La clé réside dans une approche multicouche qui combine la visibilité des actions (transcripts), la configuration des endpoints (paramètres gérés) et la collecte locale (EDR), le tout orchestré par une gouvernance des identités. C’est cette dernière qui transforme des logs bruts en décisions de sécurité actionnables.

Les agents locaux représentent l’avenir de l’IA sur le poste de travail. Ignorer leur sécurité, c’est exposer son entreprise à des fuites de données, à des exécutions non autorisées et à une perte de contrôle. En suivant les étapes décrites et en adoptant une posture proactive, vous pouvez exploiter la puissance de Claude Code tout en gardant la main sur la sécurité. Le moment d’agir est maintenant : auditez vos endpoints, activez les logs, et connectez les identités.