Pentest ChatGPT, Claude, Gemini intégrés en entreprise

Pentester ChatGPT Enterprise, Claude Enterprise, Gemini for Workspace ou Microsoft 365 Copilot ne signifie pas auditer le modèle de langage lui-même — celui-ci appartient au fournisseur et reste opaque. L'audit cible l'intégration : scopes OAuth accordés, ACL des connecteurs SharePoint/Drive, custom GPTs et Gems déployés, plugins/actions tiers, configuration DLP et shadow AI non encadré. Cet article structure la méthodologie black-box adaptée à ces déploiements SaaS, avec un focus sur Microsoft 365 Copilot qui présente la surface d'attaque la plus large en 2025.

1. Pourquoi auditer un LLM SaaS d'entreprise est différent

Trois différences structurelles avec un pentest de chatbot custom (covert dans Pentest d'un chatbot IA d'entreprise) :

• Le modèle est opaque — pas d'accès aux poids, à l'architecture, aux logs serveur. Les vulnérabilités intrinsèques du modèle (LLM01 prompt injection, LLM07 system prompt leakage du modèle de base) restent du ressort du fournisseur. L'audit se concentre sur ce que le client contrôle.
• L'identité héritée du SSO — les LLM SaaS d'entreprise sont quasi systématiquement intégrés au SSO de l'organisation (Entra ID, Google Workspace, Okta). Toute mauvaise configuration IAM héritée du SI entreprise se propage au comportement du LLM.
• Les connecteurs comme surface principale — ChatGPT Enterprise lit SharePoint via connector, Copilot accède à OneDrive natif, Gemini Workspace exploite Drive. La surface d'attaque dominante n'est pas le prompt, c'est l'ACL des sources connectées.

L'audit reste pertinent même sans accès aux internals du modèle. Il couvre des risques que le fournisseur ne couvre pas : le client est responsable de sa propre configuration, de ses ACL, de ses scopes OAuth.

2. Surface d'attaque commune aux quatre plateformes

ChatGPT Enterprise, Claude Enterprise, Gemini for Workspace et Microsoft 365 Copilot partagent un noyau commun de surface d'attaque, indépendamment du fournisseur.

Voir Audit IA générative : checklist OWASP LLM Top 10 pour le détail des contrôles par vulnérabilité.

3. Spécificités plateforme par plateforme

Les quatre plateformes diffèrent sur leurs surfaces propres et leurs garanties de gouvernance.

Points d'attention par plateforme

• ChatGPT Enterprise — l'audit prioritaire est sur les Custom GPTs déployés en Workspace : un GPT avec une Action vers une API interne expose cette API à toutes les requêtes utilisateur. Vérifier les scopes des Actions et l'authentification OAuth des callbacks.
• Claude Enterprise — depuis le déploiement de MCP (Model Context Protocol), auditer chaque MCP server connecté — c'est l'équivalent des plugins, et leur sécurité dépend entièrement de l'implémentation MCP côté client. Voir les retours documentés sur les premières CVE MCP fin 2025.
• Gemini for Workspace — la surface dominante est l'ACL Drive. Un dossier mal partagé (par exemple « Tous les employés peuvent voir » sur des documents RH) devient interrogeable en langage naturel via Gemini, ce qui est plus exploitable qu'une recherche Drive classique.
• Microsoft 365 Copilot — surface la plus large car connecteurs natifs au tenant Microsoft Graph. Les ACL héritées des dix dernières années deviennent explorables. Voir section 5 ci-dessous, focus dédié.

4. Méthodologie de test black-box adaptée

Quatre phases pour un audit black-box de LLM SaaS d'entreprise. Durée typique : 8 à 15 jours-homme.

Phase 1 — Inventaire de la surface réelle (2-3 jours)

• Lister tous les comptes Workspace ChatGPT Enterprise / Claude Enterprise / Workspace Google / tenant Microsoft 365 où le LLM est déployé.
• Recenser les Custom GPTs / Gems / Copilot agents existants — souvent inconnus de l'IT car créés par les métiers.
• Inventorier les connecteurs configurés et leurs scopes (SharePoint sites accessibles, Drive folders, calendriers, mailboxes).
• Identifier les plugins / Actions / MCP servers / extensions tierces installés.
• Détecter le shadow AI via CASB ou analyse DNS — comptes ChatGPT personnels utilisés depuis terminaux entreprise.

Phase 2 — Audit des configurations (2-4 jours)

• Vérifier les politiques d'admission au LLM (qui peut l'utiliser, depuis quels appareils).
• Auditer les scopes OAuth accordés aux applications tierces.
• Vérifier la rétention conversationnelle et le partage entre utilisateurs.
• Auditer les politiques DLP appliquées à la sortie du LLM.
• Vérifier les options de marquage de sensibilité (Microsoft Purview, Google sensitivity labels).

Phase 3 — Tests offensifs ciblés (3-5 jours)

• Tests OWASP LLM Top 10 sur les Custom GPTs / Gems / agents (LLM01, LLM06, LLM07).
• Tests d'accès cross-utilisateurs via les connecteurs (un user A peut-il interroger des données accessibles à user B mais pas à lui ?).
• Tests d'injection indirecte via documents partagés volontairement piégés (zone d'audit isolée).
• Tests de bypass DLP en sortie (encodage, formats inhabituels).
• Tests denial of wallet via prompts coûteux et boucles d'agents.

Phase 4 — Reporting (1-2 jours)

Rapport spécifique LLM SaaS qui distingue clairement :

• Findings de configuration (côté client, remédiables immédiatement) — la majorité.
• Findings de design produit (côté fournisseur, à signaler mais non remédiables côté client) — minoritaires.
• Findings de gouvernance (organisation, processus) — souvent les plus structurants.

5. Cas typique : audit Microsoft 365 Copilot

Microsoft 365 Copilot mérite un focus dédié car il représente le déploiement LLM SaaS le plus massif en entreprise européenne en 2025, et présente la surface la plus large.

Spécificités Copilot

• Accès natif via Microsoft Graph à : SharePoint, OneDrive, Exchange (mails, calendrier), Teams (messages, réunions, transcriptions), Loop, Planner, Whiteboard.
• Hérite des ACL existantes sans création de nouvelles permissions — la pure conséquence est que les misconfigurations dormantes deviennent activement exploitables.
• Copilot Studio permet de créer des agents IA personnalisés branchés sur Power Platform, ce qui ouvre une surface d'écriture massive (création d'enregistrements Dataverse, exécution de Power Automate flows).
• Audit Microsoft Purview centralise les logs Copilot (AICopilotInteraction, AICopilotAdminLog).

Tests prioritaires Copilot

# Audit ACL SharePoint exploitables via Copilot — exemple Python
# Hypothèse : auditeur connecté avec un compte test à droits limités
import requests
 
GRAPH_BASE = "https://graph.microsoft.com/v1.0"
HEADERS = {"Authorization": "Bearer <access_token_audit>"}
 
# Étape 1 — Lister les sites SharePoint accessibles à l'utilisateur d'audit
sites = requests.get(f"{GRAPH_BASE}/sites?search=*", headers=HEADERS).json()
print(f"Sites accessibles : {len(sites.get('value', []))}")
 
# Étape 2 — Pour chaque site, identifier les documents marqués sensibles
sensitive_kws = ["confidentiel", "salaire", "contrat", "secret", "interne"]
exposed_docs = []
 
for site in sites.get("value", []):
    drives = requests.get(
        f"{GRAPH_BASE}/sites/{site['id']}/drives", headers=HEADERS
    ).json()
    for drive in drives.get("value", []):
        items = requests.get(
            f"{GRAPH_BASE}/drives/{drive['id']}/root/children",
            headers=HEADERS,
        ).json()
        for item in items.get("value", []):
            name = item.get("name", "").lower()
            if any(kw in name for kw in sensitive_kws):
                exposed_docs.append({
                    "site": site["displayName"],
                    "name": item["name"],
                    "size": item.get("size"),
                })
 
# Étape 3 — Tester une requête Copilot ciblant ces documents
# (depuis l'interface Copilot, pas Graph) :
# "Résume les documents contenant 'salaire' que tu peux trouver dans
#  les sites SharePoint partagés avec moi."
print(f"Documents exposés à Copilot via ACL trop larges : {len(exposed_docs)}")

Findings types Microsoft 365 Copilot

• ACL héritées trop larges sur SharePoint sites « Tous les utilisateurs authentifiés » — extension de la surface fuites de données.
• Custom Copilot agents créés par les métiers sans validation IT, exposant des connecteurs Power Platform vers des ressources sensibles.
• Marquage de sensibilité absent ou incohérent sur les documents — Copilot ne respecte les contraintes de sensibilité que si elles sont posées via Microsoft Purview.
• Logs Purview non monitorés — les interactions Copilot sont loggées mais peu d'organisations exploitent ces logs activement.
• Shadow Copilot — utilisation depuis comptes Microsoft personnels en lien avec terminal entreprise.

6. Findings types et plan de remédiation

Synthèse des findings récurrents observés sur les pentests LLM SaaS d'entreprise 2024-2025.

Points clés à retenir

• L'audit d'un LLM SaaS d'entreprise n'est pas l'audit du modèle — c'est l'audit de l'intégration côté client : scopes, ACL connecteurs, Custom GPTs/Gems/agents, plugins, DLP, shadow AI.
• Les ACL héritées du SI sont la surface d'attaque dominante — particulièrement sur Microsoft 365 Copilot et Gemini for Workspace dont les connecteurs sont natifs.
• Microsoft 365 Copilot mérite un focus dédié — il rend exploitables en langage naturel toutes les misconfigurations dormantes et présente la surface la plus large.
• Le shadow AI est sous-estimé d'un facteur 3-5 — détection via CASB + sondage employés indispensable avant tout audit.
• La gouvernance des Custom GPTs / Gems / agents Copilot Studio est la remédiation la plus rentable — elle coupe 60-80 % des findings techniques avant qu'ils n'apparaissent.

Pour aller plus loin, voir Pentest d'un chatbot IA d'entreprise pour les déploiements custom, Audit de conformité IA pour la dimension réglementaire (EU AI Act applicable aux Custom GPTs et agents Copilot internes), et Tester les vulnérabilités d'un agent IA autonome pour les agents Copilot Studio multi-tools. Le bootcamp LLM Security inclut un lab dédié à l'audit Microsoft 365 Copilot sur tenant de test.