Déploiement Sécurisé de Dust : Guide Complet RSSI 2026

Déployer une plateforme d'agents IA en entreprise sans maîtriser ses implications de sécurité revient à ouvrir les portes du système d'information à un acteur disposant de larges privilèges d'accès et d'action. Dust, plateforme d'agents IA d'origine française certifiée SOC 2 Type II et forte de plus de 3 000 organisations clientes après sa levée de fonds Series B de 40 millions de dollars en mai 2026, illustre parfaitement ce paradoxe fondamental de l'IA agentique : sa valeur — l'accès profond aux connaissances internes et la capacité d'agir sur les systèmes — est aussi la source de sa dangerosité. Ce guide opérationnel, destiné aux RSSI, architectes sécurité, DSI et AI Champions, cartographie en détail la surface d'attaque d'un déploiement Dust, analyse le modèle de sécurité natif de la plateforme et son partage des responsabilités, recense les vulnérabilités selon les référentiels OWASP LLM Top 10 et OWASP MCP Top 10, documente les trois vulnérabilités publiquement divulguées via le programme HackerOne, et propose une démarche structurée en huit phases, des scénarios de risque détaillés (S1 à S12), une checklist priorisée avec indicateurs de maturité et un modèle en trois niveaux pour monter en maturité par paliers conscients. Trois risques dominent : l'injection de prompt indirecte via des sources empoisonnées, l'autonomie excessive d'agents surprivilégiés, et les fuites par mauvaise configuration — auxquels s'ajoute en 2026 la sécurité du protocole MCP comme nouvelle frontière critique à gouverner rigoureusement. La posture recommandée tient en cinq principes : SSO avec offboarding automatisé via SCIM, cloisonnement des données par Spaces restreints, moindre privilège sur les données, les outils et les comptes de service, validation humaine sur les actions sensibles avec préférence pour le mode lecture seule, et instrumentalisation de l'observabilité couplée à des tests adversariaux réguliers. La sécurité d'un déploiement Dust est avant tout une affaire de configuration et de gouvernance, pas de correctifs à attendre — et elle se construit par paliers de maturité mesurables.

1. Pourquoi la sécurité est le sujet central des plateformes d'agents IA

L'IA générative en entreprise a traversé trois vagues distinctes. D'abord les chatbots génériques, déconnectés des données internes, utiles pour la rédaction mais sans accès au savoir organisationnel. Ensuite les assistants connectés à une base documentaire (RAG), capables de répondre à partir de la documentation interne. Enfin la vague actuelle, celle de l'IA agentique : des agents qui n'expliquent plus, ils agissent — ils lisent et écrivent dans vos systèmes, déclenchent des workflows, mettent à jour un CRM, créent un ticket, exécutent une requête SQL, envoient un e-mail.

Dust se situe résolument sur cette troisième vague. La plateforme se présente comme un « système d'exploitation pour agents IA » et, depuis 2026, un système d'IA « multijoueur » où humains et agents partagent le même contexte opérationnel. La promesse de productivité est considérable — et la concentration de risques l'est tout autant.

La raison est directe et structurelle. Un agent Dust correctement déployé dispose, dans son périmètre, d'un accès en lecture et souvent en écriture au patrimoine informationnel de l'entreprise. Il agit avec des privilèges, manipule des données sensibles et décide sur la base d'entrées qui ne sont pas toujours dignes de confiance. Là où une faille classique compromet une application isolée, une faille sur une plateforme d'agents peut transformer un assistant utile en vecteur d'exfiltration ou d'action destructrice à l'échelle du SI. Comprendre l'architecture Zero Trust est ici un prérequis : chaque agent, chaque connecteur, chaque serveur MCP doit être traité comme non fiable jusqu'à preuve du contraire.

Le paradoxe fondamental : valeur et dangerosité ont exactement la même source. On ne sécurise pas Dust en le coupant de tout — ce serait le rendre inutile. La sécurité consiste à calibrer finement ce que chaque agent peut voir, ce qu'il peut faire, et sous quelle supervision humaine. Ce guide a un objectif opérationnel : permettre à une équipe sécurité de déployer Dust en production en maîtrisant les risques à chaque étape.

2. Présentation de Dust : architecture et briques fondamentales

2.1 Origine, maturité et positionnement

Dust est une plateforme d'IA d'origine française, fondée à Paris en 2022 par Stanislas Polu, ancien ingénieur de recherche d'OpenAI, et Gabriel Hubert, ancien Chief Product Officer d'Alan. Après une série A de 16 M$ menée par Sequoia en juin 2024, Dust a annoncé en mai 2026 une série B de 40 M$, menée par Abstract et Sequoia avec la participation de Snowflake Ventures et Datadog — portant le total levé à plus de 60 M$. L'éditeur revendique plus de 3 000 organisations clientes, plus de 300 000 agents déployés et environ 41 000 utilisateurs actifs mensuels (avril 2026). Ces chiffres traduisent une adoption forte et une assise financière sérieuse : un critère de confiance réel pour un fournisseur amené à toucher au cœur du SI.

2.2 Les briques fondamentales de l'architecture

Pour raisonner sécurité, il faut maîtriser les objets manipulés par la plateforme. Le workspace est l'environnement collaboratif de l'entreprise — périmètre de facturation, d'administration et de gouvernance. Les connections (connecteurs) sont des intégrations managées qui synchronisent automatiquement des données externes : Slack, Google Drive, Notion, Confluence, GitHub, Salesforce, Snowflake, HubSpot, Gmail, Zendesk et plus de 100 autres. Un administrateur contrôle de façon granulaire quelles données précises sont ingérées, jusqu'au dossier, au canal ou au dépôt. Les Spaces cloisonnent l'accès aux données : ouverts (accessibles à tous les membres) ou restreints (réservés à des utilisateurs désignés). C'est le pivot du cloisonnement. Les agents sont les assistants configurés : un rôle, des instructions, des sources rattachées via les Spaces, des outils, un modèle. Point de conception majeur : un agent hérite des exigences de permission de chaque Space référencé.

Le diagramme suivant illustre l'architecture complète et les quatre points de contrôle de sécurité :

2.3 Approche multi-modèle et surfaces d'usage

Dust est agnostique vis-à-vis des modèles : on choisit, par agent et par tâche, parmi OpenAI, Anthropic, Google Gemini, Mistral et d'autres. Conséquence sécurité directe : la donnée transite, selon la configuration, vers différents fournisseurs de cloud. Le choix du fournisseur, de la région d'inférence et des engagements de non-rétention devient un paramètre de gouvernance à documenter pour chaque modèle activé. Les agents sont accessibles par de multiples surfaces : interface web, extension de navigateur, intégrations Slack/Teams/WhatsApp, mise en copie d'e-mail (pratique, mais vecteur d'injection indirecte), API REST publique, webhooks, et serveurs MCP distants ou côté client. Chaque surface élargit simultanément la valeur d'usage et la surface d'attaque.

3. Comprendre la surface d'attaque : l'injection de prompt et ses conséquences

Idée contre-intuitive pour qui vient de l'AppSec classique : les vulnérabilités d'une plateforme LLM ne se réduisent pas à celles d'une application web. Un pentest web traditionnel ne détecte ni une injection de prompt, ni une fuite via embeddings, ni un excès d'autonomie. Le vocabulaire et les méthodes de test diffèrent fondamentalement.

La cause profonde est architecturale : les modèles traitent instructions et données dans le même canal, sans séparation nette. Un document récupéré, le contenu d'un ticket, le corps d'un e-mail, une page web visitée — tout arrive au modèle comme du texte brut. Si ce texte contient des instructions, le modèle peut les suivre. La frontière « donnée / instruction », fondamentale en informatique classique, est ici brouillée par construction. Aucune technique ne supprime totalement l'injection de prompt ; on ne fait que la réduire par défense en profondeur.

Trois couches superposées, chacune avec ses risques propres. La couche des données — tout ce que les connecteurs ingèrent et indexent — expose aux risques de sur-collecte, fuite transversale, empoisonnement et exposition de secrets indexés par mégarde. La couche des modèles — l'inférence et le routage vers les fournisseurs — risque la fuite, la rétention non maîtrisée, l'entraînement non consenti et la résidence non conforme. La couche des outils et des actions — tout ce que l'agent peut faire — est la plus dangereuse : elle transforme une faille de confidentialité en faille d'intégrité. Un agent qui lit est embêtant s'il fuite ; un agent qui écrit, supprime ou transfère est catastrophique s'il est détourné. C'est aussi la couche où vit le protocole MCP.

Le diagramme suivant montre le flux d'une injection de prompt indirecte et les deux points où elle peut être stoppée :

4. Le modèle de sécurité natif de Dust et le partage des responsabilités

4.1 Certifications et conformité

Dust est certifié SOC 2 Type II, se déclare conforme au RGPD avec résidence des données en Europe, et permet la conformité HIPAA. La société publie un Trust Center avec rapports disponibles sous NDA. SOC 2 Type II atteste que des contrôles existent et fonctionnent dans la durée — mais c'est une attestation d'organisation, pas une garantie d'absence de vulnérabilité. Pour un accompagnement ISO 27001, cette certification est un point d'appui solide mais ne remplace pas votre propre analyse de risques. Règle d'or : exigez le rapport SOC 2 complet (sous NDA via le Trust Center Dust), la liste des sous-traitants, les synthèses de pentest, la déclaration de gouvernance IA et le DPA. Vérifiez que les certifications sont actuelles, pas « en cours ».

4.2 Chiffrement, résidence et non-rétention

Données chiffrées au repos en AES-256 et en transit via TLS 1.3. Les clients entreprise peuvent héberger leurs données dans l'UE ou aux États-Unis (instance européenne : eu.dust.tt) — à choisir à l'initialisation. Dust affirme ne pas entraîner de modèles sur vos données et applique une politique de zéro rétention côté fournisseurs tiers. Nuance importante : la non-rétention varie par fournisseur et par modèle — ce qui est contractuellement garanti par les grands fournisseurs (OpenAI, Anthropic) ne l'est pas nécessairement pour un modèle tiers hébergé ailleurs. Vérifiez au cas par cas.

4.3 SSO, SCIM et permissions à double couche

Le plan Entreprise permet le SSO (SAML, OIDC) — compatible Okta, Microsoft Entra ID, JumpCloud — et le provisionnement SCIM 2.0 avec groupes synchronisés mappables sur les Spaces restreints. Le RBAC repose sur trois rôles : Member, Builder et Admin. Force structurante clé : le modèle de permissions à double couche sépare explicitement ce que l'agent peut atteindre (les données, via les Spaces) de qui peut l'utiliser (les utilisateurs, via les rôles et groupes SCIM). Un agent ne surface jamais de données hors de ses Spaces configurés, et un utilisateur ne peut l'invoquer que s'il a accès à tous ces Spaces. C'est un atout réel — à condition d'être configuré correctement.

4.4 Le partage des responsabilités

Point le plus souvent négligé : Dust fournit des contrôles, il ne les configure pas à votre place. La majorité des incidents sur ce type de plateforme viennent de la configuration client, pas de l'éditeur. Les recommandations ANSSI sur les systèmes d'IA agentique soulignent systématiquement ce point.

5. Vulnérabilités possibles : OWASP LLM Top 10 et OWASP MCP Top 10

Deux référentiels OWASP couvrent désormais ce domaine. L'OWASP Top 10 pour les applications LLM (édition 2025) couvre le modèle et l'application qui l'enveloppe. L'OWASP MCP Top 10 (bêta 2026) couvre le protocole par lequel l'agent appelle des outils externes. Ils sont complémentaires et les deux s'appliquent directement à Dust.

5.1 OWASP Top 10 LLM appliqué à Dust

LLM01 — Injection de prompt (risque n°1). Directe (l'utilisateur tape des instructions malveillantes) ou indirecte — plus pernicieuse — où le modèle lit un contenu non fiable contenant des instructions cachées. Comme un agent Dust ingère des tickets, e-mails, documents et peut être mis en copie d'e-mails, toute source externe devient un canal d'injection potentiel. Ni le RAG ni le fine-tuning ne neutralisent cette classe de vulnérabilité.

LLM02 — Divulgation d'informations sensibles. Secrets indexés par mégarde, données personnelles, recoupement de fragments confidentiels restitués dans des réponses d'agents.

LLM03 — Chaîne d'approvisionnement. Connecteurs et serveurs MCP tiers constituent un risque de supply chain similaire à celui des dépendances logicielles — voir §5.2.

LLM04 — Empoisonnement des données. Contenu malveillant injecté dans une source indexée (wiki interne, canal Slack, dépôt) qui oriente ensuite les réponses de tous les utilisateurs.

LLM05 — Mauvaise gestion des sorties. Une sortie d'agent insérée en aval (page, e-mail, commande) sans filtrage peut provoquer XSS, injection de commande ou actions non voulues dans les systèmes consommateurs.

LLM06 — Autonomie excessive. Trois racines : fonctionnalité excessive (trop d'outils activés), permissions excessives (compte de service surpuissant), autonomie sans supervision (actions à fort impact sans validation humaine). L'exemple canonique : un assistant e-mail accédant à toutes les boîtes via un compte privilégié — une seule injection indirecte peut déclencher l'exfiltration massive.

LLM07 — Fuite du prompt système. Les instructions d'un agent peuvent fuiter si un utilisateur les demande explicitement. N'y placez jamais de secret ou d'information confidentielle.

LLM08 — Faiblesses des vecteurs et embeddings. Le RAG est une nouvelle surface d'attaque : des contrôles d'accès insuffisants sur le magasin vectoriel peuvent exposer des données au-delà des frontières prévues par les Spaces.

LLM09 — Désinformation. Réponses assurées mais factuellement incorrectes ; en contexte métier, risque de mauvaise décision opérationnelle ou réglementaire.

LLM10 — Consommation non bornée. Boucles d'agents, requêtes massives, chaînes à 12 étapes : coûts d'inférence divergents et déni de service économique.

5.2 OWASP MCP Top 10 : le point chaud de 2026

Le protocole MCP est devenu le connecteur standard entre agents et systèmes d'entreprise, mais l'adoption a largement devancé la sécurité. Entre janvier et février 2026, des chercheurs ont déposé plus de 30 CVE visant serveurs, clients et outillage MCP ; environ 43 % étaient des injections shell. Parmi les exemples concrets : une RCE notée CVSS 9.6 dans le SDK MCP officiel en Go (CVE-2026-27896) et une SSRF CVSS 8.8 dans le serveur MCP d'Azure (CVE-2026-26118). Une analyse de Palo Alto Unit 42 a montré qu'avec cinq serveurs MCP connectés, un seul serveur compromis atteignait un taux de réussite d'attaque de 78,3 %.

MCP01 — Mauvaise gestion des tokens. Identifiants codés en dur, tokens à longue durée de vie, secrets dans les logs ou la mémoire du modèle. Parade : tokens courts et scopés, secret-scanning, jamais de secret dans le contexte de l'agent.

MCP02 — Permissions excessives. Les permissions s'élargissent silencieusement avec le temps (scope creep). Parade : moindre privilège, expiration automatique, revues d'accès trimestrielles.

MCP03 — Tool poisoning. Instructions malveillantes cachées dans les descriptions d'outils ou les valeurs de retour. Sous-techniques : rug pull (mise à jour malveillante d'un outil de confiance), schema poisoning, tool shadowing. Parade : épingler et hacher les descriptions d'outils à l'approbation, filtrer les motifs d'instruction dans les sorties.

MCP04 — Chaîne d'approvisionnement. Paquets compromis, serveurs « officiels » contrefaits, typosquatting — le premier paquet MCP malveillant a été repéré en septembre 2025.

MCP05 à MCP10 — Injection de commande (l'agent construit des commandes à partir d'entrées non fiables), subversion du flux d'intention, authentification insuffisante (problème du « confused deputy »), et sur-partage de contexte laissant fuiter des informations entre utilisateurs.

Règle d'or MCP : chaque serveur MCP connecté est une nouvelle frontière de confiance hors de votre code. Traitez tout serveur MCP comme non fiable jusqu'à preuve du contraire.

6. Bulletins, CVE et vulnérabilités connues de Dust

Mise au point honnête, car elle conditionne la crédibilité du guide. À ce jour, aucune CVE n'est attribuée à Dust, et il n'existe aucun bulletin CERT-FR ou CISA spécifique à la plateforme, ni fuite de données publiquement documentée la concernant. Absence de bulletin ne signifie pas absence de risque : cela reflète surtout le format SaaS (pas de versions à patcher côté client, donc pas de mécanique CVE classique). Dust opère un programme de divulgation de vulnérabilités sur HackerOne avec un code source partiellement public sur github.com/dust-tt.

Trois rapports publics et résolus, tous des failles applicatives classiques :

Ces trois vulnérabilités illustrent que le cloisonnement par Spaces dépend aussi de l'absence de bugs côté API — raison pour laquelle votre red teaming doit tester les deux surfaces. Le vrai risque dominant n'est pas un « exploit Dust » mais les propriétés inhérentes à toute plateforme agentique (injection, autonomie, MCP) — à gouverner par configuration, pas par correctifs à attendre.

7. Déployer Dust de manière sécurisée : démarche en huit phases

Phase 0 — Gouvernance et cadrage

Formalisez une politique d'usage de l'IA agentique : qui crée des agents, sur quelles données, avec quelles validations requises. Désignez un AI Champion et établissez un RACI sécurité/métier/IT. Réalisez une classification des données (publiques, internes, confidentielles, réglementées). Posez vos exigences non négociables (SOC 2, RGPD, HIPAA + BAA si applicable, résidence, audit) et confrontez-les au Trust Center avant contractualisation. La gouvernance cybersécurité doit intégrer les systèmes d'IA comme une catégorie spécifique avec son propre niveau de risque.

Phase 1 — Identité et accès

Activez le SSO, interdisez les comptes hors SSO, imposez le MFA côté IdP (pas côté Dust). Mettez en place le provisionnement SCIM — la création et la modification, mais surtout la révocation automatique. Appliquez le moindre privilège sur les rôles : majorité de Members, Builders justifiés, 2–3 Admins maximum. Mappez les Spaces restreints sur vos groupes IdP synchronisés en SCIM — c'est la combinaison qui donne sa puissance au modèle à double couche de Dust.

Phase 2 — Spaces et données

Adoptez le principe « minimiser l'ingestion » : ne connectez et n'indexez que le nécessaire, via la sélection granulaire jusqu'au dossier/canal/dépôt, jamais un Drive entier « au cas où ». Cartographiez les Spaces selon la classification : données confidentielles et réglementées en Spaces restreints alignés sur les groupes ; Spaces ouverts pour le réellement partageable. Avant production, effectuez une revue d'exposition (qui accède à quoi, quels agents exploitent quels Spaces) et une chasse aux secrets dans les sources avant indexation — un credential oublié dans un document Google Drive devient interrogeable par tous les agents qui utilisent ce Space une fois indexé.

Phase 3 — Connecteurs et serveurs MCP

Pour chaque connecteur : compte de service dédié au périmètre strict, scoping OAuth minimal, lecture seule par défaut. Pour les serveurs MCP, raisonnez en trois classes de confiance : Officiels (Dust ou l'éditeur du service lui-même) — à privilégier ; Communauté vérifiée (listés sur un registre officiel, audités, signés) — acceptables après revue ; Non audités / tiers — à proscrire en production sans revue approfondie. Mesures concrètes : épingler et hacher les descriptions d'outils à l'approbation, filtrer les motifs d'instruction dans les sorties, tenir une allowlist de serveurs, et pour les déploiements à l'échelle, envisager une passerelle MCP SOC 2-compliant qui centralise authentification, journalisation et inspection.

Phase 4 — Conception sécurisée des agents

Moindre privilège d'outillage : seulement les outils nécessaires au rôle de l'agent, pas plus. Instructions défensives : périmètre précis, interdits explicites, formats de sortie sourcés — sans jamais y placer de secret (LLM07). Validation humaine sur les actions à fort impact : l'agent propose, un humain approuve avant tout envoi d'e-mail externe, toute suppression, toute transaction, toute modification de masse. Attention à la fatigue de confirmation : réservez les gates au vraiment sensible et préférez un défaut déterministe — l'agent ne peut pas écrire — à une validation humaine qui finit par être cliquée mécaniquement. Traitez toute source externe comme hostile et séparez impérativement l'agent qui lit des sources non fiables de celui qui agit avec des privilèges.

Phases 5 à 8 — Modèles, observabilité, tests et incident

Choisissez la région conforme dès l'initialisation (EU sur eu.dust.tt). Vérifiez non-entraînement, non-rétention et région d'inférence pour chaque modèle activé — restreignez la liste des fournisseurs autorisés. Acheminez les journaux d'audit vers le SIEM (rétention 365 j côté Dust) ; surveillez créations/modifications d'agents, changements de rôles, ajouts de connecteurs/MCP, pics d'activité. Pour les tests, un pentest web classique ne suffit pas : prévoyez un red teaming spécifique LLM/MCP avec les outils garak, PyRIT, Giskard ou promptfoo, et mcp-scan pour les serveurs MCP. Testez l'API et l'interface. Préparez un runbook d'incident couvrant : révocation d'une clé d'API compromise, désactivation d'un agent détourné, coupure d'un connecteur, isolation d'un Space. Intégrez Dust à l'offboarding RH : révocation SCIM immédiate, reprise des agents et connecteurs du partant.

8. Scénarios de risque détaillés et contre-mesures (S1–S12)

S1 — Injection de prompt indirecte via une source empoisonnée. Un agent de support lit des tickets et peut répondre par e-mail. Un attaquant glisse dans un ticket des instructions ordonnant d'exfiltrer des données clients. L'agent, ne distinguant pas données et instructions, exécute. Impact : fuite de données, violation RGPD. Contre-mesures : sources externes traitées comme non fiables, séparation lecture/action, validation humaine avant tout envoi externe, restriction des destinataires à des domaines internes, DLP.

S2 — Agent surprivilégié, action destructive sur le CRM. Agent connecté à Salesforce en écriture via un compte de service à droits étendus. Une instruction manipulée conduit à modifier ou supprimer en masse des enregistrements. Impact : corruption de données critiques, interruption d'activité. Contre-mesures : moindre privilège du compte de service, lecture seule par défaut, écriture limitée aux champs indispensables, validation humaine sur les modifications de masse, sauvegardes côté CRM.

S3 — Space restreint mal configuré, fuite transversale. Des données RH censées être restreintes se retrouvent dans un Space ouvert ou rattachées à un groupe trop large. Un employé lambda obtient des informations salariales via un agent. Impact : violation de confidentialité grave. Contre-mesures : mapping rigoureux Spaces↔groupes SCIM, revue d'exposition systématique, test de cloisonnement en red teaming.

S4 — Clé d'API Dust fuitée. Une clé stockée en clair est poussée sur un dépôt public. Un attaquant obtient un accès programmatique au workspace contournant toute l'UI et ses contrôles visuels. Impact : accès étendu, exfiltration. Contre-mesures : secrets dans un coffre, secret-scanning des dépôts, rotation régulière et révocation immédiate, surveillance des appels API anormaux.

S5 — Serveur MCP tiers malveillant (tool poisoning, rug pull). Un admin branche un MCP tiers via bearer token. Le serveur observe les données transitant ou expose des outils piégés ; ou un outil de confiance est modifié après approbation. Impact : exfiltration, détournement des actions, perte de traçabilité. Contre-mesures : MCP officiels/validés uniquement, descriptions d'outils épinglées/hachées, Static OAuth, passerelle MCP, mcp-scan.

S6 — Sur-collecte et exposition de secrets via le RAG. Des Drives entiers sont indexés ; parmi les documents, des identifiants, contrats, données personnelles. Un agent les restitue pour des utilisateurs non habilités. Impact : LLM02, exposition de secrets, non-conformité. Contre-mesures : sélection granulaire, chasse aux secrets avant indexation, cartographie stricte des Spaces. Principe : moins on indexe, moins on expose.

S7 — Accès résiduel après départ. Le compte d'un Builder n'est pas désactivé ou ses connecteurs liés à des accès personnels restent actifs. Impact : accès persistant, fuite ou sabotage par un ancien employé. Contre-mesures : offboarding SCIM immédiat, comptes de service plutôt qu'accès personnels, reprise des objets du partant, revue des comptes orphelins.

S8 — Orchestration multi-agents et confiance transitive. Un agent « routeur » délègue à des agents spécialisés qui s'appellent en chaîne (jusqu'à 12 étapes). Une injection introduite en amont se propage, chaque agent faisant confiance à la sortie du précédent. Impact : action non autorisée en bout de chaîne, amplification. Contre-mesures : traiter la sortie d'un agent comme une entrée non fiable pour le suivant, concentrer les privilèges d'action sur peu d'agents bien gardés, validation humaine au point terminal, tracer toute la chaîne.

S9 — Isolation entre workspaces / multi-entités juridiques. Un groupe utilise plusieurs workspaces pour ses filiales ; une administration mutualisée crée une fuite inter-tenant. Impact : violation de confidentialité entre entités juridiques. Contre-mesures : séparer les workspaces par entité quand le cloisonnement est exigé, vérifier l'absence de partage croisé de Spaces/agents, tester explicitement l'isolation inter-workspace.

S10 — Contamination croisée par embeddings. Des documents de Spaces différents cohabitent dans le même index vectoriel ; des proximités sémantiques peuvent révéler l'existence ou des bribes de contenu d'un document restreint même sans y accéder directement. Impact : divulgation indirecte (LLM08). Contre-mesures : confirmer l'isolation des index par Space/tenant auprès de l'éditeur, limiter la granularité d'indexation des contenus très sensibles, tester par requêtes d'inférence.

S11 — Fuite par citations/sources. Un agent cite ses sources. Si un document restreint est récupéré, la citation peut révéler son existence, son titre ou un extrait à un utilisateur sans accès au Space. Impact : divulgation par métadonnée. Contre-mesures : vérifier que la citation hérite bien des permissions du Space, restreindre l'affichage des sources hors périmètre, revue d'exposition.

S12 — Saturation / consommation non bornée. Un agent en boucle ou enchaînant jusqu'à 12 agents consomme massivement des tokens. Impact : coûts d'inférence divergents, déni de service économique (LLM10). Contre-mesures : plafonds d'étapes et de budget, monitoring de coûts avec alertes, détection des boucles, quotas par agent/utilisateur.

9. Checklist de sécurité priorisée + KPIs

Légende : C Critique   H Haute   M Moyenne. Consultez aussi les checklists de sécurité du site pour les contrôles complémentaires.

Gouvernance et conformité

• CPolitique d'usage de l'IA agentique formalisée (RSSI + AI Champion)
• HAI Champion désigné, RACI établi (RSSI)
• CClassification des données réalisée (Data owners)
• HRapport SOC 2 Type II, sous-processeurs, DPA obtenus et revus (RSSI)
• HBAA confirmé si données de santé (Juridique)
• CRégion d'hébergement (UE/US) choisie et conforme (Sécurité)

Identité et accès

• CSSO activé, création hors SSO interdite (IAM)
• CMFA imposé côté IdP (IAM)
• CProvisionnement/déprovisionnement SCIM (IAM)
• HRôles au moindre privilège, Admins limités à 2–3 (IAM)
• HSpaces restreints mappés sur les groupes IdP (IAM + Data owners)
• COffboarding testé : révocation immédiate (IAM)

Données et Spaces

• CPrincipe « minimiser l'ingestion » appliqué (Data owners)
• HSélection granulaire configurée (Data owners)
• CDonnées sensibles isolées en Spaces restreints (Sécurité)
• HChasse aux secrets avant indexation (Sécurité)
• CRevue d'exposition avant production (Sécurité)
• MDurée de rétention des conversations configurée (Admin)

Connecteurs et serveurs MCP

• CComptes de service dédiés au périmètre minimal (IT)
• HScoping OAuth minimal, lecture seule par défaut (IT)
• CServeurs MCP classés (officiel / vérifié / proscrit), tiers non audités exclus (Sécurité)
• HDescriptions d'outils MCP épinglées/hachées, motifs d'instruction filtrés (Sécurité)
• HBearer tokens partagés évités ; Static OAuth ou gateway MCP privilégiés (IT)
• MRevue de sécurité pour tout nouveau serveur MCP (Sécurité)

Conception des agents

• CMoindre privilège d'outillage par agent (Builders)
• HInstructions défensives, aucun secret dans les prompts (Builders)
• CValidation humaine sur actions à fort impact (Builders + Métier)
• HLecture seule par défaut là où possible (Builders)
• HLecture de sources non fiables séparée des privilèges d'action (Builders)

Observabilité, formation et tests

• CJournaux d'audit acheminés vers le SIEM (SOC)
• HMonitoring usage/coûts + alertes sur seuils (SOC)
• HModule de formation utilisateurs + Builders déployé (RH + AI Champion)
• CRed teaming LLM/MCP réalisé (garak/PyRIT/Giskard/mcp-scan) (Red team)
• CCloisonnement des Spaces testé (API et UI) (Red team)
• CRunbook d'incident rédigé (révocation clé, coupure connecteur, isolation Space) (RSSI)
• MVeille sur les publications de sécurité éditeur (Sécurité)

KPIs de maturité sécurité

10. Modèle de maturité en trois niveaux

Inutile de tout déployer d'un coup. Chaque palier d'autonomie supplémentaire doit être un choix conscient, documenté et homologué — pas une dérive par accumulation de fonctionnalités. La menace post-quantique s'ajoute à l'horizon des déploiements de niveau 3, où les données confidentielles engagées dans les agents auront une durée de vie qui dépasse les garanties cryptographiques actuelles.

11. Ce qui change en 2026 et limites à connaître

Réglementation. L'application de l'EU AI Act s'intensifie en 2026 (échéances d'août 2026) avec un besoin d'inventaire des systèmes d'IA pour classer le risque. ISO 42001, DORA et SOC 2 touchent désormais le comportement des agents et le contrôle des identités. La menace post-quantique et les migrations cryptographiques doivent être intégrées dans les roadmaps des déploiements à horizon 2027–2028.

Standards d'agents et MCP. L'OWASP MCP Top 10 (bêta) et les recommandations MCP de la NSA (mai 2026) formalisent la sécurité du protocole. L'AIBOM (nomenclature des composants IA, y compris serveurs MCP) devient un artefact d'inventaire attendu dans les dossiers d'homologation. La NSA a publié en mai 2026 des recommandations de conception sécurisée spécifiques au protocole MCP.

Non-rétention : pas une garantie uniforme. La politique de zéro rétention varie par fournisseur et par modèle. Ce qui est contractuellement garanti par OpenAI ou Anthropic ne l'est pas nécessairement pour un modèle tiers hébergé dans une région non couverte. Vérifiez au cas par cas, documentez chaque modèle activé, et revalidez lors de chaque nouvelle activation ou mise à jour majeure.

Limites et dépendances. Dust est livré en SaaS managé (régions UE/US) ; il n'existe pas d'édition self-hosted/on-premise largement disponible. L'investissement dans la configuration, les agents et les connecteurs crée une dépendance — documentez vos configurations et gardez une stratégie de réversibilité. Pour les contextes exigeant un air-gap strict, d'autres approches (plateformes auto-hébergeables) existent mais sortent du périmètre de ce guide.

FAQ — Déploiement sécurisé de Dust en entreprise

L'injection de prompt est-elle un risque spécifique à Dust ou général aux plateformes LLM ?

Il s'agit d'un risque structurel à l'ensemble des plateformes LLM agentiques, classé n°1 de l'OWASP LLM Top 10. La spécificité de Dust est qu'elle amplifie ce risque par la richesse de ses connecteurs : un agent peut ingérer des tickets Zendesk, des e-mails (mis en copie), des documents Google Drive et des pages web — autant de vecteurs d'injection indirecte potentiels. Aucune technique (filtres, RAG, fine-tuning) ne neutralise complètement ce risque ; la défense efficace agit sur la capacité d'action en bout de chaîne, pas sur la compréhension du modèle.

Dust est SOC 2 Type II — est-ce suffisant pour valider le déploiement ?

Non. SOC 2 Type II atteste que des contrôles existent chez l'éditeur et fonctionnent dans la durée — c'est une attestation d'organisation, pas une garantie d'absence de vulnérabilité dans votre déploiement spécifique. La majorité des incidents sur ce type de plateforme viennent de la configuration client. Exigez le rapport complet sous NDA, la liste des sous-traitants et le DPA, puis réalisez votre propre analyse de risques et votre red teaming LLM/MCP. Un audit cybersécurité spécifique au déploiement IA reste indispensable.

Faut-il des compétences de red team spécialisées pour tester un déploiement Dust ?

Oui, un pentest web traditionnel ne couvre pas les risques spécifiques aux LLM. Il faut des outils et des compétences dédiés : garak (scanner de vulnérabilités LLM), PyRIT (Microsoft), promptfoo ou Giskard pour les tests d'évaluation, et mcp-scan pour les serveurs MCP. Les critères de réussite/échec doivent être définis avant le test : le cloisonnement des Spaces tient-il au niveau API ? Une injection indirecte déclenche-t-elle une action ? Un rug pull sur une description d'outil est-il détecté ? Ces tests doivent couvrir l'API et l'interface — le rapport HackerOne #3101858 montre que les deux peuvent avoir des règles d'accès incohérentes.

Comment gérer l'offboarding d'un employé qui avait créé des agents et des connecteurs Dust ?

Le SCIM gère la révocation immédiate du compte utilisateur, mais ne supprime pas automatiquement les objets créés par cet utilisateur. La procédure complète doit couvrir : révocation SCIM immédiate du compte (teste-la au moment de la mise en place, pas au moment du départ), identification de tous les agents et connecteurs dont il est le propriétaire, reprise de propriété ou suppression selon la politique, vérification que ses connecteurs ne reposaient pas sur des accès personnels (tokens OAuth liés à son compte), et rotation des secrets partagés s'il y avait accès. C'est une des raisons pour lesquelles les comptes de service dédiés sont préférables aux accès personnels pour les connecteurs en production.

Quels sont les signaux d'alerte à surveiller dans les journaux Dust via le SIEM ?

Les détections prioritaires à configurer : tout message contenant des motifs d'injection (ignore tes instructions, envoie à, <IMPORTANT>) dans les conversations d'agents ; un pic d'actions par un seul utilisateur dépassant nettement sa moyenne sur 24 h (indicateur de compromission de compte) ; tout ajout d'un nouveau serveur MCP ou modification d'un connecteur existant ; tout passage d'un connecteur du mode lecture seule au mode écriture ; tout accès à un Space restreint par un utilisateur dont l'appartenance au groupe n'a pas été validée ; et tout appel API utilisant une clé d'API depuis une IP non habituelle.

Dust dispose-t-il d'une édition on-premise pour les environnements à air-gap strict ?

À la date de rédaction de ce guide (juin 2026), Dust est livré exclusivement en SaaS managé avec deux régions : UE (eu.dust.tt) et US. Il n'existe pas d'édition self-hosted largement disponible même si le code source est partiellement ouvert sur github.com/dust-tt/dust. Pour les environnements nécessitant un air-gap strict, la résidence régionale en EU et les engagements contractuels de non-rétention sont les principaux leviers disponibles. D'autres plateformes d'agents auto-hébergeables existent mais sortent du périmètre de ce guide. Consultez le Trust Center Dust pour les évolutions de l'offre de déploiement.

Conclusion

Dust illustre le double visage de l'IA agentique : une plateforme capable de démultiplier la productivité en connectant des agents au cœur du SI, et, par cette même connexion, une concentration de risques qui exige une discipline de sécurité à la hauteur. Trois enseignements doivent rester en tête après la lecture de ce guide.

D'abord, la frontière entre données et instructions n'existe pas pour un modèle : toute source qui alimente un agent est un canal d'injection potentiel, et c'est pourquoi l'injection de prompt reste le risque n°1 selon l'OWASP LLM Top 10. Ensuite, le danger maximal naît de la combinaison entre autonomie et privilèges : un agent qui agit largement sans supervision transforme une faille de confidentialité en faille d'intégrité à l'échelle du SI — c'est le scénario S2 (agent surprivilégié) dans sa version la plus destructrice. Enfin, la sécurité d'un déploiement Dust est d'abord une affaire de configuration et de gouvernance : l'éditeur fournit des contrôles robustes (SOC 2 Type II, SSO/SCIM, Spaces, journaux d'audit 365 jours), mais c'est à vous de les activer, de les calibrer et de les surveiller.

Le piège à éviter absolument : sécuriser trop tard, après avoir connecté large et autorisé l'écriture « pour aller vite ». L'appel à l'action est simple : démarrez au Niveau 1 (SSO, Spaces restreints, lecture seule, pas de MCP tiers, journaux activés), prouvez la valeur sur un périmètre maîtrisé, puis montez en maturité par paliers conscients et documentés. À chaque étape, mesurez la valeur métier obtenue face au risque ajouté — les KPIs de la section 9 sont votre tableau de bord.

Un dernier mot de méthode : modèles, connecteurs, fonctionnalités et techniques d'attaque changent de mois en mois. Un déploiement sécurisé n'est pas un état figé mais un processus — revue trimestrielle, tests adversariaux réguliers, veille active sur le programme HackerOne de Dust et les publications du Trust Center. C'est à cette condition que la promesse de l'IA agentique se réalise sans coût caché, et que l'IA reste un levier de compétitivité plutôt qu'une vulnérabilité systémique. Pour aller plus loin dans votre posture de sécurité globale, consultez nos ressources sur l'architecture Zero Trust et notre accompagnement certification ISO 27001.