Sécurité de l’IA et droits d’accès

Des connaissances confidentielles.
Protégées de manière ciblée.

L’IA facilite l’accès aux connaissances. DAXS vérifie flux, droits et outils pour que les connaissances d’entreprise soient utilisées uniquement dans les cadres autorisés sur les plans métier et technique.

Deux personnes échangent sur l’utilisation d’un poste informatique.
Quand les droits existants deviennent soudain visibles

L’IA peut trop révéler sans contourner de protection.

Une IA d’entreprise peut rendre plus visibles des documents auparavant peu connus. Cela pose problème si le stockage est accessible à davantage de personnes que prévu par le métier. La surexposition par l’IA désigne ici la divulgation involontaire causée par des partages trop larges et une recherche facilitée. Une réponse techniquement autorisée peut néanmoins être indésirable pour l’organisation.

Service précis, sources connectées et identité utilisée pour la recherche sont déterminants. Un chat sans connexion aux données ne peut pas simplement parcourir tous les dossiers de l’entreprise. Téléversement, index connecté ou outils autorisés créent en revanche un flux à vérifier de manière traçable.

« Combien gagne mon responsable ? »

Cas hypothétique : un fichier de salaires se trouve dans un ancien dossier RH. Un partage de groupe hérité donne aussi un accès en lecture à des personnes extérieures aux RH. Si le service d’IA peut exploiter le fichier et si la requête est autorisée avec ces droits, son contenu pertinent peut contribuer à une réponse. Une valeur erronée ou une réponse inventée reste aussi possible ; toute sortie concrète nécessite une source.

Avec des droits correctement limités, le fichier protégé ne doit jamais entrer dans le contexte du modèle pour des personnes non habilitées. Une instruction demandant au modèle de garder les salaires secrets ne remplace pas ce contrôle technique.

Même système, droits différents

Trois personnes posent la même question.

A a besoin de l’information pour une tâche autorisée. B ne possède aucun droit de lecture. C reçoit un accès involontaire à cause d’une erreur d’habilitation. Le système doit exclure B ; pour C, les droits sources erronés doivent être corrigés.

Trois personnes interrogent des données confidentielles : les droits adaptés autorisent A, B est exclu et C possède un droit de lecture attribué par erreur.
Exemple hypothétique. Les droits sont appliqués avant le modèle ; un accès autorisé par erreur exige une correction du partage source.

Le schéma décrit des situations d’accès différentes, sans représenter trois étapes successives. Le service de recherche doit aussi tenir compte des changements : un droit retiré ne doit pas subsister dans des droits d’index périmés, caches, conversations partagées ou fichiers exportés.

Nommer clairement les limites

Masqué, chiffré et protégé sont des propriétés différentes.

Navigation et accès
Masquer un menu ou rendre un nom de dossier inconnu ne retire pas les droits de lecture. La protection doit agir sur l’objet et le service, y compris par adresse directe, recherche et API.
Héritage et partage
Un document peut hériter des droits de dossiers parents, groupes, partages individuels ou liens. Il faut vérifier l’accès effectif avec ces parcours ; une seule liste de groupes ne suffit pas.
Index et original
Un résultat de recherche ne crée pas de droit. Index, extraits, titres, aperçus et consultation de l’original nécessitent des contrôles adaptés. Un simple titre peut déjà révéler une information confidentielle.
Chiffrement et autorisation
Le chiffrement protège notamment transport et stockage. L’autorisation de lecture auprès de l’application se décide séparément. Un compte de service capable de déchiffrer ne peut donc pas restituer les contenus à tout utilisateur connecté.
Utilisateur et agent
Un agent peut utiliser des droits délégués ou sa propre identité de service. Les deux modèles nécessitent des limites explicites. Un agent commun avec un compte étendu ne doit pas contourner les droits de ses utilisateurs.
Services internes et externes
Même une IA interne nécessite droits sources, protection des journaux et interfaces sécurisées. Les connecteurs externes ajoutent destinataires, cadre contractuel, traitement, stockage et actions autorisées.
Situations hypothétiques du quotidien professionnel

Quelles informations peuvent être retrouvées en commun ?

« Quel tarif horaire l’entreprise facture-t-elle pour moi ? »

Offres, calculs de projet ou tableaux peuvent contenir tarifs facturés et coûts internes. Ces valeurs diffèrent : le tarif facturé est le prix présenté au client. Une marge sur coûts variables n’apparaît qu’après définition des coûts à déduire. Le bénéfice de l’entreprise résulte de l’ensemble du compte de résultat. Une IA ne doit ni confondre ces valeurs ni les calculer avec une précision apparente à partir d’un seul chiffre.

Avant de connecter ces documents, les responsables définissent qui peut voir chaque calcul. Les tests doivent couvrir prix directs, remises clients, conditions d’achat et marges de projets individuels.

Le dossier de projet oublié

Un projet terminé disparaît du portail mais reste lisible par un groupe large. Si ses documents continuent d’être importés ou retrouvés par un connecteur, l’IA peut en reprendre le contenu. La mesure adaptée est une décision vérifiée d’archivage et de droits ; supprimer un lien de navigation ne suffit pas.

Décisions RH et stratégie

Changements de postes prévus, discussions de rachat, objectifs de chiffre d’affaires, investissements et prévisions de bénéfice peuvent résider dans différents espaces. Le contrôle commence donc par catégories d’information et responsables. Un stockage qualifié d’interne ne précise pas quelle équipe a besoin de quelle information.

Microsoft, ChatGPT et recherche de connaissances propre

Vérifier les fonctions, assainir les droits à la source.

Pour Copilot avec les données Microsoft 365, le fabricant décrit une récupération dans les droits de l’utilisateur concerné. Des droits de lecture trop larges restent donc un risque de déploiement. Le nom Copilot ne définit toutefois ni licence ni accès aux données ; chat, contexte applicatif et agents supplémentaires doivent être distingués. Microsoft : données et droits (lien externe) – s’ouvre dans un nouvel onglet.

Partages et gouvernance

SharePoint Advanced Management aide à examiner les accès problématiques. Microsoft Purview propose notamment classification, étiquettes de sensibilité, DLP et audit. Contrôles disponibles et flux couverts dépendent de la licence, de la configuration et de la version du produit.

Limiter la découverte des contenus

Restricted Content Discovery peut limiter recherche transversale et découverte Copilot pour certains sites SharePoint. Il ne modifie pas les droits existants et ne remplace donc pas une restriction d’accès aux fichiers confidentiels. Accès directs et exceptions doivent aussi être vérifiés.

Corriger les anciennes recommandations

Restricted SharePoint Search est en fin de vie. Selon le fabricant, toute nouvelle activation est bloquée depuis le 31 juillet 2026. Un nouveau déploiement ne doit pas y fonder une architecture de sécurité durable.

Pour ChatGPT avec des services connectés, il faut aussi savoir quel compte autorise la connexion et quels droits de données et d’actions il possède. Un espace administré organise les responsabilités ; il ne corrige pas un partage source erroné. Pour une solution RAG propre DAXS prévoit explicitement identité, filtres de droits et actualisation dans l’architecture.

Des contrôles effectifs plutôt qu’un prompt de confidentialité

Seules les informations autorisées atteignent le modèle.

  1. Catégories d’information et propriétaires : RH, finances, projets et connaissances publiques disposent de destinataires justifiés et de responsables identifiés.
  2. Moindre privilège : Utilisateurs, applications et comptes de service ne reçoivent que les droits nécessaires. Le RBAC associe droits et rôles ; l’ABAC peut ajouter des attributs comme catégorie documentaire, organisation ou appartenance à un projet.
  3. Recherche autorisée : L’application détermine une identité fiable. Security Trimming ou Permission-Aware Retrieval limite résultats et extraits avant transmission au modèle de langage. Un nom de groupe repris du prompt ne prouve pas l’identité.
  4. Modifications et caches : Nouveaux partages, retraits de droits, sources supprimées et changements de groupe sont répercutés. Les caches de réponse ne doivent pas mélanger les données d’utilisateurs ou tenants différents.
  5. DLP et règles de protection : Transmission, téléversement, téléchargement et destinataires externes autorisés sont vérifiés séparément. Une étiquette n’agit qu’avec une application configurée et prise en charge.
  6. Tests négatifs et audit : Comptes sans droits, questions directes et indirectes, sources modifiées et documents manipulés font partie de la recette. Les journaux recueillent les preuves nécessaires avec accès limité et conservation adaptée.

Divulgation d’informations sensibles et fuite de données dépassent la réponse visible : journaux de recherche, erreurs, exports et chats partagés peuvent aussi contenir du confidentiel. La vérification suit tout le flux.

Quand l’IA peut aussi agir

Droits d’outils et validations limitent les dommages.

Pour un agent, une recherche correctement filtrée ne suffit pas. Un compte de service excessivement privilégié pourrait modifier ou envoyer des données que le collaborateur demandeur ne peut pas traiter. DAXS distingue donc outils de lecture, modifications préparées et exécution réelle. API et serveurs MCP vérifient objet, identité, entrée et action autorisée dans le système cible.

Une injection de prompt peut introduire des instructions via documents externes ou résultats d’outils. Ces contenus restent des données. Les actions critiques nécessitent une validation vérifiable avec destination, périmètre et aperçu du résultat. Limites d’étapes, durée et coûts, ainsi qu’un arrêt complètent ce contrôle. Ces mesures traitent notamment les risques OWASP Prompt Injection, Sensitive Information Disclosure et Excessive Agency ; elles ne garantissent pas l’exclusion de tout risque.

Déploiement et responsabilité courante

Un contrôle de sécurité IA au périmètre vérifiable.

DAXS peut accompagner Copilot, ChatGPT ou une IA propre avec des volets délimités : inventaire des sources et comptes, matrice de droits, flux, échantillons de partages problématiques, pilote contrôlé et tests négatifs documentés. Il en résulte des mesures priorisées avec responsables et critères de recette traçables.

L’exploitation comprend changements de groupes et connecteurs, mises à jour modèles et logiciels, alertes de sécurité, contrôles réguliers des droits et traitement des sorties suspectes. Travail technique et évaluation nécessaire des données ou de l’organisation sont coordonnés. Une configuration ne prouve pas globalement la conformité RGPD ou au règlement sur l’IA.

Pour le quotidien, L’IA sur le poste de travail complète le déploiement et la formation. L’optimisation des coûts de l’IA relie protection nécessaire et choix économique des modèles.

La prochaine étape utile

Parlons de votre cas d’usage.

Quelle tâche doit devenir plus simple, quelles données sont concernées et quels systèmes utilisez-vous déjà ? Cela définit une entrée limitée avec des contrôles et décisions clairs.

Expliqué simplement

Une IA peut retrouver des fichiers partagés accidentellement avec trop de personnes. DAXS vérifie qui peut lire quelles informations et exécuter quelles actions. Les droits sont contrôlés avant transmission de textes confidentiels à l’IA.