Sécurisation des agents IA locaux : l’API Compliance d’Anthropic et la gouvernance des identités en action

Imaginez un développeur utilisant Claude Code pour automatiser le déploiement d’une application. L’agent lit des fichiers de configuration, exécute des commandes shell avec les droits de l’utilisateur, se connecte à des API tierces via des serveurs MCP et manipule des données potentiellement sensibles. Que se passe-t-il si l’une de ces actions est malveillante ou accidentellement destructive ? Sans visibilité ni contrôle, l’incident peut passer inaperçu pendant des semaines. Selon une enquête récente 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 non répertorié au cours de l’année écoulée. Ce paradoxe illustre l’ampleur du défi de la sécurisation des agents IA locaux. Avec l’essor d’outils comme Claude Code d’Anthropic, les entreprises françaises doivent repenser leur approche de la sécurité et de la conformité pour garder le contrôle sur ces assistants qui opèrent directement sur les postes de travail.

Pourquoi la sécurisation des agents IA locaux est un défi inédit

Claude Code n’est pas un simple chatbot. C’est un harness sophistiqué - un orchestrateur qui prend les entrées utilisateur, les envoie au LLM avec le contexte complet de la session, et exécute les actions décidées par le modèle. Contrairement aux assistants cloud, Claude Code fonctionne localement : il lit les fichiers, lance des commandes bash, invoque des outils MCP et agit à travers les identifiants disponibles sur la machine du développeur. L’IA est ainsi passée de l’onglet du navigateur au terminal, avec des conséquences majeures pour la sécurité.

Les agents locaux ne sont pas une catégorie marginale. Des observations de terrain montrent qu’ils représentent 68,6 % des agents IA découverts dans les environnements d’entreprise. Or, 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 de sécurité à utiliser des extensions tierces pour un minimum de gouvernance. La nouvelle API Compliance introduite par Anthropic change la donne, mais elle expose aussi un problème plus profond : les logs d’activité seuls ne permettent pas de déterminer si l’accès d’un agent est légitime.

Le harness est le véritable orchestrateur : il exécute les commandes, s’authentifie auprès des tiers et se connecte aux serveurs MCP. Le LLM n’est que le cerveau ; les mains et les jambes sont sur vos endpoints.

Cette distinction est cruciale. Le cerveau (le LLM) tourne dans le cloud d’Anthropic, mais les mains (le harness) opèrent sur vos endpoints. C’est là que la visibilité et le contrôle doivent s’exercer. Pourtant, aucune console centralisée ne permet de surveiller l’ensemble des agents locaux, leur configuration, leur identité et leurs accès. Le modèle de responsabilité partagée classique est mis à rude épreuve, et les administrateurs doivent assumer une charge accrue.

Les trois couches de visibilité pour Claude Code

Pour gouverner efficacement les agents locaux, trois couches de collecte de données sont nécessaires. Aucune ne suffit seule, mais leur combinaison permet une approche plus complète. Le tableau ci-dessous résume leurs rôles et leurs limites.

Couche 1 : Les paramètres gérés (Managed Settings)

Le mécanisme d’application d’Anthropic repose sur les managed settings. Chaque endpoint qui installe Claude Code possède un fichier JSON (sur macOS et Linux) ou des entrées de registre (sur Windows) qui définissent les règles de base. Ces paramètres prennent le pas sur les configurations globales, de projet et utilisateur, permettant d’imposer une politique cohérente dans toute l’organisation.

Les règles disponibles incluent :

• Listes d’autorisation et de blocage pour des serveurs MCP spécifiques.
• Expressions régulières sur les commandes bash (par exemple, n’autoriser que git, npm, docker).
• Désactivation de l’exécution de commandes par les skills.
• Contrôle de la lecture de fichiers.

Voici un exemple de fichier managed-settings.json :

{
  "managed-settings": {
    "allowed_mcp_servers": ["jira", "slack", "github"],
    "denied_mcp_servers": ["*"],
    "bash_command_regex": "^(git|npm|docker|kubectl|aws)",
    "disable_skills_commands": true,
    "disable_skills_file_read": false
  }
}

Ces règles peuvent être déployées via un MDM (Jamf, Intune, Workspace ONE) ou, pour les clients du plan entreprise, directement depuis l’interface d’administration d’Anthropic. Cependant, elles sont statiques et ne tiennent pas compte du contexte ni de l’intention. Un développeur qui a besoin d’exécuter une commande inhabituelle pour une tâche légitime sera bloqué, tandis qu’un attaquant pourrait contourner les règles si elles sont mal configurées. En pratique, les managed settings constituent une première barrière, mais elles ne suffisent pas à assurer une gouvernance fine.

Couche 2 : L’API Compliance d’Anthropic

Le 11 août 2026, Anthropic a introduit de nouveaux endpoints pour les sessions locales dans son API Compliance. Ces endpoints offrent une visibilité sans précédent sur les interactions entre le harness et le LLM :

Ces endpoints donnent accès à tout ce qui est communiqué au modèle, sous forme de blocs text, tool_use et tool_result. Ils couvrent les invites utilisateur, les commandes bash, les lectures et écritures de fichiers, et même les commandes MCP. Comme le modèle ne conserve aucun état côté serveur, le harness renvoie l’intégralité du contexte à chaque tour, ce qui permet à l’API Compliance de tout capturer.

Voici un exemple d’appel pour récupérer la liste des sessions :

curl -s -H "x-api-key: $ANTHROPIC_API_KEY" \
  "https://api.anthropic.com/v1/compliance/apps/sessions/local" | jq '.data'

Un exemple de réponse :

[
  {
    "session_id": "sess_abc123",
    "user_id": "user@company.com",
    "start_time": "2026-08-30T10:00:00Z",
    "end_time": "2026-08-30T12:30:00Z",
    "message_count": 45
  }
]

En analysant les transcriptions, vous pouvez :

• Journaliser l’utilisation des outils et identifier les commandes exécutées.
• Construire un inventaire des agents : leurs skills, les serveurs MCP utilisés, leurs plugins.
• Détecter des comportements anormaux, comme l’accès à des fichiers sensibles ou l’exécution de commandes non autorisées.

Pour extraire des informations actionnables, il est nécessaire de parser les messages. Chaque commande bash apparaît comme un tool_use avec "name": "Bash" et la commande dans input. Les serveurs MCP se présentent sous la forme mcp__<server>__<command> ; les serveurs propriétaires utilisent des noms lisibles (Jira, Slack, Notion), tandis que les serveurs connectés par l’utilisateur peuvent apparaître sous forme d’UUID. Dans ce cas, il faut maintenir une correspondance UUID-nom ou se fier au suffixe de la commande. Les skills sont détectables lorsqu’ils sont lus via un Read (le chemin du fichier .md est alors visible). Les plugins, plus complexes, se devinent par des conventions de chemin.

Les transcriptions de session locales peuvent contenir des données sensibles, y compris des informations personnelles (PII), des secrets et des données clients. Leur stockage devient une source de données sensibles en soi. Traitez-la comme telle, conformément au RGPD et aux recommandations de la CNIL.

Couche 3 : La télémétrie endpoint et l’OpenTelemetry

L’API Compliance capture ce que les agents font en interaction avec le LLM. Mais certaines actions restent invisibles : les hooks qui s’exécutent localement entre la décision du modèle et l’exécution réelle, les changements de mode (bypassPermissions / auto), ou encore les processus lancés en dehors d’une session. C’est là qu’interviennent la télémétrie endpoint et OpenTelemetry (OTel).

OpenTelemetry est un standard open-source pour les traces, métriques et logs. Chaque harness courant l’intègre nativement, il suffit de le configurer. OTel enregistre les décisions d’autorisation des outils et les changements de permissions, que l’API Compliance ne voit pas. En revanche, OTel a été conçu pour des actions atomiques, tandis que les transcriptions de session sont des JSON denses et longs. Si vous ne souhaitez pas stocker des transcriptions très volumineuses, OTel peut être plus facile à exploiter pour le logging temps réel.

Par ailleurs, un agent endpoint traditionnel (EDR) peut collecter ce qui réside sur le disque : fichiers de configuration, skills et plugins installés (leurs fichiers .md), et corréler les logs de processus pour détecter des commandes bash risquées provenant d’agents. Des observations de terrain indiquent qu’il existe en moyenne plus de 10 fichiers de configuration par agent local, dispersés sur l’endpoint. L’EDR peut les récupérer et les analyser.

Enfin, n’oublions pas une limite importante : si Claude Code utilise un modèle autre que celui d’Anthropic (via Amazon Bedrock, Google Cloud Vertex AI, ou un déploiement privé), l’API Compliance ne couvre pas ces sessions. La télémétrie endpoint devient alors la seule source de visibilité.

De la visibilité à la gouvernance : le rôle central de l’identité

Les trois couches précédentes fournissent une visibilité sans précédent, 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. Les logs montrent ce qui s’est passé, mais pas qui est à l’origine ni pourquoi.

La télémétrie montre ce qui s’est passé. La gouvernance nécessite de relier ces signaux au propriétaire, à l’objectif, aux identités, aux justificatifs, aux autorisations et aux chemins d’accès. L’identité est le plan de contrôle qui transforme les données de session et d’endpoint en une sécurité applicable des agents IA.

Pour combler ce fossé, il faut du contexte provenant d’autres parties de l’organisation. Il s’agit de corréler les skills et plugins exécutés sur les endpoints avec ceux que vos dépôts internes gèrent réellement. Une fois ce contexte établi, la détection d’un skill malveillant unique fournit une carte thermique de son exécution, et la mitigation devient rapide.

La gouvernance des identités est donc le pivot qui permet de passer de la simple observation à l’action. Elle permet de :

• Déterminer si l’accès d’un agent est justifié (appartient-il à un projet approuvé ?).
• Réduire les permissions au moindre privilège (l’agent a-t-il besoin d’accéder à l’ensemble du système de fichiers ?).
• Révoquer l’accès lorsque l’objectif de l’agent prend fin (suppression du compte de service associé).

En pratique, cela implique d’intégrer la découverte des agents avec votre référentiel d’identités (Active Directory, Okta, Azure AD) et votre solution de gestion des accès. Chaque agent doit être associé à un propriétaire, un but, et des justificatifs d’authentification limités. Les sessions de Claude Code doivent être traitées comme des accès utilisateur classiques, avec des revues périodiques.

Comment mettre en œuvre une stratégie de sécurisation des agents IA locaux

Voici une feuille de route en six étapes pour sécuriser Claude Code et, plus largement, les agents IA locaux dans votre organisation :

1. Déployez les paramètres gérés : Utilisez votre MDM ou le plan entreprise d’Anthropic pour appliquer une politique de base sur tous les endpoints. Bloquez les serveurs MCP inconnus, limitez les commandes bash autorisées, et désactivez les skills non approuvés.

2. Activez l’API Compliance et collectez les transcriptions : Assurez-vous que votre organisation est éligible à l’API Compliance. Configurez un pipeline de collecte régulière des sessions locales (par exemple, via un script cron ou une fonction serverless). Stockez les transcriptions de manière sécurisée, avec des contrôles d’accès stricts.

3. Déployez un agent endpoint ou un EDR : Complétez la visibilité cloud par une collecte locale des configurations, des skills et des plugins. Corrélez les logs EDR avec les transcriptions pour identifier les incohérences (par exemple, une commande bash exécutée mais non loguée dans l’API).

4. Mettez en place une gouvernance des identités : Intégrez la découverte des agents avec votre solution IAM. Créez des comptes de service dédiés pour les agents, avec des permissions limitées dans le temps et dans l’espace. Associez chaque session à un utilisateur et à un projet.

5. Formez vos développeurs et sensibilisez aux risques : Expliquez aux utilisateurs de Claude Code les bonnes pratiques : ne pas saisir de secrets en clair dans les invites, utiliser des variables d’environnement pour les tokens, étiqueter les sessions contenant des données sensibles, et supprimer les transcriptions inutiles après 30 jours.

6. Auditez régulièrement et adaptez vos politiques : Planifiez des revues mensuelles des inventaires d’agents, des transcriptions et des configurations. Les menaces évoluent, tout comme les capacités des agents. Mettez à jour vos listes d’autorisation MCP et vos expressions régulières en fonction des retours d’usage.

En suivant ces étapes, vous construirez une approche progressive mais solide de la sécurisation des agents IA locaux. N’oubliez pas que la sécurité est un processus continu : ce qui fonctionne aujourd’hui devra être ajusté demain.

Conclusion : anticiper les risques pour tirer parti de l’IA en toute sécurité

La sécurisation des agents IA locaux est un défi en constante évolution. Claude Code illustre parfaitement les nouvelles contraintes : un agent qui opère sur l’endpoint, hérite des identifiants de l’utilisateur et exécute des actions potentiellement dangereuses. L’API Compliance d’Anthropic apporte une avancée majeure en termes de visibilité, mais elle ne suffit pas. La gouvernance des identités est le chaînon manquant qui transforme les données brutes en décisions de sécurité éclairées.

En combinant paramètres gérés, API Compliance, télémétrie endpoint et gouvernance des identités, vous pouvez non seulement voir ce que font vos agents, mais aussi contrôler qui ils sont et ce qu’ils sont autorisés à faire. C’est ainsi que vous construirez une sécurité digne de la confiance que vous accordez à l’IA.

Les entreprises françaises, particulièrement soumises au RGPD et aux recommandations de l’ANSSI, ont tout intérêt à adopter dès maintenant une approche structurée. L’IA locale ne va pas disparaître ; elle va au contraire se généraliser. Aux équipes de sécurité de prendre le volant.