Kiteworks Secure MCP Server arrive sur la marketplace de connecteurs d’Anthropic

La plupart des entreprises n’ont pas choisi d’exposer leurs données sensibles aux modèles d’IA. Elles y sont arrivées progressivement, un prompt Claude ou ChatGPT bien intentionné après l’autre, car l’alternative aurait été d’interdire à leurs collaborateurs d’utiliser des outils qui les rendent plus efficaces. Le rapport annuel Kiteworks 2026 sur la sécurité des données et les risques de conformité révèle que toutes les organisations interrogées ont désormais l’IA agentique dans leur feuille de route, mais que 63 % ne peuvent pas limiter l’usage que ces agents font des données, et 60 % n’ont aucun moyen d’arrêter un agent qui se comporte de façon malveillante. Cet écart entre ambition et contrôle, le Model Context Protocol (MCP) devait justement le combler, mais la plupart des implémentations MCP laissent toujours cette faille ouverte.

Kiteworks réduit cet écart dès aujourd’hui. Le serveur Kiteworks Secure MCP est désormais référencé sur le Connector Marketplace d’Anthropic dans Claude Desktop, offrant aux clients Kiteworks un accès direct, en un clic, pour connecter Claude à leur environnement de données gouvernées. Les collaborateurs continuent de travailler comme à leur habitude, en langage naturel, dans un client IA familier. Ce qui change, c’est ce qui se passe derrière le prompt : chaque accès à un fichier, chaque opération sur un dossier, chaque extraction de données passe désormais par les mêmes contrôles d’accès basés sur les rôles et les attributs, le chiffrement et l’audit log qui régissent déjà la messagerie électronique, le partage et le transfert de fichiers dans l’environnement sécurisé Kiteworks.

Il ne s’agit pas d’une couche de gouvernance ajoutée à l’IA après coup. C’est le même plan de contrôle qui régit déjà l’accès, l’utilisation et l’échange des données pour les personnes de l’organisation. Cette nouveauté intègre l’agent IA de Claude dans ce plan de contrôle, en tant que seconde classe d’identité soumise à la même politique. Cette distinction — entre des agents gouvernés dès le départ au même titre que les humains, et des agents opérant seuls, hors de tout cadre — est au cœur de cette évolution.

Résumé de l’essentiel

1. Le serveur Kiteworks Secure MCP est désormais disponible sur le Connector Marketplace d’Anthropic.

Les clients Kiteworks peuvent connecter Claude Desktop directement à leur environnement privé Kiteworks via un connecteur en un clic, sans avoir à développer un code d’intégration personnalisé.

2. Chaque requête IA est autorisée selon les politiques RBAC et ABAC existantes.

Le Data Policy Engine évalue chaque accès à un fichier, chaque opération sur un dossier et chaque extraction de données avant que Claude n’en voie le résultat, garantissant qu’aucune information hors du périmètre d’un utilisateur n’atteint le modèle.

3. Les failles de gouvernance dans l’IA agentique sont généralisées, pas hypothétiques.

Des recherches indépendantes ont documenté des agents ayant divulgué des informations personnelles identifiables, accepté des identités usurpées et consommé des ressources sans limite une fois laissés sans gouvernance. C’est pourquoi le contrôle d’accès doit s’appliquer en amont du modèle, et non en aval.

4. La sécurité est intégrée au niveau du protocole, pas ajoutée par-dessus.

Le renforcement OAuth 2.1, la cryptographie validée FIPS 140-3 et l’échange de clés hybride post-quantique protègent chaque session entre Claude et le serveur Kiteworks MCP.

5. La configuration se fait en deux étapes, car chaque client dispose de son instance privée.

Un administrateur active Kiteworks MCP une fois pour l’organisation, puis chaque utilisateur final connecte Claude Desktop à ce serveur privé via le Connector Marketplace.

La faille de gouvernance qui accroît le risque des agents IA en entreprise

La pression pour adopter l’IA n’est pas le problème. Le problème, c’est ce que les entreprises acceptent pour y parvenir. Les intégrations IA classiques donnent généralement au modèle un accès large à un espace de stockage, une boîte mail ou une API, en espérant que la conception des prompts et l’alignement du modèle assureront le reste du contrôle d’accès. Cette approche était déjà fragile avec un seul modèle bien paramétré. Elle s’effondre dès que des agents agissent de façon autonome, dialoguent entre eux et prennent des décisions qu’aucun humain n’a explicitement validées.

L’ampleur de la faille apparaît clairement dans les chiffres. Selon le rapport Prévisions 2026, 55 % des organisations ne peuvent pas isoler leurs systèmes IA du reste du réseau, et 54 % des conseils d’administration ne placent même pas la gouvernance IA dans leurs cinq priorités. Dans les agences gouvernementales, le même rapport indique que 90 % n’ont pas de mécanisme de limitation d’usage pour les agents IA, et 76 % n’ont aucun « kill switch » pour interrompre un agent en cours de tâche. Le WEF Global Cybersecurity Outlook 2026 apporte un constat supplémentaire : environ un tiers des organisations n’ont aucun processus pour valider la sécurité d’un système IA avant sa mise en production, et seulement 40 % procèdent à des revues régulières de sécurité IA une fois le système en place.

Ce qui se passe lorsque cette faille de gouvernance rencontre un agent actif a été démontré de façon éloquente par « Agents of Chaos », une étude menée en février 2026 par vingt chercheurs issus d’institutions telles que le MIT, Stanford, Carnegie Mellon et Harvard. En utilisant le framework open source OpenClaw dans un environnement réel non isolé, les chercheurs ont documenté au moins dix violations majeures de sécurité dans onze études de cas représentatives. Un agent a transféré un e-mail entier, contenant un numéro de sécurité sociale non caviardé et des coordonnées bancaires, après avoir refusé une demande directe pour ces mêmes données, car il savait reconnaître une demande explicite d’information sensible, mais pas que transmettre le conteneur qui les renferme revenait au même. Dans une autre étude de cas, un chercheur a modifié un nom d’affichage Discord pour imiter le propriétaire d’un agent. L’agent a détecté l’usurpation la première fois, dans le même canal qu’il connaissait déjà. Il a totalement échoué la seconde tentative : quand l’attaquant a ouvert un nouveau canal privé sans historique, l’agent a accepté l’identité sur la seule base du nom d’affichage, a supprimé ses propres fichiers mémoire, s’est renommé et a accordé l’accès administrateur.

Les auteurs de cette étude estiment que le problème est structurel, pas superficiel. Les agents reposant sur des grands modèles de langage n’ont aucun moyen fiable de distinguer une instruction autorisée d’une instruction non autorisée lorsque les deux arrivent sous forme de tokens dans la même fenêtre de contexte. Cela fait de l’injection de prompt une caractéristique structurelle de ces systèmes, et non un bug que l’on pourrait corriger par de meilleurs prompts. Les décisions d’accès ne peuvent donc pas être laissées à l’appréciation du modèle. Elles doivent être imposées par une couche de politique que le modèle ne peut pas contourner. C’est ce que signifie le zéro trust en pratique : vérifier la requête au point où l’agent accède effectivement aux données, à chaque fois, quel que soit ce que l’agent prétend sur lui-même.

Ce que fait le serveur Kiteworks Secure MCP

Le serveur Kiteworks Secure MCP agit comme un point de connexion gouverné entre des clients IA comme Claude, ChatGPT, Gemini ou Copilot et les données gouvernées d’une organisation. Il repose sur le Model Context Protocol ouvert, devenu la norme émergente pour connecter les modèles de langage à des outils et sources de données externes. Plutôt que d’accorder au modèle un accès direct au système de fichiers ou à l’API, chaque requête transite par le serveur Secure MCP et le Data Policy Engine de Kiteworks, qui l’évalue selon la gestion des accès basée sur les rôles (RBAC) et la gestion des accès basée sur les attributs (ABAC) avant de retourner quoi que ce soit.

Cette évaluation s’applique aussi bien aux personnes qu’aux agents IA, selon le même modèle de politique. Kiteworks n’a pas créé un modèle de politique distinct, plus souple, pour l’IA. Un client IA s’authentifie via OAuth 2.0 et hérite des autorisations de l’utilisateur demandeur, au lieu de fonctionner avec des droits permanents propres. L’ABAC applique ensuite des règles supplémentaires selon la classification, la sensibilité et le contexte des données demandées, de sorte qu’un fichier accessible à une session IA d’un utilisateur pourra être refusé à un autre, même si les deux posent la même question. Les contenus jugés trop sensibles par la politique ne sont jamais transmis au modèle. Chaque accès à un fichier, chaque opération sur un dossier, chaque extraction de données est consignée dans une traçabilité unifiée. Les équipes conformité et sécurité bénéficient ainsi de la même visibilité sur les activités IA que sur celles de la messagerie et du transfert de fichiers.

Sous le serveur Secure MCP, les données restent dans l’environnement d’échange sécurisé de Kiteworks, protégées par un double chiffrement, des contrôles de souveraineté et une réplication haute disponibilité. Le client IA n’obtient jamais de copie permanente du contenu de l’entreprise. Il reçoit uniquement les données auxquelles une requête authentifiée et validée par la politique donne droit, au moment où elle en a besoin, et rien de plus.

Une sécurité de niveau entreprise intégrée au protocole

Un modèle de gouvernance n’est fiable que si le transport et la cryptographie sous-jacents le sont aussi. Kiteworks a conçu le serveur Secure MCP selon les exigences de sécurité des entreprises, et non selon les paramètres par défaut de l’open source MCP. Les jetons d’accès sont stockés dans le keystore chiffré du système d’exploitation, et non dans des variables d’environnement, ce qui élimine une source fréquente de fuite d’identifiants relevée dans les recherches sur la sécurité MCP. L’authentification repose sur le renforcement OAuth 2.1 : enregistrement dynamique des clients, flux d’autorisation avec PKCE, jetons d’accès et de rafraîchissement JWT, et rotation automatique des jetons. Un jeton volé a une durée de vie très courte et ne peut pas être réutilisé indéfiniment.

La cryptographie du serveur répond aux exigences FIPS 140-3, avec AES-256-GCM, RSA avec SHA-256 et TLS 1.3 utilisant des courbes validées par le NIST. Kiteworks a également intégré la confidentialité persistante post-quantique grâce à un échange de clés hybride X25519 et ML-KEM-768 TLS sous FIPS 203, protégeant les sessions actuelles contre le risque qu’un adversaire doté de capacités quantiques puisse un jour déchiffrer le trafic capturé aujourd’hui. Une limitation de débit configurable s’applique globalement, par utilisateur et par session, pour contrer la consommation illimitée de ressources que des chercheurs comme l’équipe Agents of Chaos ont observée chez les agents non gouvernés. Les chemins d’accès aux fichiers sont normalisés et validés pour prévenir les traversées de répertoires, les identifiants et les charges transférées ne sont jamais exposés au LLM lui-même, et la validation stricte des certificats TLS et des noms d’hôte protège contre les interceptions de type « man-in-the-middle ».

Aucune de ces mesures ne crée de friction pour l’utilisateur final. Depuis Claude, l’expérience reste une conversation en langage naturel. En coulisses, chacun de ces contrôles s’applique à chaque requête.

Du prompt à l’action gouvernée : comment ça fonctionne dans Claude

Pour un collaborateur, le travail dopé à l’IA s’effectue en langage courant, dans un client déjà utilisé, sans avoir à se soucier de la gouvernance sous-jacente. Un utilisateur peut saisir « crée un dossier T1 sous le dossier Prévisions », « téléverse ce tableur ici », « que contient le dossier Analyse ? » ou « télécharge ces documents », et le serveur Secure MCP traduit chacune de ces demandes en langage naturel en une action contrôlée par la politique et auditée dans l’environnement Kiteworks.

Ce pipeline gouverné s’étend aussi à la création de contenu, pas seulement à la récupération. Avec le serveur Secure MCP connecté, un utilisateur peut demander à Claude de créer un formulaire web sécurisé à partir d’un PDF, d’une image ou d’une description textuelle. Claude génère et prévisualise le formulaire au format JSON structuré, puis le dépose directement dans un dossier gouverné Kiteworks. Le nouveau formulaire hérite automatiquement des contrôles RBAC et ABAC de la plateforme, du double chiffrement et du journal d’audit unifié, transformant ce qui était un processus manuel et multi-étapes en un workflow accéléré par l’IA, conforme dès la création et non après coup.

Pourquoi la présence sur le Connector Marketplace d’Anthropic est importante

Le référencement du serveur Secure MCP sur le Connector Marketplace d’Anthropic change la façon dont les clients Kiteworks passent de « nous voulons un accès IA gouverné à nos données » à sa mise en œuvre effective. Chaque client Kiteworks dispose de sa propre instance cloud privée, chaque organisation déploie donc son propre serveur Kiteworks MCP privé, sans connexion à un point de terminaison mutualisé. La configuration s’effectue en deux étapes : un administrateur suit le guide d’installation et d’activation de Kiteworks MCP pour l’organisation, puis chaque utilisateur final ouvre le Connector Marketplace dans Claude Desktop et se connecte directement à l’instance Kiteworks de son organisation, sans développement spécifique ni attente sur le backlog des développeurs. Les organisations utilisant un client autre que Claude Desktop peuvent suivre le même guide pour déployer un serveur local pour un développeur ou un serveur HTTP pour l’ensemble de l’organisation.

Un référencement sur marketplace est aussi une décision de diffusion, pas seulement technique. Cela met une option de connexion gouvernée à disposition de chaque utilisateur Claude Desktop dans l’organisation cliente Kiteworks, au moment même où il décide comment connecter Claude à ses données, et non après que l’équipe sécurité ait découvert une intégration non gouvernée déjà en production. Quand on sait que nombre d’incidents documentés dans des études comme Agents of Chaos sont dus à des agents opérant sans identité vérifiée ni autorisations limitées, fermer cette fenêtre entre « lancement de l’IA » et « mise en place de la gouvernance IA » est aussi important que n’importe quel contrôle de sécurité individuel.

Une conformité qui accompagne la donnée

Les organisations réglementées ne peuvent pas traiter la gouvernance IA comme une piste de conformité distincte du reste de leur activité. Le serveur Secure MCP hérite des mêmes certifications que le reste de la plateforme Kiteworks : Kiteworks est certifié FedRAMP et a été évalué selon IRAP au niveau PROTECTED. Pour les responsables sécurité, conformité et IA des secteurs réglementés, cela signifie que les workflows IA construits sur Claude et le serveur Secure MCP fonctionnent dans la même frontière d’accréditation que la messagerie, le partage et le transfert de fichiers, sans introduire un nouveau système à évaluer, justifier et auditer séparément.

Premiers pas avec le serveur Kiteworks Secure MCP

Les organisations qui utilisent déjà Kiteworks peuvent activer le serveur Secure MCP via le guide d’installation et d’activation Kiteworks MCP, puis permettre aux utilisateurs finaux de se connecter via le Connector Marketplace d’Anthropic dans Claude Desktop. Les organisations qui évaluent la gouvernance des données IA de façon plus large peuvent s’appuyer sur ce lancement comme point de départ concret : au lieu de débattre de la politique IA de façon abstraite, les équipes sécurité et conformité voient précisément comment l’accès d’un client IA à des données spécifiques est autorisé, journalisé et limité en production.

Pour en savoir plus sur la gouvernance de l’accès des agents IA aux données sensibles de l’entreprise, réservez votre démo sans attendre !

Ressources complémentaires

• Article de blog
  Stratégies Zero Trust pour une protection abordable de la vie privée face à l’IA
• Article de blog
  Comment 77 % des organisations échouent à sécuriser les données IA
• eBook
  L’écart de gouvernance IA : pourquoi 91 % des petites entreprises jouent à la roulette russe avec la sécurité des données en 2025
• Article de blog
  Il n’existe pas de « –dangerously-skip-permissions » pour vos données
• Article de blog
  Les régulateurs ne se contentent plus de demander si vous avez une politique IA. Ils veulent des preuves de son efficacité.