Claude Code : Sécuriser les agents IA locaux avec l'API Compliance d'Anthropic

Claude Code : Sécuriser les agents IA locaux avec l’API Compliance d’Anthropic

Selon une enquête de Token Security et de la Cloud Security Alliance, 68 % des professionnels de la sécurité estiment avoir une bonne visibilité sur leurs agents IA, mais 82 % ont découvert un agent dont l’existence était inconnue l’année dernière. Cette statistique illustre le défi majeur que pose Claude Code, l’assistant d’IA locale qui lit des fichiers, exécute des commandes shell et invoque des outils MCP avec les droits de son utilisateur. Depuis août 2026, Anthropic fournit une API Compliance permettant de mieux suivre ces actions, mais les logs seuls ne suffisent pas à déterminer la légitimité d’un accès.

Dans cet article, nous analysons les trois couches essentielles pour sécuriser Claude Code : les paramètres gérés, l’API Compliance et la télémétrie locale. Nous verrons pourquoi une approche combinée reste insuffisante sans un contexte identitaire complet.

Les agents locaux : un défi pour le modèle de responsabilité partagée

Qu’est-ce qu’un harnais d’agent IA ?

Un harnais (ou harness) n’est pas un simple chatbot. C’est un orchestrateur sophistiqué : il transmet le contexte de la session au LLM, mais c’est lui qui exécute les commandes, s’authentifie auprès de tiers et se connecte aux serveurs MCP. Le LLM est le cerveau ; le harnais est le corps, et la sécurité doit s’adapter à cette dualité. Dans Claude Code, le cerveau tourne chez Anthropic, mais les mains agissent sur votre terminal, ce qui rend la visibilité locale indispensable.

Pourquoi le SaaS classique ne suffit plus

Avec une application SaaS traditionnelle, on attend une console centralisée avec des politiques d’organisation. Claude Code échappe à ce modèle : 68,6 % des agents IA découverts par Token Security sont des agents locaux qui héritent des identifiants et des permissions de l’employé. Le harnais fonctionne là où l’utilisateur travaille, et Anthropic ne peut pas voir ce qui reste sur le disque.

« Un harnais d’agent local agit avec les droits de l’utilisateur, et les logs d’activité ne peuvent pas révéler si un accès est légitime. »

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

Anthropic propose des managed settings sous forme d’un fichier JSON (macOS, Linux) ou d’entrées de registre (Windows). Ces règles prennent le pas sur les configurations globales, projet ou utilisateur.

Ce que les paramètres gérés permettent

• Listes d’autorisation/refus pour des serveurs MCP spécifiques
• Expressions régulières sur les commandes bash
• Désactivation de l’exécution de commandes par les compétences (skills)
• Et d’autres règles configurables via l’interface GUI (plan Entreprise) ou votre MDM

Limites des politiques statiques

Les règles statiques limitent l’autonomie des développeurs et ne tiennent pas compte du contexte ou de l’intention. Comme un gros rocher au milieu d’une rivière, elles perturbent le flux sans l’arrêter. Par exemple, un développeur qui a besoin d’accéder à un serveur MCP « Jira » pour un projet critique sera bloqué par une règle trop restrictive, ou contourné par une exception manuelle.

Couche 2 : L’API Compliance - la transparence des sessions

Les nouveaux endpoints de l’API

Le 11 août 2026, Anthropic a introduit trois endpoints dédiés aux sessions locales :

Ces transcriptions capturent tout ce qui est communiqué au modèle : blocs text, tool_use et tool_result. Ainsi, elles incluent les commandes bash, les lectures/écritures de fichiers et les appels MCP.

Que peut-on en tirer ?

En analysant les transcriptions, vous pouvez :

• Logger l’utilisation de chaque outil
• Construire un inventaire des agents : leurs compétences, serveurs MCP et plugins
• Détecter les commandes dangereuses

Exemple concret : une commande bash apparaît comme {"name":"Bash", "input":"rm -rf /important"}. Un outil MCP pour Jira sera mcp__Jira__create_issue. Les compétences (skills) sont inférées lorsqu’un fichier SKILL.md est lu par le harnais.

« Les transcriptions de session locales peuvent contenir des données sensibles (PII, secrets). Leur stockage devient une source de données sensible à traiter comme telle. »

Les angles morts de l’API

• Actions hors LLM : les hooks (qui s’exécutent entre la décision du LLM et l’exécution) ne remontent pas dans l’API.
• Permissions locales : les décisions de permission (refus, contournement) ne sont visibles que via OpenTelemetry (OTel).
• Modèles non-Anthropic : si Claude Code utilise Bedrock, Foundry ou Google Cloud, aucune couverture API.

OpenTelemetry : un complément technique

OTel, standard open source pour les traces et métriques, est intégré dans chaque harnais courant. Il enregistre les actions atomiques (permissions, hooks) que l’API Compliance ne voit pas. Mais ses logs sont moins riches que les transcriptions longues et denses de l’API.

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

Ni l’API Compliance ni OTel ne voient ce qui réside sur le disque : fichiers de configuration, fichiers .md des compétences inutilisées, processus lancés hors session.

Les données locales essentielles

• Fichiers de configuration : Token Security découvre en moyenne plus de 10 fichiers de configuration par agent local.
• Historiques de sessions : Claude Code conserve les transcriptions locales pendant 30 jours (par défaut). Un attaquant ayant accès à l’endpoint peut les lire.
• Processus et EDR : les logs de l’antivirus ou d’EDR peuvent révéler des commandes bash dangereuses.

Comment exploiter ces données ?

1. Collecter les fichiers de configuration via un agent endpoint.
2. Corréler avec les logs EDR pour identifier les commandes suspectes.
3. Supprimer les transcriptions obsolètes contenant des données client.

Un exemple : un plugin non signé, téléchargé depuis une source inconnue, peut se retrouver dans un dossier ~/.claude/plugins. L’endpoint seul peut le détecter avant qu’il soit utilisé.

Analyser les transcriptions : méthodes pratiques

Commandes bash

Chercher "name": "Bash" dans les blocs tool_use. La commande complète est dans input.

Serveurs MCP

Les outils MCP apparaissent comme mcp__<serveur>__<commande>. Les serveurs propriétaires (Jira, Slack) ont des noms lisibles ; les serveurs communautaires montrent un UUID.

• 35,1 % des serveurs MCP découverts sont d’origine communautaire ou inconnue (Token Security).

Compétences (skills)

Quand un skill est activé, son contenu est injecté dans le prompt. Cherchez une lecture de fichier (Read) dont le chemin contient SKILL.md.

Plugins

Un plugin est un ensemble de fichiers. En suivant les chemins lus, vous pouvez reconstruire les noms de plugins via les conventions de nommage.

« Aucune de ces analyses ne nécessite de toucher aux prompts utilisateur - on travaille uniquement sur les blocs tool_use. »

Vers une gouvernance identitaire des agents IA

Les trois couches (paramètres gérés, API Compliance, endpoint) offrent une base, mais elles ne suffisent pas car :

• Aucune ne relie l’activité à un propriétaire, à ses identités, ses credentials et ses permissions.
• Un administrateur ne peut pas distinguer un plugin malveillant d’un plugin légitime sans contexte organisationnel.

L’identité comme plan de contrôle

Pour transformer les logs en décisions de sécurité, il faut :

1. Corréler les compétences et plugins avec ceux gérés par l’entreprise (dépôts internes).
2. Détecter un skill malveillant et cartographier ses déploiements.
3. Révoquer les accès quand l’agent n’est plus nécessaire.

L’identité 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.

Conclusion : agir dès maintenant

Claude Code apporte une puissance incroyable aux développeurs, mais il redéfinit la frontière de responsabilité. Les outils d’Anthropic ont progressé, mais ils ne remplacent pas une gouvernance centrée sur l’identité. Pour sécuriser vos agents IA locaux, combinez les trois couches de collecte et ajoutez un contexte identitaire : c’est la seule façon de répondre à la question « cet accès est-il légitime ? ».

Prochaine étape : auditez vos endpoints, activez l’API Compliance, et mettez en place une solution de gouvernance des identités pour vos agents IA. La sécurité des agents locaux commence par une visibilité complète et une gestion des droits adaptée.