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

Isidore Bellemare

Selon une enquête récente de la Cloud Security Alliance, 68 % des professionnels de la sécurité estiment avoir une bonne visibilité sur les agents IA, mais 82 % ont découvert un agent non autorisé dans leur environnement au cours de l’année écoulée. Ce paradoxe illustre parfaitement le défi que représente la sécurisation de Claude Code et des agents locaux similaires. Avec la nouvelle API Compliance d’Anthropic, les équipes de sécurité disposent enfin d’outils pour surveiller les actions de ces agents, mais comme nous allons le voir, la visibilité seule ne suffit pas : elle doit s’accompagner d’une gouvernance des identités robuste.

L’essor des agents locaux : un défi pour la sécurité

Claude Code n’est pas un simple chatbot. C’est un harness - un orchestrateur sophistiqué qui lit des fichiers, exécute des commandes shell, invoque des serveurs MCP et agit à travers les identifiants disponibles sur la machine du développeur. L’IA est passée de l’onglet du navigateur au poste de travail, et cette mutation a des implications majeures pour la sécurité.

« Un harnais n’est pas un chatbot. Il prend l’entrée utilisateur et l’envoie au LLM avec le contexte complet de la session. Le composant qui exécute réellement les commandes, s’authentifie auprès de tiers et se connecte aux serveurs MCP, c’est le harnais, pas le LLM. »

Les agents locaux ne sont pas une catégorie de niche : selon Token Security, ils représentent 68,6 % des agents IA découverts dans les environnements clients. Ils héritent souvent des identifiants, de la position réseau et des permissions de l’employé. Pourtant, avant août 2026, les contrôles natifs d’Anthropic offraient une visibilité très limitée sur ce que ces agents faisaient réellement, forçant les équipes à utiliser des extensions tierces pour atteindre un minimum de gouvernance.

Avec les nouveaux endpoints de l’API Compliance, vous pouvez mieux gouverner vos agents locaux, mais il est essentiel de comprendre où se situent encore les limites.

Les trois couches de visibilité et de contrôle

Pour sécuriser efficacement Claude Code, vous devez combiner trois sources de données : les paramètres gérés, l’API Compliance et la télémétrie de l’endpoint. Aucune couche prise isolément ne suffit.

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

Le mécanisme d’application d’Anthropic repose sur les managed settings. Chaque endpoint qui installe Claude Code possède un enregistrement managed-settings : un fichier JSON sur Mac et Linux, des entrées de registre sur Windows. Ses règles prennent le pas sur les paramètres globaux, de projet et utilisateur, vous permettant d’imposer une ligne de base sur chaque session Claude Code de l’organisation.

Avec un plan entreprise, vous appliquez les politiques via l’interface graphique ; sans cela, votre MDM peut écrire l’enregistrement managed-settings sur les endpoints. Les règles disponibles couvrent :

  • Listes d’autorisation et de blocage pour des serveurs MCP spécifiques.
  • Expressions régulières sur les commandes bash.
  • Désactivation de l’exécution de commandes par les skills.
  • Et d’autres options.

Ces règles aident, mais elles sont statiques. Elles ne connaissent ni le contexte ni l’intention. En pratique, elles ressemblent à un gros rocher au milieu d’une rivière : elles perturbent le flux sans l’arrêter. De plus, elles brident la liberté des développeurs, ce qui peut générer des contournements.

L’API Compliance : la transparence des sessions

Jusqu’à récemment, l’API Compliance d’Anthropic couvrait principalement les actions 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 pour les sessions locales :

EndpointRetourne
GET /v1/compliance/apps/sessions/localListe des métadonnées de session
GET /v1/compliance/apps/sessions/local/{session_id}Métadonnées d’une session
GET /v1/compliance/apps/sessions/local/{session_id}/messagesTranscription complète de la session

Ces endpoints vous donnent une visibilité sur les agents s’exécutant sur les endpoints, basée sur leur interaction avec les modèles d’Anthropic. Tout ce qui est communiqué au modèle est enregistré dans trois types de blocs : text, tool_use et tool_result. Entre eux, ils couvrent les invites utilisateur, les commandes bash, les lectures et écritures de fichiers, et même les commandes MCP.

« Le modèle ne conserve aucun état côté serveur. Les fichiers .md des skills et plugins n’existent que sur l’endpoint, donc le harnais renvoie le contexte complet au modèle à chaque tour. Tout ce qui atteint le modèle atteint l’API Compliance. »

Parsées correctement, les transcriptions de session vous permettent de journaliser l’utilisation des outils et de construire un inventaire de vos agents : leurs skills, les serveurs MCP utilisés, leurs plugins.

Cependant, l’API Compliance a des limites importantes :

  • Elle ne couvre que les interactions avec les modèles Anthropic. Les sessions utilisant Bedrock, Foundry ou Google Cloud ne sont pas visibles.
  • Certaines actions sur l’endpoint n’atteignent jamais le LLM, comme les hooks qui s’exécutent localement entre la décision du modèle et l’exécution réelle de l’outil.
  • Les transcriptions peuvent contenir des données sensibles (PII, secrets, données clients). Leur stockage devient une source de données sensible en soi.

Ce que seul l’endpoint peut révéler

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

Un agent dédié peut :

  • Récolter les fichiers de configuration (Token Security découvre en moyenne plus de 10 fichiers de configuration par agent local).
  • Récupérer les fichiers .md des skills et plugins.
  • Corréler les logs EDR pour détecter des commandes bash risquées provenant d’agents.

De plus, Claude Code stocke localement tout l’historique des sessions pendant 30 jours par défaut. Un acteur malveillant qui accède à l’endpoint peut lire ces fichiers. La même prudence s’applique : traitez ces transcriptions comme des données sensibles.

Au-delà des logs : la gouvernance des identités comme pivot

Les trois couches précédentes 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 faire la différence entre un plugin malveillant téléchargé depuis Internet et un plugin légitime écrit par un ingénieur de l’entreprise. Pour combler ce fossé, il faut du contexte supplémentaire.

« La télémétrie peut montrer ce qui s’est passé. La gouvernance exige de relier ces signaux au propriétaire, à l’identité, aux accès. »

La gouvernance des identités devient le plan de contrôle qui transforme les données d’endpoint et de session en une sécurité enforceable. Concrètement, il s’agit de :

  • Corréler les skills et plugins exécutés avec ceux gérés dans vos dépôts internes.
  • Associer chaque session à un utilisateur, ses rôles et ses permissions.
  • Vérifier que les accès utilisés par l’agent sont conformes au principe du moindre privilège.
  • Révoquer les accès lorsque l’utilité de l’agent prend fin.

Cette approche permet de détecter un skill malveillant et d’obtenir immédiatement une carte de chaleur de tous les endpoints où il s’exécute, accélérant ainsi la remédiation.

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

Voici les étapes pratiques pour mettre en place une sécurité holistique de Claude Code dans votre organisation.

  1. Déployer les paramètres gérés via MDM ou le plan entreprise.

    • Définissez des règles de base : interdiction de certains serveurs MCP, validation des commandes bash par regex, désactivation des skills non approuvés.
    • Testez ces règles auprès d’un groupe pilote de développeurs avant un déploiement large.

  2. Activer l’API Compliance et traiter les transcriptions.

    • Intégrez les endpoints /local dans votre SIEM ou votre outil de sécurité.
    • Parsez les blocs tool_use pour extraire les commandes bash, les appels MCP et les lectures de fichiers.
    • Exemple de parsing pour une commande bash :
{
  "type": "tool_use",
  "name": "Bash",
  "input": "ls -la /etc"
}
  • Construisez un inventaire des serveurs MCP, skills et plugins utilisés.

  1. Déployer un agent de sécurité sur les endpoints.

    • Récoltez les fichiers de configuration, les skills et plugins installés.
    • Corrélez avec les logs EDR pour identifier les comportements anormaux.

  2. Mettre en place OpenTelemetry pour les actions non couvertes.

    • Les hooks et les décisions de permission n’atteignent pas l’API Compliance. OTel les enregistre.
    • Configurez OTel dans Claude Code pour tracer les permissions accordées ou refusées.

  3. Intégrer la gouvernance des identités.

    • Rapprochez les identifiants utilisés par les agents avec l’annuaire d’entreprise (Active Directory, Okta, etc.).
    • Appliquez des politiques de cycle de vie : révocation automatique des accès après désactivation du compte.

  4. Former les développeurs à l’utilisation responsable.

    • Sensibilisez à ne pas écrire de secrets en clair dans les sessions.
    • Encouragez l’utilisation de variables d’environnement et de coffres de secrets.

  5. Mettre en place une surveillance continue.

    • Analysez les transcriptions pour détecter des fuites de données.
    • Planifiez des revues périodiques des permissions des agents.

Conclusion : une approche holistique pour la sécurité des agents IA

La sécurisation de Claude Code ne peut reposer sur une seule couche. Les paramètres gérés imposent une ligne de base, l’API Compliance offre une transparence sans précédent sur les sessions, et la télémétrie d’endpoint complète le tableau avec les configurations statiques. Mais ces trois couches restent insuffisantes sans un pivot central : la gouvernance des identités. C’est elle qui permet de distinguer un accès légitime d’un accès malveillant, de tracer chaque action jusqu’à son propriétaire et d’appliquer le principe du moindre privilège.

En adoptant cette approche holistique, vous transformez la sécurité de vos agents IA d’un exercice réactif de collecte de logs en une démarche proactive de confiance et de contrôle. Les agents locaux sont là pour rester ; à vous de faire en sorte qu’ils travaillent pour vous, sans compromettre votre sécurité.