Claude Code et la sécurité des agents locaux : API de conformité, visibilité et gouvernance des identités

Selon une enquête récente de Token Security, les agents locaux représentent 68,6 % des agents d’IA découverts dans les environnements clients. Parmi eux, Claude Code, le nouveau harness d’Anthropic, lit les fichiers, exécute des commandes shell, invoque des outils MCP et agit via les informations d’identification disponibles sur la machine du développeur. Cette bascule de l’IA du navigateur vers le poste de travail pose un problème de sécurité majeur : comment contrôler ce qui se passe sur des milliers d’endpoints quand les journaux d’activité seuls ne suffisent pas à déterminer si un accès est légitime ?

Les nouvelles endpoints de l’API de conformité d’Anthropic, dévoilées en août 2026, offrent aux équipes de sécurité une visibilité inédite sur ces sessions. Mais comme nous allons le voir, elles ne résolvent pas tout. La gouvernance des agents locaux exige une approche en trois couches - paramètres gérés, API de conformité, télémétrie endpoint - et surtout un chaînage avec l’identité pour transformer les données brutes en décisions de sécurité actionnables.

Comprendre le défi de sécurité des agents locaux comme Claude Code

Qu’est-ce qu’un harness et pourquoi change-t-il la donne ?

Un harness n’est pas un simple chatbot. C’est un orchestrateur sophistiqué qui prend les entrées de l’utilisateur et les transmet au modèle de langage (LLM) avec l’intégralité du contexte de session. Le LLM, lui, ne conserve aucun état : il reçoit tout ce dont il a besoin pour répondre de manière ponctuelle. Le composant qui exécute réellement les commandes, s’authentifie auprès de tiers et se connecte aux serveurs MCP, c’est le harneSS, pas le LLM.

Pour visualiser ce fonctionnement inhabituel, comparez-le au corps humain : le LLM est le cerveau, il traite les données et prend les décisions. Le harnais, lui, représente les mains, les jambes et les sens. Le cerveau tourne dans le cloud d’Anthropic, mais les mains opèrent sur vos postes de travail. C’est là que la visibilité et le contrôle doivent s’ancrer.

Contrairement à une application SaaS classique, Claude Code n’offre pas de console centrale pour superviser l’ensemble des agents sur les endpoints. Avant août 2026, les contrôles natifs d’Anthropic offraient une visibilité très limitée sur les actions de ses agents locaux, forçant les équipes à recourir à des extensions tierces pour atteindre un minimum de gouvernance.

Pourquoi les contrôles classiques échouent-ils ?

L’enquête de la Cloud Security Alliance (commandée par Token Security) révèle un paradoxe : 68 % des professionnels IT et sécurité jugent leur visibilité sur les agents d’IA élevée, alors que 82 % ont découvert dans l’année écoulée un agent dont l’existence était inconnue de la sécurité, et souligne l’urgence d’acquérir de nouvelles compétences en cybersécurité IA. Cette dissonance montre que la perception ne correspond pas à la réalité du terrain.

Les agents locaux héritent des identifiants, des permissions et de la position réseau de l’utilisateur connecté. Ils peuvent donc accéder à tout ce que le développeur peut atteindre - bases de données, secrets, API cloud - sans que les contrôles traditionnels (pare-feu, EDR) ne fassent la différence entre une action humaine légitime et une action automatisée malveillante, comme le démontrent les techniques de contournement des défenses Windows.

« Les journaux d’activité seuls ne peuvent pas vous dire si l’accès d’un agent est légitime. » - Dan Abramov, Security Researcher chez Token Security.

Les trois couches de gouvernance pour sécuriser Claude Code

Pour obtenir une visibilité complète sur les agents locaux, trois couches de collecte de données sont nécessaires : ce qu’offre Anthropic, ce que seul un agent endpoint peut collecter, et ce qu’il faut faire de ces informations.

Couche 1 : Les paramètres gérés (managed settings), la ligne de base politique

Le mécanisme de contrôle intégré d’Anthropic repose sur les managed settings. Chaque endpoint qui installe Claude Code possède un fichier JSON (sur Mac et Linux) ou des entrées de registre (sur Windows) qui définissent une politique prioritaire sur toute session Claude Code dans l’organisation.

Les règles disponibles couvrent :

• Listes d’autorisation et de blocage pour des serveurs MCP spécifiques
• Expressions régulières (regex) sur les commandes bash
• Désactivation des skills qui exécutent des commandes

Cette approche présente des limites évidentes : les politiques statiques d’autorisation/refus ne sont pas adaptées au rythme de l’IA moderne, et elles ignorent le contexte et l’intention. En pratique, c’est comme placer un gros rocher au milieu d’une rivière : il perturbe le flux mais ne l’arrête pas.

Couche 2 : L’API de conformité (Compliance API), les transcriptions de session

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

Ces endpoints donnent accès à tout ce qui est communiqué au modèle : prompts utilisateur, commandes bash, lectures/écritures, et même commandes MCP. Comme le modèle ne conserve aucun état côté serveur, le harnais renvoie l’intégralité du contexte à chaque tour. Si un élément atteint le modèle, il est loggé dans l’API de conformité.

« Les transcriptions de session vous permettent de journaliser l’utilisation des outils et de construire un inventaire de vos agents : chaque skill, serveur MCP et plugin utilisé. »

Cependant, il faut noter que les transcriptions locales peuvent contenir des données sensibles (PII, secrets, données client). Leur stockage devient une source de données sensible en soi - à traiter comme tel.

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

L’API de conformité et OpenTelemetry (OTel) capturent ce que les agents font. Mais ni l’un ni l’autre ne peut voir ce qui repose sur le disque : fichiers de configuration, skills et plugins installés (sauf s’ils ont été utilisés en session), ou processus lancés en dehors d’une session.

C’est ici qu’un agent endpoint spécialisé devient indispensable. Il peut :

1. Récupérer les fichiers de configuration : Token Security découvre en moyenne plus de 10 fichiers de configuration par agent local.
2. Analyser les fichiers .md des skills et plugins pour comprendre leurs capacités.
3. Corréler les logs EDR pour détecter des commandes bash risquées provenant d’agents.

« Les EDR fournissent des preuves, pas un modèle de gouvernance. Ils ne peuvent pas relier l’activité d’un agent à son propriétaire, son intention, ses identifiants et ses permissions. »

Analyser les transcriptions de session pour obtenir des logs actionnables

Pour obtenir une journalisation atomique des actions à partir des sessions Claude Code, il faut traiter les transcriptions de l’API de conformité. Chaque message est de type text, tool_use ou tool_result, encapsulé dans des champs user, assistant, etc.

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.

Serveurs MCP

Ils apparaissent comme un tool_use dont le nom est mcp__<server>__<command>. Les serveurs propriétaires (Jira, Slack, Notion) utilisent des noms lisibles. Les serveurs connectés par un utilisateur apparaissent sous forme d’UUID ; on retrouve le service via le suffixe de commande (slack_send_message) ou une correspondance UUID-nom. Notez que 35,1 % des serveurs MCP découverts par Token Security sont construits par la communauté ou d’origine inconnue — une surface d’attaque idéale pour une injection de prompt chiffrée.

Skills

Les skills ne sont pas nommés dans un champ dédié, mais on peut les inférer. Lorsqu’un skill se déclenche, le harnais envoie son fichier SKILL.md via l’API - soit en injectant le contenu directement, soit par une instruction Read sur son chemin. Cette lecture révèle le nom du skill et son emplacement.

Plugins

Les plugins sont plus complexes car ils regroupent plusieurs extensions. On retrouve leur nom par conventions de chemin lorsqu’un de leurs scripts ou .md est lu dans le contexte.

Important : tout cela fonctionne sans toucher aux prompts utilisateur, uniquement à partir des blocs tool_use et des lignes de commande.

Les limites des trois couches et le rôle crucial de la gouvernance des identités

Le tableau ci-dessous résume les apports et les angles morts de chaque couche :

Même combinées, ces trois couches ne suffisent pas. Aucune ne capture le contexte de votre entreprise et ne parvient à lier l’accès à l’intention. Un administrateur qui examine les transcriptions ne peut pas distinguer un skill malveillant téléchargé depuis Internet d’un skill légitime écrit par un ingénieur. Pour combler ce fossé, il faut corréler les skills et plugins en cours d’exécution avec ceux que les dépôts internes gèrent réellement.

C’est là qu’intervient la gouvernance des identités. La télémétrie montre ce qui s’est passé. La gouvernance nécessite de relier ces signaux à :

• Le propriétaire de l’agent
• Son intention
• Ses identités et permissions
• Ses voies d’accès

Ce contexte permet de déterminer si l’accès est justifié, de le réduire au moindre privilège et de le révoquer lorsque l’objectif de l’agent prend fin. L’identité est le plan de contrôle qui transforme les données d’endpoint et de session en sécurité d’agent IA exécutable.

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

Voici une démarche en six étapes pour les RSSI et équipes sécurité souhaitant maîtriser les agents locaux :

1. Déployer les paramètres gérés d’Anthropic via MDM - Appliquer une ligne de base interdisant les serveurs MCP non approuvés et les commandes bash dangereuses, tout en informant les développeurs des restrictions.

2. Activer l’API de conformité et collecter les transcriptions - Configurer la remontée des sessions locales vers un SIEM ou un data lake. Traiter ces données comme sensibles (chiffrement, accès restreint, politique de rétention de 30 jours maximum).

3. Déployer un agent de sécurité dédié sur les endpoints - Pour récolter les fichiers de configuration, les skills installés et les logs de processus. Corréler avec les logs EDR.

4. Parser les transcriptions pour extraire les actions atomiques - Développer des scripts ou utiliser une solution existante pour isoler les commandes bash, les invocations MCP et les lectures de skills.

5. Corréler avec un référentiel d’identités et de permissions - Relier chaque agent à son utilisateur, ses rôles et ses accès. Vérifier que les permissions utilisées (comme l’accès à une base de production) sont bien justifiées par le contexte de la session.

6. Mettre en place des boucles de détection et de réponse - Définir des alertes sur des comportements anormaux : utilisation d’un serveur MCP inconnu, exécution de commandes bash destructrices, présence d’un skill non référencé dans le dépôt interne.

« La télémétrie peut montrer ce qui s’est passé. La gouvernance exige de connecter ces signaux au propriétaire de l’agent, à son objectif, ses identités et ses permissions. »

Conclusion : l’identité comme plan de contrôle pour la sécurité des agents IA

Avec l’arrivée de Claude Code et des agents locaux, la sécurité des endpoints entre dans une nouvelle ère. Les configurations statiques et les transcriptions de session sont des briques utiles, mais insuffisantes si elles ne sont pas reliées à un système de gouvernance des identités. Seule cette approche permet de transformer une masse de données brutes en décisions de sécurité contextuelles, de détecter un skill malveillant avant qu’il ne cause des dégâts, et de réduire les permissions au strict nécessaire.

Les trois couches - paramètres gérés, API de conformité, endpoint - forment une base solide, mais l’ossature qui les rend opérationnelles, c’est l’identité. Intégrer des référentiels comme Active Directory, Azure AD ou des solutions IAM avec les flux d’agents locaux est la prochaine étape incontournable pour les organisations qui veulent profiter de l’IA sans compromettre leur sécurité.

Cet article s’appuie sur les travaux de Dan Abramov, Security Researcher chez Token Security, et sur les données de l’enquête Cloud Security Alliance commandée par Token Security. Pour approfondir, consultez les guides de l’ANSSI sur la sécurité des IA et les normes ISO 27001 relatives à la gestion des identités.