Fuite de données chez Fireworks AI : comment limiter votre exposition aux fournisseurs d'IA tiers

Si vous faites appel à des fournisseurs d'IA, considérez chaque copie de vos données destinée à l'analyse, à l'évaluation, à la R&D ou aux sauvegardes comme une frontière de sécurité à part entière. Un chemin d'inférence bien protégé ne protège en rien les copies créées pour d'autres usages.

D'après ses bulletins de sécurité, Fireworks AI a subi deux intrusions en octobre 2026. La première a été rendue publique en octobre. La seconde, survenue les 23 et 24 octobre, n'a été divulguée que le 9 novembre.

Le 10 novembre, Notion a précisé dans son avis de sécurité qu'un jeu de données exposé contenait des transcriptions de conversations IA utilisées pour sa fonctionnalité d'analyse Insights. Selon Notion, moins de 1 % de ses espaces de travail sont concernés.

Pour la grande majorité des espaces touchés, Notion qualifie ces transcriptions de non attribuables : elles ne comportaient ni identifiant d'espace de travail, ni libellé utilisateur, ni résultat d'outil. Non attribuable ne veut pas dire sans danger, car le texte lui-même peut contenir des identifiants de connexion ou des données personnelles. Au 11 novembre 2026, les deux enquêtes étaient toujours en cours.

Ce guide explique comment inventorier les copies secondaires, conditionner le failover à vos politiques de données, isoler les routes et désactiver une fonctionnalité d'IA sans mettre tout votre produit à l'arrêt.

Chronologie de l'incident et périmètre confirmé

Selon Fireworks, l'intrusion du 24 octobre a exposé des métadonnées de ressources et des informations de facturation. Pour certains comptes, des secrets, des jeux de données et des poids de modèles incomplets ont aussi été exposés. Fireworks précise ne pas conserver de numéros de carte bancaire et qu'aucun n'a donc été touché.

Fireworks n'a détecté aucun impact sur ses services principaux Inference, Training SDK et Nexus. Son bulletin indique que l'incident fait l'objet d'une surveillance active. L'entreprise dit avoir mandaté Unit 42, l'équipe de Palo Alto Networks, pour l'investigation numérique, et avoir prévenu les autorités.

Les zones d'ombre

• Lien entre les incidents : aucune des communications publiques ne rattache les transcriptions de Notion à l'une ou l'autre des intrusions d'octobre.
• Auteur de l'attaque : on ignore publiquement si le même groupe est à l'origine des deux intrusions.
• Fournisseur cloud : Fireworks n'a pas nommé le fournisseur qui hébergeait ses machines de R&D.
• Contenu des prompts : on ne sait pas combien d'identifiants ni quelle quantité de données personnelles contenaient les transcriptions.
• Clients concernés : Fireworks n'a pas publié le nombre de clients touchés.

Le risque, c'est la copie, pas l'appel

Cartographiez vos données d'IA par finalité, et pas seulement par fournisseur. Un même prompt peut atterrir dans des systèmes qui n'ont ni les mêmes utilisateurs, ni les mêmes identifiants, ni les mêmes durées de conservation, ni les mêmes méthodes de suppression, ni les mêmes sous-traitants.

La zero data retention (ZDR, ou conservation nulle des données) est un engagement à ne pas conserver les données de requête et de réponse couvertes. Sa portée dépend de l'endpoint et de la finalité.

D'après la FAQ de Notion consacrée à l'incident, son engagement ZDR pour les entreprises couvre les requêtes envoyées aux fournisseurs de modèles tiers pour générer des réponses. Il ne couvre pas les fonctionnalités qui nécessitent de stocker requêtes et réponses, comme l'historique des conversations et Insights.

Notion indique avoir transmis ces requêtes et réponses stockées à Fireworks pour l'analyse Insights. Fireworks s'était engagé contractuellement à la ZDR pour cet usage, mais l'enquête de Notion a mis en évidence des données conservées à partir des endpoints utilisés. Notion explique auditer désormais ses fournisseurs critiques, notamment ses fournisseurs d'inférence et ses sous-traitants de données, pour vérifier leurs pratiques de minimisation et de ZDR.

Pour chaque fonctionnalité d'IA, demandez-vous donc quels traitements ultérieurs reçoivent le même contenu, pourquoi ils en ont besoin et comment chaque copie est supprimée. Notre article sur les risques de sécurité des routeurs LLM traite des défaillances et des abus de routage. La suite de ce guide porte sur les copies secondaires et le confinement.

Inventorier et contrôler chaque copie secondaire

Tenez un inventaire unique, partagé entre les équipes applicatives, sécurité, data et gestion des fournisseurs. Pour chaque copie, consignez les données concernées, la finalité, le lieu de stockage, la durée de conservation, les identifiants, les sous-traitants, la méthode de suppression et le responsable des preuves. S'il vous reste des usages d'IA non recensés, notre méthode pour passer du shadow AI à une IA gouvernée vous aidera d'abord à les identifier.

Lorsque les entrées sont structurées, appliquez des listes blanches au niveau des champs. Le masquage par expressions régulières ne permet pas de garantir qu'un prompt en texte libre ne contient ni secret ni donnée personnelle : limitez donc le nombre de traitements qui reçoivent du texte brut.

N'oubliez pas les sous-traitants de vos sous-traitants. Demandez à chaque fournisseur sa liste à jour de sous-traitants, ses conditions de notification des changements, ses délais contractuels de notification d'incident, ses engagements régionaux et ses preuves de suppression.

Lorsqu'une copie est supprimée, la personne chargée de la vérification dans l'inventaire doit documenter ce qui a été effacé et ce qui subsiste : sauvegardes, éléments conservés pour l'investigation, tables d'analyse dérivées et copies chez les sous-traitants.

Conditionner le failover à vos politiques de données

Un failover automatique peut élargir l'exposition s'il ne vérifie que la disponibilité. Une destination de secours doit aussi respecter la classe de données de la requête, sa région, ses exigences de conservation et la portée de ses identifiants.

Dans l'exemple suivant, la requête est refusée par défaut si aucune destination ne remplit toutes les conditions :

providers = [
    {"name": "primary", "classes": {"confidential"}, "regions": {"eu"},
     "retention": 0, "scopes": {"assistant"}, "available": False},
    {"name": "backup", "classes": {"public", "internal"}, "regions": {"us"},
     "retention": 30, "scopes": {"assistant"}, "available": True},
]

def choose(request):
    evaluations = []
    for provider in providers:
        reasons = []
        if not provider["available"]: reasons.append("unavailable")
        if request["data_class"] not in provider["classes"]: reasons.append("data_class")
        if request["region"] not in provider["regions"]: reasons.append("region")
        if provider["retention"] > request["max_retention"]: reasons.append("retention")
        if request["scope"] not in provider["scopes"]: reasons.append("credential_scope")
        if not reasons: return {"decision": "allow", "provider": provider["name"]}
        evaluations.append({"provider": provider["name"], "reasons": reasons})
    return {"decision": "deny", "evaluations": evaluations}

request = {"data_class": "confidential", "region": "eu",
           "max_retention": 0, "scope": "assistant"}
print(choose(request))

Ici, le fournisseur principal est indisponible. Le fournisseur de secours échoue aux contrôles de classe de données, de région et de conservation : la requête est donc refusée, avec les motifs en pièce jointe. Faites remonter ce refus plutôt que d'assouplir la politique sans le dire.

Restrictions régionales, identifiants à courte durée de vie, contrôle des flux sortants, paramètres de conservation : ces mécanismes n'existent que si le fournisseur les prend en charge. Vérifiez donc chaque destination avant de l'approuver. Multiplier les fournisseurs réduit le risque de dépendance, comme l'explique notre guide sur l'intérêt de ne pas dépendre d'un seul fournisseur d'IA, mais chaque nouvelle route exige la même gouvernance.

Isoler les routes, surveiller les accès et prévoir des kill switches

Séparez identifiants, projets et environnements par fonctionnalité et par route. Un job d'analyse ne doit pas réutiliser l'identité de l'inférence en production, et un environnement de R&D ne doit jamais détenir de clé donnant accès à une route de production.

Surveillez les identifiants de requête, les identifiants de locataires pseudonymisés, les choix de route, les destinations, le volume de tokens, l'utilisation des identifiants, les événements de suppression et les refus liés aux politiques. Excluez le contenu des requêtes de la télémétrie courante.

Selon Fireworks, les éléments recueillis rattachent l'activité à un groupe motivé par l'appât du gain, qui revend des accès volés à des LLM à des passerelles de routage illicites. Cette pratique porte le nom de LLMjacking. Pour repérer ce type d'abus sur vos propres clés, appliquez les méthodes de notre guide sur la détection d'usages anormaux des identifiants d'API LLM.

Prévoyez un kill switch par fonctionnalité d'IA ou d'analyse, et non un interrupteur unique pour tout le produit. Notion indique s'être déconnecté de Fireworks, avoir interrompu ses entraînements, désactivé Insights et cessé de servir des modèles open-weight via Fireworks, tandis que le reste du produit continuait de fonctionner.

Notion permet aussi aux propriétaires des espaces de travail concernés de télécharger le contenu exposé, avec des signalements des informations potentiellement sensibles, afin qu'ils puissent renouveler leurs identifiants. Anticipez cette étape : les personnes concernées ont besoin d'éléments exploitables, pas seulement d'une notification.

Ce que ces mesures ne couvrent pas

Ces mesures réduisent ce que contient chaque copie et accélèrent le confinement d'un incident. Elles n'auraient pas forcément empêché les incidents de Fireworks, et certains risques restent à votre charge :

• Administrateurs et personnel du fournisseur : un opérateur compromis ou malveillant peut accéder à toutes les données que votre politique autorise le fournisseur à détenir.
• Engagements inexacts : contrats et attestations peuvent se révéler faux. Notion disposait d'un engagement ZDR contractuel de Fireworks, et des données ont pourtant été conservées.
• Prompts en texte libre : les utilisateurs y collent des secrets et des données personnelles qu'aucun filtre ne détecte de façon fiable.
• Sauvegardes et copies d'investigation : elles peuvent survivre à la suppression dans les systèmes actifs, parfois à dessein.

La place d'Eden AI dans la chaîne de confiance

Une passerelle comme Eden AI se situe entre votre application et les fournisseurs de modèles en aval : c'est donc un système de plus à inscrire dans votre inventaire. Commencez par notre présentation de la passerelle IA, puis confrontez les options documentées, politiques de zero data retention et de région, fallback et clés API personnalisées, à vos propres exigences.

Quelle que soit la passerelle, documentez ce qu'elle reçoit, stocke, journalise et route, et soumettez-la aux mêmes contrôles que chaque fournisseur en aval. Une passerelle peut centraliser les décisions de politique, mais elle ne maîtrise pas ce qu'un fournisseur fait des données une fois reçues, et elle constitue elle-même une frontière de confiance privilégiée.

À vérifier cette semaine

À retenir

• Inventoriez les copies par finalité : traitez inférence, analyse, évaluation, R&D et sauvegardes comme autant de frontières distinctes.
• Minimisez les données stockées : appliquez des listes blanches aux champs structurés et restreignez l'accès aux prompts bruts.
• Isolez fonctionnalités et routes : utilisez des identifiants, des environnements et des kill switches distincts.
• Testez le confinement : mettez à l'épreuve le failover conditionné aux politiques, la vérification des suppressions et la coupure des fonctionnalités.

FAQ

Pour aller plus loin

• Bulletins de sécurité de Fireworks : les communications de référence sur les deux incidents d'octobre et les mesures de renforcement prises.
• Avis de sécurité de Notion : la chronologie de la réponse et la révocation des clés du 11 novembre.
• FAQ de Notion consacrée à l'incident : comment les propriétaires concernés peuvent examiner les données, et ce que couvre la ZDR de Notion.
• Sécurité des API LLM : détecter un usage anormal des identifiants : une surveillance concrète des clés volées ou détournées.
• Du shadow AI à une IA gouvernée en 30 jours : une démarche pour identifier et encadrer les usages d'IA non recensés.