Une seule barre de recherche pour retrouver tout ce que vous savez — et une seule requête de trop pour divulguer ce qui ne devrait jamais sortir. L’alerte récente d’exfiltration autour d’Atlassian Rovo n’était pas un cas limite étrange ; c’est l’issue logique de l’assemblage de grands modèles de langage avec des connecteurs cross‑SaaS que l’on vend comme de la « productivité ». Si vous dirigez une startup ou une scale‑up, vous avez déjà 10 à 25 surcouches IA en circulation — du Copilot par‑ci, du Q&A par‑là — souvent activées par des administrateurs métier bien intentionnés. Vos hypothèses DLP et de « moindre privilège » cessent de s’appliquer dès qu’un indexeur d’éditeur aspire votre organisation et qu’un modèle répond en croisant les silos.
Ce post vous propose un playbook opérationnel, sans fioritures : traitez les copilotes SaaS comme des intégrations non gérées, capables de faire circuler des données au‑delà des frontières. Construisez un kill‑switch couvrant l’identité, le réseau et le contenu, et entraînez‑vous chaque trimestre. Si vous ne pouvez pas empêcher un copilote de lire un espace Confluence sensible en moins de 15 minutes, ce n’est pas vous qui le contrôlez — c’est lui qui vous contrôle.
Ce qui a changé : les copilotes ont effacé vos frontières de confiance
Les contrôles traditionnels reposaient sur trois séparations :
- Frontières applicatives : Jira n’est pas Confluence, Drive n’est pas GitHub.
- Périmètres d’accès utilisateur : Alice peut lire les projets de l’équipe A, pas ceux de l’équipe B.
- Localisation des données : le contenu reste dans l’application où il a été créé.
Les copilotes cross‑SaaS abolissent ces trois séparations :
- Des connecteurs et des indexeurs opérés par les éditeurs explorent plusieurs silos, souvent via des comptes de service qui voient plus que n’importe quel humain.
- Le RAG mélange les résultats à la volée ; ainsi, « une réponse utile » peut citer un post‑mortem interne qu’Alice n’était jamais censée voir.
- Des caches, des embeddings et des traces persistent hors de votre tenant, avec des politiques de rétention et de suppression souvent floues.
Voilà pourquoi une surcouche IA peut fuiter alors même que vos applications de base sont correctement permissionnées. Le mode de défaillance n’est pas une ACL unique ; c’est une agrégation non gouvernée.
Une taxonomie simple des risques liés aux copilotes
Classez ce que vous avez déjà avant de concevoir des contrôles :
- Niveau 1 — Assistants in‑app (Risque plus faible) : fonctionnalités IA limitées à un produit et à ses permissions (ex. « résumer ce ticket Jira »).
- Niveau 2 — Recherche cross‑silo (Moyen/Élevé) : surcouches qui indexent plusieurs produits (Confluence, Drive, Slack, GitHub) et répondent en les croisant. C’est là que vivent RAG + connecteurs.
- Niveau 3 — Agents opérationnels (Élevé/Critique) : systèmes qui lisent largement et modifient aussi des ressources (ouvrir des tickets, pousser du code, mettre à jour le CRM). Ils combinent risque d’exfiltration et écritures destructrices.
Par défaut, supposez que des copilotes de Niveau 2/3 sont présents, sauf preuve du contraire. En 2026, il est rare d’en trouver moins de 6 à 12 connecteurs activés dans une organisation d’ingénierie de 200 à 500 personnes.
Le modèle de contrôle du CTO : plan des requêtes, plan des données, kill‑switch
Vous avez besoin de contrôles à trois niveaux :
- Plan des requêtes : qui peut invoquer le copilote, quels tokens il détient et quels scopes il peut demander à la volée.
- Plan des données : ce que le copilote (et son éditeur) peut réellement indexer, mettre en cache, encoder (embeddings) et récupérer ; combien de temps les données vivent, et où.
- Kill‑switch : une méthode bornée dans le temps et répétée pour couper l’accès en quelques minutes via révocation d’identité, blocage d’egress réseau et arrêt côté éditeur.
Étape 1 — Inventorier ce que vous avez vraiment (2 semaines)
On ne gouverne pas des fantômes. Commencez avec la télémétrie que vous possédez déjà :
- Journaux DNS et proxy : extrayez les 30 à 90 derniers jours. Attendez‑vous à voir des appels vers api.openai.com, *.anthropic.com, gemini.googleapis.com, bedrock.*.amazonaws.com, et une longue traîne d’endpoints LLM d’éditeurs.
- Autorisations OAuth : exportez les journaux d’octroi d’applications d’entreprise depuis votre IdP (Okta/Azure AD). Triez par scopes tels que read:all, files:read, wiki:read, repo:read, audit:read.
- Configurations des connecteurs : dans Jira/Confluence, Slack, Google Workspace, GitHub et Drive, dressez la liste des apps du marketplace dont la description contient « index », « assist » ou « search ». Documentez si elles utilisent un compte de service ou des tokens user‑on‑behalf‑of.
- Consoles d’administration éditeur : pour les copilotes achetés en connaissance de cause, capturez la résidence des données, la rétention et les paramètres de portée des connecteurs. Si vous ne les trouvez pas, c’est un constat en soi.
Scorez chaque copilote par rayon d’impact : nombre de connecteurs × portée maximale × rétention. Tout ce qui combine comptes de service et indexation cross‑silo est en rouge.
Étape 2 — Corriger l’identité en premier : scopes, JIT et OBO (2–3 semaines)
Les erreurs d’identité expliquent pourquoi les copilotes voient plus que ce que vos admins imaginent.
- Supprimez les comptes de service en lecture globale. Remplacez‑les par des tokens user‑on‑behalf‑of (OBO) liés à des groupes gérés via SCIM. Si l’éditeur ne sait pas faire de l’OBO, pas de scopes étendus.
- Extension Just‑In‑Time (JIT) pour les pilotes. Créez des groupes temporaires (ex. « Copilot‑Confluence‑Pilot ») avec une expiration à 7–14 jours. Attachez l’accès éditeur à ces groupes ; révoquez par défaut.
- Proof‑of‑possession ou tokens DPoP lorsque pris en charge. Lieez les tokens au client pour réduire les replays.
- Consentement par connecteur. Pas de scope « lire tout Drive ». Utilisez drive.file ou des permissions par dossier. Pour Confluence, liez à des espaces ; pour GitHub, à des organisations/dépôts spécifiques.
- Rotation trimestrielle des octrois. Expirez les consentements sauf ré‑approbation explicite. Automatisez via des politiques IdP.
Attendez‑vous à une baisse de 10–20% de l’effet « wow » des démos quand vous retirez les scopes globaux. C’est un compromis acceptable pour éviter de divulguer vos comptes rendus de board.
Étape 3 — Redonner la main au réseau (2 semaines)
Vous ne déchiffrerez pas tous les flux TLS, mais vous pouvez contrôler où part le trafic IA.
- Listes d’autorisation d’egress pour les destinations IA. Utilisez Cloudflare Gateway, Zscaler ou votre secure web gateway existante pour n’autoriser que des endpoints LLM évalués et des domaines d’éditeurs de copilotes connus. Bloquez par défaut tout nouvel endpoint IA générique.
- Ancrage SNI et IP pour le trafic éditeur. Lorsque les éditeurs publient des plages d’IP, restreignez en conséquence. Cela n’éliminera pas tous les contournements SaaS, mais réduit la surface d’attaque.
- Politique de split‑tunnel. Forcez les terminaux d’entreprise à passer par la passerelle ; détectez et bloquez les connexions de comptes personnels vers les mêmes domaines de copilote depuis des IP d’entreprise.
- Plafonds de débit et de taille. L’exfiltration adore le volume. Plafonnez les taux de requêtes et la taille des réponses pour les endpoints IA ; alertez sur les pics.
La politique réseau est votre kill‑switch le plus rapide : une règle de refus unique vaut mieux que courir après 12 consoles d’admin distinctes.
Étape 4 — Hygiène du contenu en périphérie (3–4 semaines, en parallèle)
Si vous devez indexer, assainissez d’abord. Ne comptez pas sur des outils côté éditeur pour comprendre vos données.
- Proxy de masquage en amont du connecteur. Insérez un service léger entre le crawler de l’éditeur et vos sources via les webhooks/hooks de fetch disponibles. Masquez de façon déterministe les classes à haut risque : clés d’API, secrets, SSN (numéros de sécurité sociale), numéros de compte bancaire, emails clients, termes de santé qui déclenchent des exigences réglementaires.
- Masquage structuré + par modèle. Employez des regex simples et des validateurs de checksum pour les formats évidents ; ajoutez un petit modèle local pour classer les paragraphes sensibles (noms de clients, éléments de roadmap). Rendez le masquage déterministe et reproductible ; journalisez les empreintes (hashes) avant/après.
- Listes de blocage côté tenant. Maintenez une denylist d’espaces, drives, dépôts et canaux Slack à ne jamais indexer. Interdiction par défaut pour tout ce qui est libellé « legal », « exec », « finance » ou « security ».
- TTL sur embeddings et caches. Exigez des éditeurs qu’ils respectent une rétention de 7 à 30 jours pour les embeddings et les journaux de conversation. S’ils ne peuvent pas la configurer, faites‑en un avenant contractuel ou réduisez leur périmètre.
Oui, le masquage dégrade la qualité des réponses. C’est le but. Vous voulez des réponses sûres par défaut, et des réponses profondes sur demande explicite.
Étape 5 — Audit de retrieval, honeytokens et exercices (2–3 semaines)
Supposez qu’un dérapage finira par se produire. Il vous faut détecter et stopper vite.
- Journaux de récupération. Pour chaque réponse, journalisez les URIs sources (espace/page/fichier/dépôt) et l’utilisateur appelant. Conservez 90 jours. Si un éditeur ne peut pas exposer cela, il n’est pas prêt pour l’entreprise.
- Honeytokens & canaris. Plantez une chaîne secrète unique, non publique, dans un espace/dépôt exclu. Alertez si elle apparaît dans des réponses ou sort de votre réseau via les journaux d’egress.
- Exercices trimestriels du kill‑switch. Simulez une fuite : déclenchez une détection, coupez l’egress, révoquez les consentements IdP et demandez la mise en pause du crawler éditeur. Mesurez le MTTR pour le confinement (<15 minutes) et l’éradication complète (<24 heures).
Optionnel mais puissant : encapsuler les éditeurs derrière votre propre broker
Si votre taille le justifie, insérez un service broker devant les copilotes tiers :
- Wrapper OAuth. Les éditeurs s’authentifient sur votre broker, qui échange ensuite des tokens OBO de courte durée pour chaque source. Centralisez consentement, rotation et révocation.
- Policy as code. Encodez qui peut interroger quels connecteurs, à quel moment et depuis quels appareils. Refus par défaut ; journalisez toutes les décisions.
- Masquage en ligne et filigranage. Appliquez votre assainissement au centre et insérez des filigranes invisibles pour tracer les fuites.
Cela ajoute une à deux semaines d’implémentation mais se rembourse en contrôle et en auditabilité.
Ce qu’il faut exiger des éditeurs
N’acceptez pas « faites‑nous confiance, nous n’entraînons pas nos modèles sur vos données » comme posture de sécurité. Votre checklist RFP/renouvellement doit inclure :
- Prise en charge OBO et portée par connecteur. Aucun compte de service global.
- Résidence et rétention configurables (max 7–30 jours) pour embeddings, caches et journaux.
- Traces de récupération complètes par réponse (URIs, horodatages, identité utilisateur, version de modèle).
- Pause/reprise d’indexation via API et garanties de suppression définitive avec preuves.
- SOC 2 Type II dont le périmètre couvre explicitement la chaîne d’indexation et de récupération IA, pas seulement l’appli web.
- Durcissement contre l’injection de prompts sur les crawlers et filtres de récupération ; description des mesures de mitigation.
- SLA d’incident traitant toute récupération non autorisée comme un incident de sécurité avec obligations de notification.
Le plan kill‑switch d’exfiltration en 30‑60‑90 jours
Jours 0–30 : Geler, trouver et réduire le périmètre
- Décréter un gel temporaire des nouvelles installations de copilote/connecteur. Expliquez le pourquoi en interne.
- Mener à bien l’inventaire : egress DNS/proxy, octrois IdP, apps du marketplace. Classer en Niveaux 1–3.
- Supprimer les comptes de service avec lecture globale. Convertir en OBO ou réduire la portée à des groupes pilotes avec expiration à 14 jours.
- Activer la liste d’autorisation réseau pour les endpoints IA. Commencez par tout bloquer, n’autorisez que les 3–5 destinations de confiance explicite.
- Établir une denylist d’espaces/dépôts/drives à ne jamais indexer.
- Documenter la ligne de base de configuration éditeur : résidence, rétention, audit, contrôles de pause.
Jours 31–60 : Mettre des contrôles sur le chemin
- Déployer ou renforcer votre secure web gateway (Cloudflare Gateway, Zscaler, etc.) avec ancrage SNI/IP pour les domaines IA et copilotes. Implémenter des plafonds de débit/taille.
- Mettre en place un proxy de masquage devant vos sources les plus à risque (Confluence/Drive/Slack). Démarrer par un masquage déterministe des secrets/DCP (PII) ; ajouter un petit classifieur pour les paragraphes sensibles.
- Intégrer la journalisation des récupérations là où les éditeurs la supportent ; alimentez votre SIEM. Sinon, l’exiger contractuellement avant renouvellement.
- Déployer des honeytokens et canaris ; vérifier votre capacité de détection à l’egress.
- Négocier des avenants contractuels pour les limites de rétention, les traces de récupération et les SLA d’incident.
Jours 61–90 : S’exercer et automatiser
- Réaliser un exercice complet de kill‑switch : déclencher la détection, bloquer l’egress, révoquer les consentements, mettre en pause les crawlers éditeurs. Capturer le MTTR et les écarts.
- Automatiser le policy as code dans votre IdP et votre passerelle : groupes, expirations, allowlists, règles de refus et détection de dérive.
- Publier en interne un Standard de sécurité Copilot : niveaux, éditeurs approuvés, configurations requises, cadence de revue et playbook d’urgence.
- Mettre en place une revue trimestrielle des journaux de récupération pour détecter l’extension de périmètre et les installations shadow.
Les arbitrages à assumer
- Qualité des réponses vs. sécurité. Le masquage et les connecteurs à périmètre réduit rendront les réponses moins « magiques ». Votre objectif est la prédictibilité, pas la magie.
- Friction vs. shadow IT. Si vous serrez trop la vis, les équipes passeront par des comptes personnels. Combinez les contrôles avec une voie d’accès pour des pilotes approuvés.
- Verrouillage fournisseur vs. contrôle. Enrober les copilotes via votre broker apporte du contrôle mais complique les migrations. Gardez vos politiques et votre logique de masquage portables.
- Coût vs. visibilité. Journaliser les récupérations et opérer une passerelle n’est pas gratuit. Budgétez‑le comme une assurance cyber ; vous vous en féliciterez au premier déclenchement d’un canari.
Pourquoi maintenant, pas après le prochain gros titre
En 2026, les surcouches IA sont la voie la plus rapide de « interne » à « public ». La plupart des organisations découvrent qu’elles en ont une douzaine… après une fuite. L’infrastructure requise — scopes d’identité, listes d’autorisation d’egress, masquage pré‑index, journalisation des récupérations — est une technologie ennuyeuse mais éprouvée. Vous pouvez mettre en place l’essentiel du kill‑switch en 4 à 6 semaines avec une petite équipe senior. Nous avons constaté qu’un pod nearshore de 3 à 5 ingénieurs peut le livrer 20–30% moins cher que l’improvisation post‑incident avec des consultants et la pression du PR.
N’attendez pas que la prochaine histoire à la Rovo se joue dans votre tenant. Inventoriez, contenez et soyez capables de couper — à vos conditions.
Points clés
- Les copilotes cross‑SaaS effacent les frontières d’apps et de permissions ; traitez‑les par défaut comme des intégrations à haut risque.
- Bâtissez des contrôles en trois couches : plan des requêtes (tokens OBO, scopes JIT), plan des données (masquage pré‑index, listes de refus, limites de rétention) et réseau (listes d’autorisation d’egress).
- Exigez des traces de récupération, la prise en charge OBO et la configurabilité de la rétention de la part des éditeurs ; contractualisez‑le.
- Mettez en place un proxy de masquage déterministe pour les sources sensibles ; acceptez des réponses un peu moins brillantes pour bien plus de sécurité.
- Instrumentez les journaux de récupération, plantez des honeytokens et entraînez un kill‑switch à 15 minutes chaque trimestre.
- Une petite équipe senior peut livrer cela en 4 à 6 semaines ; c’est moins cher que gérer une fuite.