Configurer les Dust Spaces et les autorisations basées sur les rôles : comment les administrateurs informatiques préviennent les fuites de données interdépartementales dans les assistants IA

Lors du déploiement à l'échelle d'assistants d'intelligence artificielle générative (AI Agents / Assistants), les administrateurs informatiques et les responsables de la sécurité et de la conformité font face à un dilemme majeur : les collaborateurs gagnent une productivité considérable en interrogeant leurs bases de connaissances internes en langage naturel, mais les architectures conventionnelles de Génération Augmentée par Récupération (RAG) introduisent un risque critique de fuite de données entre départements (Cross-Department Data Leakage). Si un collaborateur du marketing demande à un assistant d'entreprise généraliste : « Quels ont été les ajustements de rémunération de la direction approuvés le mois dernier ? » ou « Résume la stratégie contentieuse confidentielle relative au litige avec notre fournisseur », un pipeline RAG classique interrogeant une base vectorielle partagée récupérera et synthétisera sans hésitation ces documents hautement sensibles.

S'en remettre uniquement à des garde-fous au niveau du prompt (Prompt Guardrails, comme stipuler dans les instructions « ne réponds pas aux questions sur les salaires ») s'avère inopérant face aux injections de commandes, aux formulations détournées ou aux reformulations sémantiques. L'isolation des données d'entreprise doit être structurelle et déterministe afin de garantir que des documents non autorisés ne puissent jamais pénétrer dans la fenêtre de contexte (Context Window) du grand modèle de langage (LLM).

Dust répond à cet impératif grâce à un Modèle d'Autorisations à Double Couche (Dual-Layer Permission Model), articulé autour des Spaces (conteneurs de données étanches), du Contrôle d'Accès Basé sur les Rôles (RBAC), de la synchronisation d'annuaire via SCIM et Identity Provider (IdP) et du découpage strict au niveau des connecteurs. Ce guide explique pas à pas aux administrateurs informatiques comment configurer Dust Spaces et structurer leur gouvernance pour déployer des assistants IA sûrs et cloisonnés par département.

1. Architecture fondamentale : le modèle d'autorisations à double couche de Dust

Pour interdire toute fuite interdépartementale, l'équipe informatique doit dissocier l'accès des assistants aux données de l'accès des utilisateurs aux assistants. Les applications SaaS traditionnelles s'appuient sur un contrôle d'accès unidimensionnel : l'utilisateur X a-t-il le droit d'ouvrir le document Y ? À l'ère de l'IA générative, des assistants autonomes synthétisent et croisent de multiples données au nom de l'utilisateur, rendant obsolètes les contrôles de surface.

Dust structure la sécurité autour de deux couches complémentaires :

[ Systèmes Sources (Drive, SharePoint, Slack, Notion) ]
                         │
                         ▼ (Périmètre Admin & Compte de Service Dédié)
                 [ Connexions Dust ]
                         │
                         ▼ (Sous-ensembles de Données Assignés)
          ┌──────────────┴──────────────┐
          ▼                             ▼
   [ Open Spaces (Publics) ]     [ Restricted Spaces (Restreints) ]
   (ex. Company Data)            (ex. Finance, Juridique, RH)
          │                             │
          ▼                             ▼
   [ Assistants Généraux ]       [ Assistants Départementaux ]
          │                             │
          ▼                             ▼
   (Tous les Membres du Workspace)(Uniquement Membres du Space Dédié)
          ▲                             ▲
          └──────────────┬──────────────┘
                         │
              [ Utilisateurs et Groupes ]
            (Synchronisés via SCIM / IdP)

Couche 1 : Accès de l'assistant aux données (Confinement Déterministe)

Lorsqu'un assistant est conçu dans Dust, ses fonctions de recherche documentaire et ses outils d'exécution sont strictement limités aux Spaces qui lui sont attribués. Un assistant relié uniquement à l'espace Support Technique et à l'espace Company Data ne dispose d'aucune interface ni d'aucun index vectoriel lui permettant d'interroger l'espace restreint Finance ou l'espace Juridique. Cette barrière infranchissable est appliquée au niveau de la base de données avant même que la requête ne soit transmise au LLM.

Couche 2 : Accès de l'utilisateur à l'assistant (Visibilité Sécurisée par Défaut)

Dust applique un principe fondamental : les espaces mobilisés par un assistant déterminent qui peut voir et solliciter cet assistant. Par défaut, un collaborateur ne peut rechercher, afficher et invoquer un assistant que s'il est membre autorisé de chacun des espaces rattachés aux outils et bases de données de cet assistant.

Si un assistant interroge l'espace restreint de la Direction Financière, Dust le masque automatiquement de l'interface de tout utilisateur non membre de cet espace. Cette règle élimine les attaques par rebond (Proxy Attacks) : aucun utilisateur non autorisé ne peut utiliser un assistant à privilèges élevés comme intermédiaire pour extraire des documents protégés.

2. Stratégie des Spaces : Ségrégation des domaines ouverts et restreints

Dans Dust, l'intégralité des données, documents et intégrations est encapsulée dans des Spaces. Concevoir une topologie claire de ces espaces constitue le premier rempart contre les fuites d'informations.

Comparatif : Open Spaces vs. Restricted Spaces

Le rôle de l'espace par défaut « Company Data »

Chaque workspace Dust dispose d'un espace ouvert par défaut intitulé Company Data :

• Cet espace est accessible à tous les collaborateurs et ne peut être ni supprimé, ni renommé, ni restreint.
• Les documents qui y sont intégrés sont indexés par les assistants génériques du workspace (comme @dust).
• Règle absolue pour l'administrateur : Ne reliez jamais de feuilles de calcul salariales, de canaux Slack de direction ou de dossiers de contentieux à Company Data. Considérez cet espace comme le panneau d'affichage public de l'entreprise.

Quotas d'espaces selon l'offre

• Offre Business : Permet de créer jusqu'à 5 espaces. Convient aux structures légères nécessitant une séparation élémentaire (Company Data, Direction, Ingénierie, Ventes, Opérations).
• Offre Enterprise : Permet de créer jusqu'à 100 espaces. Conçue pour les grandes organisations et structures matricielles nécessitant un cloisonnement strict par département, filiale ou projet stratégique (ex. audit interne, M&A, contentieux réglementaires).

3. Déploiement en 6 étapes pour les administrateurs informatiques

Afin de garantir une étanchéité parfaite entre les équipes, les administrateurs doivent respecter le protocole de configuration suivant :

Étape 1 : Provisionnement d'annuaire automatisé via SCIM 2.0

Gérer les accès manuellement engendre inévitablement des dérives de privilèges lors des mutations ou des départs. Pour les offres Enterprise, l'interconnexion avec le fournisseur d'identité (Okta, Microsoft Entra ID ou Google Workspace) via SCIM 2.0 est incontournable.

1. Dans Dust, rendez-vous sur Admin > Organization > Members > Groups > User provisioning > Set up Directory sync.
2. Choisissez votre IdP et finalisez la configuration de la synchronisation d'annuaire.
3. Configurez la synchronisation des groupes métiers (par exemple : dept-finance, dept-legal, dept-people, exec-board).
4. Lorsqu'un salarié change de service ou quitte l'entreprise, le statut se répercute instantanément dans Dust : s'il quitte le groupe Finance dans Entra ID, ses droits d'accès à l'espace restreint Finance ainsi qu'à tous les assistants associés sont révoqués immédiatement.

Étape 2 : Délimitation des connecteurs avec des comptes de service dédiés

Les connecteurs Dust (Google Drive, Microsoft SharePoint/OneDrive, Notion, Confluence, Slack) s'interfacent avec vos référentiels documentaires. Pour respecter le principe du moindre privilège :

1. Bannir les comptes administrateurs personnels : Ne connectez jamais un outil avec le compte nominatif d'un informaticien. En cas de départ, la synchronisation s'interrompt et ses brouillons personnels risquent d'être indexés.
2. Utiliser des comptes de service dédiés :
   • Google Drive : Créez un compte virtuel tel que dust-admin@votredomaine.fr et n'accordez-lui des droits de lecture et de téléchargement que sur les Drive Partagés (Shared Drives) destinés à l'IA.
   • Microsoft SharePoint / OneDrive : Créez une inscription d'application dans Entra ID dotée de l'autorisation d'application Sites.Selected, ou configurez un compte de service (dust-service@votredomaine.fr) et limitez strictement les collections de sites autorisées via PowerShell (Grant-PnPAzureADAppSitePermission) ou l'API Microsoft Graph.
   • Slack : N'invitez le robot Dust que dans les canaux publics ou d'archives ciblés, en évitant les canaux privés de direction.
3. Sélectionner précisément les arborescences : Dans la modale de synchronisation Dust, parcourez l'arborescence et cochez uniquement les sous-dossiers pertinents au lieu de synchroniser la racine complète d'un espace documentaire.

Étape 3 : Création des Restricted Spaces et affectation des groupes

Une fois les données synchronisées avec Dust, elles restent dans un sas technique jusqu'à leur affectation explicite à un Space par un administrateur.

1. Rendez-vous dans l'onglet Spaces de Dust et cliquez sur New.
2. Indiquez le nom de l'espace (ex. : Finance & Accounting).
3. Choisissez l'option Restricted.
4. Dans la gestion des membres, sélectionnez Provisioned group access et choisissez le groupe synchronisé depuis votre IdP (ex. : dept-finance).
5. Ouvrez le nouvel espace, allez dans Connected Data, puis cliquez sur Add data from connections.
6. Cochez exclusivement les dossiers Drive ou les bibliothèques SharePoint réservés à ce département.
7. Validez en cliquant sur Save. Les données sensibles sont à présent confinées dans ce conteneur restreint.

Console d'administration Dust : Création d'un Espace Restreint
┌─────────────────────────────────────────────────────────────┐
│ Créer un nouvel espace (Create New Space)                   │
│ Nom : [ Finance & Accounting                              ] │
│ Type d'accès : ( ) Open (Public)   (•) Restricted (Restreint│
│ Attribution des membres :                                   │
│   [ Provisioned group access                              ▼]│
│   Groupes : [ dept-finance x ] [ exec-cfo x ]               │
│                                                             │
│ Données connectées (Connected Data) :                       │
│   [x] Google Drive: /Shared Drives/Finance/FY26_Budgets/    │
│   [x] SharePoint: /sites/FinanceOps/Financial_Statements/   │
│   [ ] Google Drive: /Shared Drives/Company_Wide/ (Exclu)    │
│                                                             │
│ [ Annuler ]                                 [ Créer l'espace]│
└─────────────────────────────────────────────────────────────┘

Étape 4 : Gestion des rôles et contrôle de création des assistants (RBAC)

Par défaut, un nouveau workspace Dust autorise l'ensemble des membres à créer et publier des agents. En milieu professionnel, ce périmètre doit être encadré.

Accédez à Admin > Governance pour affiner la matrice d'autorisations :

1. Create agents et Publish agents : Modifiez l'attribution de Everyone vers un groupe certifié (tel que des créateurs formés AI Builders) ou Admin only, afin d'éviter la prolifération d'assistants non vérifiés.
2. Create skills et Manage skill availability : Conservez ce réglage sur Admin only afin d'empêcher l'intégration non contrôlée d'API tierces.
3. Mappage des rôles : Dans Admin > Members > Roles, associez les rôles aux groupes d'annuaire. Réservez le rôle Admin à l'équipe informatique centrale. Les responsables de département peuvent être nommés Managers ou Group Managers pour suivre l'utilisation et administrer les membres locaux sans pouvoir modifier la sécurité de l'infrastructure.
4. Délégation ciblée des fonctions de sécurité : L'autorisation Access security features (accès aux journaux d'audit et aux réglages réseau) n'est pas comprise dans le rôle Manager et doit faire l'objet d'une délégation explicite par un administrateur.

Étape 5 : Création de l'assistant métier et règle d'intersection

Lors du paramétrage d'un assistant dans l'Agent Builder :

1. Rédigez des Instructions précises quant au périmètre d'action et aux règles de confidentialité.
2. Dans la section Knowledge / Tools, ajoutez l'outil Search data sources :
   • Cochez uniquement l'espace restreint concerné (ex. : Finance & Accounting).
   • N'ajoutez pas Company Data, sauf si l'assistant a impérativement besoin des politiques générales de l'entreprise.
3. Comprendre la règle d'intersection multi-espaces (Condition ET) :
   • Si un assistant fait appel à des connaissances issues de l'Espace A (Finance) et de l'Espace B (Direction), un utilisateur doit obligatoirement être membre de l'Espace A ET de l'Espace B pour pouvoir voir et exécuter cet agent.
   • S'il n'appartient qu'à l'Espace A, l'agent sera entièrement masqué pour lui.
   • Bonne pratique : Associez chaque assistant à un seul espace restreint pour éviter tout blocage involontaire d'utilisateurs légitimes.

Étape 6 : Choix du mode d'authentification des outils (Personal vs. Shared)

Pour les assistants amenés à interagir avec des applications externes (GitHub, Salesforce, Jira, HubSpot, serveurs MCP), choisissez le mode de connexion dans Knowledge > Tools :

• Identifiants Partagés (Shared Credentials) : Tous les utilisateurs appellent l'outil au travers d'un compte de service commun configuré par l'administrateur. Adapté aux référentiels publics en lecture seule.
• Identifiants Personnels (Personal Level Credentials) : L'administrateur réalise la liaison OAuth initiale, puis chaque utilisateur doit se connecter avec son propre compte lors de sa première utilisation.
  • Indispensable pour les applications sensibles : Dans des outils comme Salesforce ou des dépôts privés GitHub, ce mode assure que l'assistant n'accède qu'aux enregistrements autorisés par le profil individuel de l'utilisateur dans l'application cible, conjuguant ainsi l'isolation des Spaces Dust au contrôle d'accès natif de la source.

4. Audit, surveillance continue et cycle de départ des collaborateurs

La conformité exige une traçabilité rigoureuse de chaque interaction réalisée au sein de la plateforme.

┌──────────────────────────────────────────────────────────────┐
│                Flux d'Événements en Temps Réel               │
└──────────────────────────────┬───────────────────────────────┘
                               │
            ┌──────────────────┴──────────────────┐
            ▼                                     ▼
     [ Action Humaine Directe ]            [ Action Dérivée de l'IA ]
     actor: "user"                         actor: "user"
     action: "agent.executed"              metadata.actor_type: "agent"
     targets: ["agent-finance-01"]         metadata.initiating_user: "..."
            │                                     │
            └──────────────────┬──────────────────┘
                               ▼
                [ Moteur d'Audit Dust Enterprise ]
                               │
            ┌──────────────────┴──────────────────┐
            ▼                                     ▼
     [ Journal d'Audit Inaltérable ]       [ Streaming vers SIEM ]
     (Admin > Security > Audit Logs)       (Datadog, Splunk, S3, GCS)

Journal d'audit : distinction entre actions humaines et IA

Les journaux d'audit de Dust Enterprise (Admin > Organization > Security > Audit Logs) offrent un historique complet et inaltérable :

• Acteur (Actor) : Distingue les requêtes humaines (user), les appels d'API (api_key) et les tâches d'arrière-plan (system), avec horodatage, adresses IP et agents utilisateurs.
• Typologie d'actions : Enregistre précisément agent.executed, space.created, space.deleted, data_source.updated et tool.executed.
• Traçabilité des opérations de l'IA : Lorsqu'un assistant effectue une recherche ou active un outil, l'événement porte la mention metadata.actor_type: "agent", tout en conservant l'identité complète de l'utilisateur initiateur (initiating_user_id et initiating_user_email), permettant ainsi de remonter sans ambiguïté à l'origine d'une requête lors d'un audit.

Exportation en temps réel vers les plateformes SIEM

Les équipes de sécurité peuvent diffuser les journaux d'audit vers Datadog, Splunk, AWS S3, Google Cloud Storage (GCS) ou un point de terminaison HTTPS dédié. Si vos pares-feux restreignent les flux entrants, autorisez les plages d'adresses IP de transmission WorkOS documentées par Dust.

Gestion des départs de collaborateurs

Lorsqu'un collaborateur quitte l'entreprise :

1. La désactivation dans l'IdP entraîne la révocation immédiate du compte Dust par SCIM.
2. Tous ses droits sur les espaces restreints et assistants dédiés sont suspendus instantanément.
3. Ses déclencheurs et automatisations personnelles (Triggers) sont supprimés de manière définitive.
4. Bonne pratique de transition : Avant la radiation, examinez les tâches planifiées sous Programmatic Usage > Automations pour réaffecter les propriétaires nécessaires. Pour les assistants non publiés créés par l'employé sortant, un administrateur peut ouvrir l'Agent Builder et cliquer sur Become an editor as an admin afin d'en reprendre la gestion sans perdre les configurations acquises.

5. Matrice d'architecture et liste de contrôle pour l'administrateur

Matrice des Espaces et des Niveaux d'Accès

Liste de contrôle de sécurité pré-déploiement

• Synchronisation SCIM 2.0 active : Les groupes départementaux d'Okta ou d'Entra ID sont synchronisés sans erreur dans Dust.
• Espace Company Data vérifié : Aucun fichier salarial, document de contentieux ou résultat prévisionnel n'est présent dans l'espace public.
• Comptes de service dédiés en place : Les connexions Drive et SharePoint utilisent des comptes techniques restreints aux seuls dossiers nécessaires.
• Espaces Restreints isolés : Les espaces dédiés aux départements sensibles sont créés avec l'option Provisioned group access.
• Données connectées ciblées : Les sous-dossiers confidentiels sont assignés uniquement au sein de leur espace restreint respectif.
• Droits de publication verrouillés : Dans Admin > Governance, la création et la publication d'assistants sont réservées aux profils habilités.
• Identifiants personnels configurés : Les outils connectés à des applications à droits spécifiques (Salesforce, GitHub) fonctionnent en mode Personal Credentials.
• Connexion SIEM opérationnelle : L'export des journaux vers Splunk ou Datadog est actif et validé par un test d'alerte.

En articulant le confinement structurel de Dust Spaces avec la synchronisation d'annuaire et la gestion rigoureuse des identifiants d'outils, les administrateurs informatiques garantissent une sécurité sans faille, éliminant tout risque de fuite de données interdépartementale tout en démocratisant la puissance de l'IA générative.

Références

• Spaces management
• Workspace Governance: Roles, Groups & Permissions
• Access Controls and Permissions
• Users and groups provisioning
• Personal vs Shared Credentials for Tools & MCP Servers
• Agents management
• Audit Logs
• Google Drive
• Microsoft
• Dust Security: Enterprise-Grade Data Protection