Kiteworks Agent Marketplace offre à votre assistant IA un accès gouverné aux données réglementées
De nombreuses organisations réglementées ont déjà déployé un assistant IA. Le véritable défi consiste à lui donner accès aux données stratégiques : contrats, dossiers, factures, rapports de direction et documents techniques. Le Kiteworks Agent Marketplace comble ce fossé sans créer de seconde copie non maîtrisée des données.
Les équipes sécurité et gouvernance se retrouvent souvent face à deux mauvaises options. Soit elles bloquent l’assistant sur les référentiels sensibles, et l’investissement ne tient pas ses promesses. Soit elles ferment les yeux pendant que les utilisateurs téléchargent, copient-collent ou prennent des captures d’écran, ce qui fait sortir les données réglementées de tout contrôle et de toute traçabilité mis en place par l’organisation.
Cet article explique pourquoi le blocage est contre-productif, comment les agents gouvernés fonctionnent dans Kiteworks en tant qu’utilisateur demandeur, et comment démarrer avec un dossier à faible risque plutôt qu’un projet à l’échelle de la plateforme.
Résumé Exécutif
Un assistant IA qui n’accède pas aux données sensibles pousse à des contournements, synonymes de mouvements de données non tracés. Le Kiteworks Agent Marketplace propose un catalogue public de plus de 70 agents gouvernés qui s’exécutent sur Kiteworks MCP, permettant à l’assistant d’accéder aux données via les mêmes autorisations, règles et journaux d’audit que tout autre échange de données. Pour les responsables sécurité, conformité et IT, cela signifie une IA utile sur les données sensibles, une surface d’attaque réduite par rapport aux exports improvisés, et une traçabilité qui couvre désormais le canal de l’agent IA, en plus de l’e-mail et du partage de fichiers.
Résumé des points clés
- Bloquer l’assistant déplace le risque IA au lieu de le réduire. Si les outils autorisés n’accèdent pas aux données sensibles, les utilisateurs déplacent les données vers l’outil, sans aucune traçabilité.
- Les agents gouvernés agissent en tant qu’utilisateur demandeur. Un agent hérite des rôles et autorisations de l’utilisateur, il ne peut donc rien voir ou faire de plus que la personne qui l’utilise.
- La politique est évaluée à chaque requête. Les règles basées sur les attributs prennent en compte la classification, les attributs utilisateur et le contexte en temps réel, ce qui maintient la décision d’accès au niveau de la plateforme, pas de l’assistant.
- Les jetons de sécurité restent hors du contexte de l’assistant. En mode local, les données des fichiers transférés restent également hors de portée, sauf si l’utilisateur lit volontairement un fichier, ce qui répond directement à la problématique du prompt-injection.
- Démarrez avec un dossier à faible risque et un pilote en lecture seule. L’activation du connecteur est une action administrative, ce qui permet de valider le modèle de contrôle avant d’élargir l’accès.
Pourquoi bloquer l’assistant sur les données réglementées est contre-productif
Le blocage semble être la solution de sécurité évidente. Ce n’est pas le cas, car la demande ne disparaît pas. Les utilisateurs ont toujours besoin de résumer un contrat, de trouver une clause ou de comparer deux versions, et l’assistant reste le moyen le plus rapide. Si la voie officielle est fermée, ils en ouvrent une autre.
Ce que font les utilisateurs à la place
Ils téléchargent le fichier, collent le texte dans une invite ou prennent une capture d’écran. Chacune de ces actions reste un échange de données, mais sans contrôle d’identité, autorisations ni traçabilité. L’équipe sécurité ne peut pas examiner ce qu’elle n’a jamais vu, et l’auditeur ne peut pas contrôler un événement qui n’a laissé aucune trace.
Pourquoi une politique ne suffit pas
Une politique d’usage acceptable dit aux utilisateurs ce qu’ils doivent faire. Elle ne leur fournit pas un moyen gouverné de le faire. L’organisation doit proposer une voie où l’assistant accède aux données sensibles sous les mêmes contrôles que tous les autres canaux, afin que dire oui à l’IA ne signifie pas renoncer à la supervision.
Comment le Kiteworks Agent Marketplace intègre les agents gouvernés à votre assistant
Le Kiteworks Agent Marketplace est un catalogue public d’agents gouvernés pour votre assistant IA. Chaque agent fonctionne sur Kiteworks MCP, ce qui signifie que le traitement s’effectue dans Kiteworks, et non sur une copie externe de vos données. Claude est déjà pris en charge sur l’application web, Desktop et Claude Code. Le catalogue est consultable avant tout contact avec un fournisseur, et chaque agent annonce d’emblée son périmètre fonctionnel.
Les agents agissent en tant qu’utilisateur demandeur
Un agent ne dispose pas d’une identité privilégiée propre. Les opérations IA héritent des rôles et autorisations de l’utilisateur authentifié, et les politiques basées sur les attributs évaluent la classification des fichiers, les labels de sensibilité, les attributs utilisateur et le contexte à chaque requête. La surface d’accès ne s’élargit pas, et il n’y a pas de nouvelle identité privilégiée à gérer.
Ce qui reste hors du contexte de l’assistant
Les jetons de sécurité ne sont jamais accessibles dans le contexte de l’assistant. En mode local, les fichiers transitent sur un canal de données séparé, leurs données restent donc hors de portée sauf si l’utilisateur lit explicitement un petit fichier texte. C’est le connecteur qui l’impose, pas la bonne volonté de l’assistant. Cela compte pour les revues de prompt-injection, où la question est de savoir ce qu’un assistant manipulé pourrait atteindre.
Démarrer avec un dossier à faible risque
L’activation du marketplace est un paramètre administratif, pas une migration. Les administrateurs activent MCP dans l’interface administrateur de Kiteworks, qui utilise une application OAuth intégrée gérée à cet endroit. Ensuite, il suffit d’ajouter le connecteur une fois, pour l’ensemble du marketplace ou pour un agent spécifique, et les fonctions intégrées ne nécessitent aucune installation supplémentaire.
Ce que doit prouver un premier pilote
Choisissez un dossier important mais non critique, et commencez par des tâches en lecture seule. Vérifiez trois points : l’agent n’a vu que ce que l’utilisateur pouvait voir, chaque appel figure dans le journal d’audit avec la bonne attribution utilisateur, et votre politique a bien bloqué ce qu’elle devait bloquer. Si ces trois critères sont remplis, élargissez le périmètre sur la base de preuves, pas d’optimisme.
Gouverner le canal des agents IA sur le Data Control Plane de Kiteworks
Les outils de posture indiquent où résident les données sensibles, et l’IAM décide qui peut se connecter. Le DLP inspecte ce qui sort. Aucun de ces outils ne gouverne l’instant où un agent IA agit sur des données réglementées pour le compte d’un utilisateur. C’est le rôle du Data Control Plane de Kiteworks. L’Agent Marketplace l’étend à l’assistant, de sorte que les appels d’agent suivent la même identité, les mêmes autorisations et règles data-aware que l’e-mail, le partage de fichiers ou les API, et sont consignés dans un journal d’audit infalsifiable pouvant alimenter vos outils SIEM.
Il complète vos investissements existants en DSPM, IAM et DLP, sans les remplacer. Pour identifier les agents adaptés à votre premier pilote, consultez le catalogue, ou planifiez une démo personnalisée et testez le workflow que votre assistant ne peut pas encore atteindre.
Foire aux questions
Le blocage semble rassurant mais ne fonctionne pas, car la demande subsiste ; les utilisateurs téléchargent alors les fichiers, copient le texte ou prennent des captures d’écran, ce qui fait sortir les données de tout contrôle d’identité, d’autorisations et de traçabilité, sans journal d’audit pour les équipes sécurité ou les auditeurs.
Les agents s’exécutent sur Kiteworks MCP, à l’intérieur de la plateforme, et non sur des copies de données externes. Ils héritent des rôles et autorisations de l’utilisateur demandeur, avec des politiques basées sur les attributs qui évaluent la classification, la sensibilité, les attributs utilisateur et le contexte à chaque requête ; les jetons de sécurité restent hors du contexte de l’assistant.
Sélectionnez un dossier à faible risque et effectuez des tâches en lecture seule pour vérifier que l’agent n’accède qu’à ce que l’utilisateur peut voir, que chaque appel figure dans le journal d’audit avec la bonne attribution utilisateur, et que les règles bloquent les actions non autorisées avant d’élargir le périmètre.
Il étend les contrôles existants pour que les appels d’agent suivent la même identité, les mêmes autorisations et règles data-aware que l’e-mail ou le partage de fichiers, et soient consignés dans un journal d’audit infalsifiable alimentant les outils SIEM, tout en complétant les investissements DSPM, IAM et DLP.