Accès fantôme à l'IA : comment les outils d'IA héritent des autorisations d'accès aux données sensibles

Les employés n'ont pas besoin de transférer des données sensibles vers un outil d'IA non approuvé pour créer un risque lié à l'IA.

Parfois, il suffit de le connecter.

Un employé autorise un assistant IA à résumer des fichiers sur un espace de stockage cloud. Un développeur connecte un outil de codage IA à un dépôt de code source. Une équipe métier ajoute un agent IA à une application SaaS. Un flux de travail autonome utilise un compte de service existant pour extraire des informations d'une base de données.

Dans chaque cas, l'outil d'IA peut accéder aux données grâce aux autorisations existantes.

Cela crée un problème de sécurité croissant : Accès à l'IA fantôme.

L'accès fantôme à l'IA se produit lorsque des outils, agents, applications ou intégrations d'IA accèdent aux données de l'entreprise en dehors des processus de sécurité et de gouvernance établis, notamment par le biais d'autorisations héritées ou déléguées.

Le défi ne consiste pas simplement à identifier les outils d'IA utilisés par les employés. Les organisations doivent également comprendre à quoi ces systèmes d'IA peuvent accéder, comment ils ont obtenu cet accès, quelles données sensibles sont sous-jacentes et si cet accès crée une exposition inutile.

Qu’est-ce que Shadow AI Access ?

L'accès à l'IA fantôme désigne l'accès aux données d'entreprise créé par des outils, agents, applications ou intégrations d'IA qui fonctionnent en dehors des processus d'IA approuvés ou entièrement réglementés.

Il est étroitement lié à l'IA fantôme, mais ces deux concepts répondent à des questions de sécurité différentes.

Shadow AI Discovery pose la question suivante : Quelles formes d'IA les gens utilisent-ils ?

L'accès à Shadow AI demande : Jusqu'où cette IA peut-elle aller ?

Une organisation peut identifier une application d'IA et pourtant ne rien savoir des risques liés aux données qu'elle implique.

Les équipes de sécurité doivent également déterminer :

• Quels utilisateurs et quelles identités se connectent au système d'IA ?
• Quelles autorisations a-t-il reçues ?
• Ces autorisations ont-elles été accordées directement ou par héritage ?
• Quelles applications, API, référentiels et bases de données peut-il atteindre ?
• Quelles données sensibles sont contenues dans ces ressources ?
• Quelles actions l'IA peut-elle effectuer ?
• À qui appartient l'intégration ?
• Cet accès correspond-il à un objectif commercial légitime ?

Sans ce contexte, un inventaire des outils d'IA peut montrer où l'IA est présente sans pour autant indiquer où elle crée une exposition significative des données.

Comment l'IA fantôme accède aux données d'entreprise

L'IA n'a pas besoin d'un compte de base de données dédié pour accéder aux informations de l'entreprise.

L'accès peut provenir d'identités et d'intégrations déjà utilisées par les organisations.

1. Accès délégué par l'utilisateur

Prenons l'exemple d'un employé qui connecte un assistant de productivité IA à un compte de stockage cloud.

L'employé a déjà accès à :

• Documents de l'équipe
• Présentations aux clients
• Prévisions financières internes
• Contrats
• Documents stratégiques

L'employé autorise l'application d'IA à lire les fichiers afin qu'elle puisse rechercher ou résumer des documents.

L'organisation n'a pas accordé d'accès direct à l'outil d'IA. L'utilisateur a étendu un accès existant.

Si les autorisations de cet utilisateur sont déjà excessives, l'intégration de l'IA peut hériter des conséquences de cet accès excessif.

2. Application et autorisations OAuth

Les applications d'IA modernes s'intègrent souvent aux plateformes SaaS d'entreprise via OAuth ou d'autres méthodes d'autorisation déléguée.

Une intégration utile pourrait demander l'autorisation de lire les fichiers, les messages, les calendriers, les contacts, les référentiels ou les enregistrements.

L'entreprise y voit un atout en matière de productivité.

Le service de sécurité doit pouvoir visualiser la relation d'accès sous-jacente.

Une autorisation telle que “ lire les fichiers ” prend une tout autre dimension lorsque ces fichiers contiennent des dossiers clients, des informations sur les employés, des contrats, des justificatifs d'identité, de la propriété intellectuelle ou des informations réglementées.

3. API

Les agents d'IA utilisent fréquemment des API pour récupérer des informations ou exécuter des actions.

Par exemple, un agent de support peut appeler une API qui récupère les enregistrements clients à partir d'un CRM.

Si l'API permet à l'agent de récupérer tous les enregistrements clients alors que le flux de travail ne nécessite que des informations sur le client qui demande actuellement de l'aide, l'IA risque d'avoir un accès plus large que ce que son objectif requiert.

L'interface d'IA peut sembler limitée, alors que l'API sous-jacente offre un accès beaucoup plus large.

4. Comptes de service et identités machine

Un flux de travail d'IA peut s'authentifier via un compte de service plutôt que via un utilisateur individuel.

Ce compte de service pourrait être antérieur de plusieurs années au projet d'IA.

Au fil du temps, il a pu accumuler des accès à des bases de données, des systèmes de stockage, des applications et des ressources cloud.

Lier un agent d'IA à cette identité peut soudainement rendre ces autorisations existantes pertinentes pour la sécurité de l'IA.

Voilà pourquoi sécurité de l'identité de la machine et la gouvernance de l'accès à l'IA se recoupent de plus en plus.

Comment l'accès à l'IA fantôme se propage

La difficulté réside dans le fait que l'accès à l'IA peut transiter par plusieurs couches avant d'atteindre les données.

Un exemple concret : l’assistant de réunion IA

Prenons l'exemple d'une équipe commerciale qui adopte un assistant de réunion basé sur l'IA.

À première vue, la décision en matière de sécurité semble simple. L'outil enregistre les réunions et génère des résumés.

Mais l'équipe le connecte à plusieurs autres systèmes :

• calendriers d'entreprise
• E-mail
• Stockage en nuage
• Le CRM
• Plateformes de collaboration

Désormais, l'empreinte potentielle de cet outil en matière de données s'étend au-delà des transcriptions de réunions.

Selon ses autorisations, il pourrait avoir accès aux noms des clients, à leurs coordonnées, aux discussions contractuelles, aux prix, aux prévisions de ventes, à la stratégie interne, aux problèmes d'assistance ou à d'autres informations confidentielles.

Le risque ne provient pas des mots “ assistant de réunion IA ”.”

Le risque provient de la combinaison de l'accès, des autorisations, des données sensibles et de la finalité commerciale.

C’est pourquoi bloquer ou approuver une application d’IA uniquement sur la base de son nom ou de sa catégorie ne résout pas le problème sous-jacent.

Autre exemple : l’assistant IA pour développeurs

Un développeur connecte un assistant de codage IA à un dépôt de code source.

L'objectif est légitime : aider le développeur à comprendre le code, à résoudre les problèmes et à travailler plus rapidement.

Mais le référentiel contient plus que de la logique applicative.

Il peut également contenir :

• Clés API
• Secrets
• chaînes de connexion à la base de données
• URL internes
• Algorithmes propriétaires
• Données de configuration client
• Détails de l'infrastructure

La question importante n'est plus simplement de savoir si l'entreprise autorise l'assistant de codage IA.

L'organisation a besoin de savoir quels référentiels il peut atteindre et quelles informations sensibles ces référentiels contiennent.

Cela transforme Shadow AI d'un problème de gestion d'applications en un problème de sécurité des données.

Découverte de l'IA fantôme vs gouvernance d'accès à l'IA fantôme

Les organisations ont besoin de ces deux capacités, mais elles résolvent différentes parties du problème.

Pourquoi bloquer l'IA fantôme ne suffit pas

Les organisations peuvent interdire une application d'IA et malgré tout rencontrer un problème d'accès à l'IA.

De nouveaux outils apparaissent. Les employés adoptent de nouveaux services. Les fournisseurs SaaS existants ajoutent des fonctionnalités d'IA. Les applications approuvées intègrent des copilotes. Les équipes de développement créent des agents en interne.

Un modèle binaire approuvé/non approuvé traite également deux situations très différentes comme si elles présentaient le même risque.

Considérer:

• Un outil d'IA non approuvé et sans lien avec les données d'entreprise
• Un agent d'IA agréé disposant d'un large accès aux informations clients et financières

La première soulève un problème de gouvernance.

La seconde option peut entraîner une exposition des données beaucoup plus importante.

Les équipes de sécurité doivent donc évaluer l'IA en fonction de ce qu'elle peut réellement atteindre et faire, et non pas simplement parce qu'elle figure sur une liste d'applications approuvées.

Comment réduire les risques d'accès à l'IA fantôme

Un programme pratique relie la découverte de l'IA, l'identité, l'accès, les données, l'activité et la remédiation.

1. Détecter l'IA dans toute l'entreprise

Tenir un inventaire des applications, agents, copilotes, assistants, modèles et intégrations d'IA.

Inclure les IA autorisées et non autorisées.

Pour chaque système, identifiez dans la mesure du possible son objectif commercial et son responsable.

2. Identifier les identités derrière l'IA

Déterminez comment chaque système d'IA s'authentifie et obtient l'accès.

Rechercher:

• Utilisateurs
• Groupes
• OAuth accorde
• Applications
• Apis
• Comptes de service
• Identités des machines
• Rôles cloud
• Autorisations déléguées

Un inventaire d'IA sans contexte d'identité peut ne pas comprendre comment l'outil accède réellement aux ressources de l'entreprise.

3. Cartographier les autorisations et les chemins d'accès de l'IA

Déterminez ce que le système d'IA peut faire et d'où proviennent ces autorisations.

Ne vous contentez pas des autorisations directes.

Tracer les accès hérités et indirects via les applications, les API, les comptes de service, les groupes, les rôles et autres identités.

Le guide de BigID Autorisations IA explique comment ces relations peuvent étendre l'accès effectif d'un système d'IA.

4. Connecter l'accès de l'IA aux données sensibles

C’est à ce stade qu’une carte d’accès devient utile pour la prise de décisions relatives aux risques.

Déterminer si l'IA peut atteindre :

• Informations personnelles
• Dossiers clients
• Informations sur les employés
• données financières
• Informations sur la santé
• Identifiants et secrets
• Code source
• propriété intellectuelle
• Contrats
• Autres informations réglementées ou essentielles à l'activité

Découverte et classification des données donne aux équipes de sécurité le contexte nécessaire pour comprendre ce qui se cache derrière une autorisation d'IA.

5. Comparer l'accès à l'objectif commercial

Demandez-vous si l'IA a réellement besoin de l'accès dont elle dispose.

Un assistant de réunion peut avoir besoin d'accéder au calendrier. Il n'a probablement pas besoin d'un accès illimité à tous les fichiers accessibles à un cadre dirigeant.

Un assistant de programmation peut avoir besoin d'accéder à un dépôt spécifique. Il n'a pas forcément besoin d'accéder à tous les dépôts disponibles pour le développeur qui l'a connecté.

Un agent du service client peut avoir besoin de consulter le dossier d'un client individuel. Il n'a pas forcément besoin d'autorisations d'exportation en masse.

L'objectif constitue le point de départ pour moindre privilège.

6. Prioriser l'accès à l'IA qui crée un risque réel

Une liste exhaustive de toutes les autorisations d'IA peut rapidement devenir un autre arriéré en matière de sécurité.

Prioriser les résultats en fonction du contexte, par exemple :

• Sensibilité des données
• Niveau de gravité de l'autorisation
• Chemin d'accès
• Activité
• Possession
• Exposition
• Objectif commercial
• Impact potentiel

Cela permet aux équipes de distinguer une autorisation de lecture inutilisée pour un contenu à faible risque d'une intégration d'IA active capable d'exporter des données clients sensibles.

7. Réduire l'accès excessif et surveiller les changements

L'accès à l'IA ne reste pas statique.

Les employés connectent de nouvelles applications. Les fournisseurs intègrent de nouvelles fonctionnalités d'IA. Les autorisations évoluent. Les données sont transférées. Les agents acquièrent de nouveaux outils. Les comptes de service accumulent des droits d'accès.

Les équipes doivent identifier et traiter en permanence :

• Autorisations inutiles pour l'IA
• Accès excessif aux données sensibles
• Intégrations d'IA obsolètes
• Agents orphelins
• Propriétaire inconnu
• Nouveaux chemins d'accès
• Modifications de l'exposition des données sensibles

La surveillance continue transforme la gouvernance de l'IA parallèle d'un inventaire périodique en un processus de gestion des risques permanent.

Questions que les décideurs devraient poser à propos de l'IA fantôme

Les dirigeants n'ont pas besoin d'une liste exhaustive de toutes les étendues OAuth ou des droits d'accès aux API.

Ils ont besoin d'être assurés que les équipes peuvent relier l'adoption de l'IA aux risques commerciaux.

L'intelligence artificielle fantôme devient un problème d'accès aux données

L'adoption de l'IA évolue rapidement car les organisations n'introduisent plus l'IA via un modèle de déploiement centralisé.

L'IA arrive via des outils autonomes, des applications SaaS existantes, des copilotes, des API, des plateformes de développement, des fonctionnalités intégrées et des agents autonomes.

Cela rend la découverte des applications nécessaire, mais insuffisante.

Les organisations doivent répondre à trois questions :

Quelle forme d'IA existe ?

À quoi peut-il accéder ?

Quelles données cet accès expose-t-il ?

Ce lien offre aux équipes de sécurité et de gouvernance un moyen beaucoup plus clair de distinguer l'adoption de l'IA des risques liés à l'IA.

Comment BigID contribue à contrôler l'accès aux IA fantômes

BigID relie la découverte par l'IA aux données et au contexte d'accès nécessaires pour comprendre l'exposition.

Au lieu de considérer une application d'IA comme un actif isolé, BigID aide les équipes à comprendre les relations entre les systèmes d'IA, les identités, les autorisations, les applications, les API, l'activité, la propriété et les données sensibles de l'entreprise.

Les organisations peuvent utiliser BigID pour :

• Découvrez l'IA : Identifier les systèmes d'IA, les applications, les agents, les copilotes et autres utilisations de l'IA au sein de l'entreprise.
• Comprendre l'accès à l'IA : Cartographiez les identités, les autorisations, les applications, les API, les comptes de service et les identités machine impliqués dans l'accès à l'IA.
• Connexion à l'accès aux données sensibles : Identifier les informations réglementées, confidentielles, exclusives et essentielles à l'activité que l'IA peut atteindre.
• Détecter les accès excessifs : Identifier les accès à l'IA qui dépassent les besoins légitimes de l'entreprise ou qui créent une exposition inutile.
• Ajouter le contexte de propriété et d'activité : Déterminer qui détient l'accès à l'IA et si les autorisations restent pertinentes et actives.
• Prioriser les risques : Les équipes de sécurité doivent concentrer leurs efforts sur l'accès à l'IA qui expose les données les plus sensibles ou critiques.
• Réduire l'exposition : Accès adapté, assigner des mesures correctives, appliquer les politiques et surveiller les changements au fil du temps.

Cela relie la gouvernance de l'IA parallèle à Gouvernance de l'accès à l'IA et la sécurité des données.

Détecter Shadow AI vous indique où chercher. Comprendre son mode d'accès vous indique où agir.

FAQ sur l'accès à Shadow AI

Qu’est-ce que l’accès à l’IA fantôme ?

L'accès à l'IA fantôme se produit lorsque des outils, agents, applications ou intégrations d'IA accèdent à des systèmes ou données d'entreprise en dehors de processus d'IA approuvés ou entièrement contrôlés, y compris par le biais d'autorisations héritées et déléguées.

Comment une IA fantôme peut-elle accéder à des données sensibles ?

L'IA fantôme peut accéder à des données sensibles via les utilisateurs, les applications, les autorisations OAuth, les API, les comptes de service, les identités machine, les rôles cloud, les groupes et d'autres intégrations. L'outil d'IA peut hériter d'un accès existant plutôt que d'obtenir un accès direct aux données.

Quelle est la différence entre l'IA fantôme et l'accès à l'IA fantôme ?

L'IA fantôme désigne les technologies d'IA utilisées en dehors des processus d'approbation ou de gouvernance organisationnels établis. L'accès à l'IA fantôme concerne les systèmes d'entreprise, les autorisations, les identités et les données sensibles auxquels ces systèmes d'IA peuvent accéder.

Pourquoi les permissions héritées représentent-elles un risque pour l'IA ?

Les autorisations héritées peuvent conférer à un système d'IA des accès dépassant le cadre prévu. Si l'utilisateur, l'application, l'API ou le compte de service associé à l'IA dispose déjà d'un accès excessif, la connexion à une IA peut aggraver cette vulnérabilité.

L'IA approuvée peut-elle créer un accès excessif ?

Oui. L'approbation d'une application d'IA ne garantit pas que chaque autorisation ou connexion de données soit appropriée. Une IA approuvée peut toujours recevoir des autorisations excessives ou accéder à des données sensibles non requises par son objectif métier.

Bloquer l'IA fantôme est-il suffisant ?

Non. Bloquer les outils non autorisés connus peut réduire certains risques, mais les organisations doivent également contrôler l'accès aux IA approuvées, aux fonctionnalités d'IA intégrées, aux agents développés en interne, aux API et aux autres intégrations d'IA.

Comment le principe du moindre privilège s'applique-t-il à l'IA fantôme ?

Le principe du moindre privilège limite les systèmes d'IA aux autorisations, applications, outils et données nécessaires à leur finalité. Les organisations ont besoin du contexte d'identité et de données pour déterminer à quel moment l'accès de l'IA dépasse cette finalité.

Comment BigID contribue-t-il à lutter contre l'accès non autorisé à l'IA ?

BigID connecte les systèmes d'IA aux identités, aux autorisations, aux chemins d'accès, à la propriété, à l'activité et aux données sensibles afin d'aider les équipes à identifier les accès excessifs à l'IA, à prioriser l'exposition, à réduire les autorisations inutiles et à surveiller en continu les changements.