Fuite OpenCode : bloquer les clés volées avec Synthorai Trusted IPs

Le 17 octobre 2026, OpenCode a informé ses utilisateurs qu’un intrus avait accédé à un ancien système de son service hébergé OpenCode Console. Les clés de fournisseurs tiers qui y étaient enregistrées « ont pu être exposées ». Des utilisateurs ont ensuite signalé des frais allant de quelques centaines de dollars à $1,700 sur leurs comptes OpenAI, Anthropic et Google. Une clé fournisseur est la clé API délivrée par OpenAI ou Anthropic. La confier à un outil hébergé pour qu’il appelle le fournisseur à votre place s’appelle le BYOK (bring your own key). Le coût d’une fuite dépend de deux facteurs : les adresses depuis lesquelles la clé peut être utilisée et le montant qu’elle peut dépenser avant d’être bloquée.

TL;DR

• Selon OpenCode, l’intrusion dans Console a touché 1.4% des utilisateurs de Console ; les clés stockées par le CLI OpenCode local n’ont pas été affectées.
• Les règles IP et les plafonds de dépenses d’une passerelle ne couvrent que le trafic qui la traverse. Une clé fournisseur exposée doit donc être protégée par un plafond strict chez le fournisseur.
• Quand l’option « Approbation des nouvelles IP » est activée, Synthorai refuse les appels d’une clé API provenant de toute adresse non approuvée pour cette clé, avec une réponse HTTP 403 et ip_not_trusted.
• Chaque clé Synthorai peut avoir un plafond de dépenses, des limites de requêtes et de tokens par minute, ainsi qu’une date d’expiration.

Que s’est-il passé lors de l’intrusion dans OpenCode Console ?

Un tiers non autorisé a accédé à « un ancien système que nous étions en train de mettre hors service », selon l’e-mail envoyé par OpenCode aux utilisateurs concernés. Les clés fournisseur enregistrées dans leurs espaces de travail Console ont pu être consultées. OpenCode situe le début possible de l’exposition au 17 octobre à 00:30 UTC. Voici la chronologie établie à partir des publications d’OpenCode, de celles des équipes des fournisseurs et de la presse :

Une attaque de distillation consiste à collecter en masse les réponses d’un modèle pour en entraîner un autre. Les clés volées sont l’un des moyens utilisés pour financer ces appels. OpenCode n’a pas expliqué le lien entre l’intrusion et la distillation. Le cofondateur Dax Raad a déclaré que l’intrusion concernait « OpenCode Console, pas OpenCode lui-même », et que les clés ajoutées dans le CLI local n’étaient jamais transmises à l’entreprise. Au 21 octobre, OpenCode n’avait publié ni cause racine, ni précision sur le chiffrement des clés stockées, ni nombre de comptes correspondant aux 1.4%, ni politique de remboursement, ni post-mortem (The Hacker News, BleepingComputer).

Quelles clés ont été exposées, et quelles protections sont utiles ?

Les clés exposées étaient des clés fournisseur. Une clé fournisseur volée s’utilise directement auprès du fournisseur, sans passer par l’outil qui la stockait. Cela limite ce qu’une passerelle LLM peut faire. Une passerelle est un service placé entre votre code et les fournisseurs de modèles, qui leur transmet vos requêtes. Elle ne voit et ne peut limiter que le trafic qui passe par elle. Il faut donc distinguer deux types de clés :

Les deux sections suivantes, sur les IP de confiance et les plafonds de dépenses, concernent la première ligne. Pour la seconde, le plafond strict défini chez OpenAI, Anthropic ou Google constitue le dernier rempart ; la section qui suit présente ces réglages.

Comment Synthorai protège-t-il les clés de la plateforme et les clés BYOK ?

Les clés fournisseur ajoutées au coffre BYOK sont chiffrées au repos avec AES-256-GCM, un algorithme standard de chiffrement authentifié. Une fois enregistrées, aucune API, aucun outil MCP et aucune page de la console ne permet de les récupérer : la console n’affiche que leurs quatre derniers caractères. La passerelle ne déchiffre une clé qu’en mémoire, pour la requête qui l’utilise. Seul le propriétaire de l’espace de travail peut en ajouter, les renouveler ou les supprimer. Les clés fournisseur utilisées par Synthorai pour sa propre capacité sont stockées de la même manière. Aucune page ni API ne les affiche, y compris dans la console d’administration. Le chiffrement protège les copies de la base de données ; une compromission du service en cours d’exécution peut toujours donner accès aux clés pendant leur utilisation. Le plafond côté fournisseur décrit plus bas reste donc le dernier rempart pour les clés BYOK.

Les clés API que Synthorai vous délivre sont uniquement stockées sous forme de hash, une empreinte à sens unique qui ne permet pas de retrouver la clé. La clé complète n’est affichée qu’une fois, à sa création. Toute lecture ultérieure, depuis la console, l’API de gestion ou le serveur MCP, ne renvoie que son préfixe. Une clé d’inférence peut uniquement appeler des modèles : l’API de gestion la refuse. Une clé d’inférence volée ne permet donc pas de lire les logs, les données d’utilisation ou les autres clés (API keys, admin keys).

Comment les IP de confiance bloquent-elles une clé volée ?

Les IP de confiance bloquent les appels d’une clé API depuis toute adresse non approuvée pour cette clé. Une clé copiée dans un log CI ou sur un ordinateur portable renvoie donc une erreur au lieu d’une réponse si quelqu’un l’utilise ailleurs. Un propriétaire ou un administrateur active cette protection dans Settings › Security avec l’option « Approbation des nouvelles IP ». La boîte de dialogue liste les adresses utilisées par chaque clé au cours des sept derniers jours, toutes présélectionnées pour approbation. Vérifiez cette liste avant de confirmer et décochez les adresses inconnues : si une clé a déjà été volée et utilisée, l’adresse de l’attaquant y figure aussi.

Ensuite, tout appel depuis une nouvelle adresse renvoie HTTP 403 (l’adresse ci-dessous est réservée aux exemples de documentation) :

{
  "error": {
    "type": "permission_error",
    "code": "ip_not_trusted",
    "ip": "203.0.113.9",
    "message": "Requests from IP address 203.0.113.9 are held until this address is approved for the key. ...",
    "approve_url": "https://synthorai.io/console/settings?tab=security"
  }
}

Le créateur de la clé reçoit un e-mail indiquant l’adresse, sa localisation, le client et le modèle demandé. L’approbation se fait dans la console après connexion : transférer l’e-mail n’approuve donc rien. L’approbation peut porter sur une adresse ou sur sa plage /24 (256 adresses IPv4 voisines) pour un client dont l’adresse change. La passerelle lit l’adresse de l’appelant sur la connexion telle que ses propres proxies la voient. Un client ne peut donc pas usurper une autre adresse en envoyant son propre en-tête X-Forwarded-For, celui qu’utilisent les proxies pour transmettre l’adresse d’origine du client. Nous l’avons vérifié avec un en-tête falsifié : le refus indiquait toujours l’adresse réelle.

# From an address not yet approved for the key, with a forged header:
curl -s https://synthorai.io/v1/models \
  -H "Authorization: Bearer $SYNTHORAI_API_KEY" \
  -H "X-Forwarded-For: 203.0.113.9"
# The 403's "ip" field is the caller's real address, not 203.0.113.9.

Il est aussi possible de créer une clé avec une liste fixe ip_allowlist. Cette liste fait toutefois partie des paramètres de la clé : chaque nouveau bureau, serveur ou point de sortie VPN impose de la modifier, et toute entrée oubliée reste autorisée. Les IP de confiance partent des adresses déjà utilisées par la clé et demandent une approbation pour chaque nouvelle adresse. Elles regroupent les adresses de toutes les clés dans une liste où une adresse connue s’approuve en un clic. Si une clé possède sa propre liste d’adresses autorisées, seule cette liste s’applique : choisissez l’un ou l’autre mécanisme pour chaque clé.

La confiance est propre à chaque clé. Les fonctions serverless et les runners CI qui utilisent une nouvelle adresse à chaque exécution seraient bloqués à chaque fois. N’approuvez pas les plages publiées par un fournisseur de CI hébergée : tous ses clients les partagent, et n’importe qui y exécutant un job passerait le contrôle. Faites passer ces appels par une adresse de sortie fixe, par exemple avec un runner auto-hébergé ou une passerelle NAT, puis approuvez cette adresse. Autre option : leur donner une clé de courte durée avec un plafond bas.

Comment les plafonds de dépenses limitent-ils le coût d’une clé volée ?

Chaque clé API Synthorai peut avoir son propre plafond de dépenses. Si elle est malgré tout exposée, elle s’arrête au montant choisi. La console permet de définir le plafond, les modèles autorisés et l’expiration à la création :

Les limites de débit par clé et les autres paramètres ci-dessous se règlent via l’API de gestion :

Voici une clé dédiée à un service, limitée à ses besoins et créée avec une clé d’administration (une clé de gestion qui peut créer et limiter des clés, mais pas appeler de modèles) :

curl https://synthorai.io/api/v1/keys \
  -H "Authorization: Bearer sk-syn-admin-..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "support-bot prod",
    "limit_usd": 50,
    "limit_reset": "daily",
    "rate_limit": {"rpm": 60, "tpm": 200000},
    "allowed_models": ["claude-haiku-5-5"],
    "expires_at": "2027-01-31T00:00:00Z"
  }'

Les propriétaires d’espaces de travail peuvent aussi définir un plafond quotidien et un plafond mensuel par membre. Un membre qui atteint son plafond mensuel reçoit HTTP 402 jusqu’au mois suivant. Ces limites s’appliquent au trafic passant par Synthorai. Si les appels BYOK sont comptabilisés, elles couvrent aussi les requêtes BYOK effectuées via la passerelle, mais pas l’utilisation directe d’une clé fournisseur volée.

Qu’est-ce que ces protections ne bloquent pas ?

Les IP de confiance bloquent l’utilisation d’une clé depuis une nouvelle adresse, mais pas depuis une machine approuvée. Or les vols les plus courants se produisent précisément là : malware sur le portable d’un développeur, job CI compromis ou serveur manipulé pour envoyer des requêtes au profit d’un attaquant. Dans ces cas, ce sont le plafond de dépenses, la liste des modèles et une expiration courte qui limitent les dégâts.

L’approbation reste une décision humaine. Un attaquant peut déclencher une requête bloquée en espérant qu’elle sera approuvée par habitude. La page d’approbation affiche l’adresse, sa localisation, le client et le modèle. N’approuvez que si ces informations correspondent à un appel que vous avez effectué.

Un plafond réinitialisé chaque jour permet à une clé volée de dépenser ce montant quotidiennement jusqu’à ce que quelqu’un s’en aperçoive. Associez les plafonds à des moyens de détection : l’e-mail envoyé pour chaque adresse bloquée, les dépenses par clé dans la console et le journal d’audit des modifications de clés. Si une clé a pu être exposée, supprimez-la dans la console et créez-en une nouvelle. Pour repérer les clés avant une fuite, ajoutez à votre hébergeur de code une règle de détection des secrets pour le préfixe sk-syn-, par exemple un motif personnalisé GitHub avec protection des push.

Que faut-il configurer chez le fournisseur pour une clé BYOK ?

Attribuez à chaque outil une clé fournisseur distincte, dans son propre projet ou espace de travail, avec un plafond de dépenses strict. Une clé volée ne pourra ainsi dépenser que le budget de ce projet. Révoquez toute clé exposée dans le tableau de bord du fournisseur : la supprimer de l’outil qui la stockait ne la révoque pas. Aucun des trois fournisseurs ne définit de plafond par clé ; la plus petite unité est le projet ou l’espace de travail :

Les alertes de dépenses et les budgets qui se contentent d’envoyer un e-mail n’arrêtent pas une attaque en cours. Ils restent utiles comme second signal, en complément d’un plafond strict. Dans la console Synthorai, la page BYOK propose sous les clés des liens vers les paramètres de plafonnement de chaque fournisseur :

Peut-on utiliser OpenCode avec Synthorai ?

Oui. Les clés utilisées par le CLI OpenCode local restent sur votre machine, une configuration qui n’a pas été touchée par l’intrusion. opencode auth login https://synthorai.io connecte OpenCode via le navigateur avec un code à usage unique. OpenCode reçoit alors sa propre clé API, valable 7, 30 ou 90 jours (guide de configuration). Si « Approbation des nouvelles IP » est activé et que vous autorisez la connexion depuis le même réseau, l’adresse utilisée pour la connexion est automatiquement approuvée pour cette clé. Les appels depuis toute autre adresse attendent une approbation. Si la demande de connexion provient d’un autre réseau que celui de votre navigateur, la page de confirmation vous avertit et l’adresse ne devient fiable qu’après approbation de son premier appel. Si vous n’avez pas exécuté la commande vous-même, annulez la demande.

La clé apparaît sous le nom « OpenCode » sur la page des clés API. Vous pouvez y ajouter un plafond de dépenses ou la supprimer. Une clé stockée sur un portable reste exposée aux malwares présents sur cette machine. Choisissez donc une durée de 7 ou 30 jours et laissez « Approbation des nouvelles IP » activé : une copie de la clé sera inutilisable depuis toute autre adresse et expirera rapidement.

FAQ

Les clés stockées dans le CLI OpenCode ont-elles été exposées lors de l’intrusion ?

Non. Selon OpenCode, l’intrusion se limitait à OpenCode Console. Les clés ajoutées dans le CLI local ou l’application de bureau sont stockées sur la machine de l’utilisateur et ne sont jamais envoyées à OpenCode.

Supprimer une clé fournisseur d’un outil hébergé la révoque-t-il ?

Non. Supprimer une clé d’un outil ne supprime que la copie de cet outil. La clé reste utilisable chez le fournisseur tant que vous ne l’avez pas révoquée dans son tableau de bord et remplacée par une nouvelle.

Le plafond de dépenses d’une passerelle protège-t-il une clé fournisseur exposée ?

Non. Les plafonds d’une passerelle ne comptabilisent que les requêtes qui la traversent. Une clé fournisseur volée étant utilisée directement auprès du fournisseur, c’est le plafond de ce dernier qui s’applique.

À lire aussi : IP de confiance, coffre BYOK, clés d’administration et limites des clés, configuration d’OpenCode.

Sources consultées le 21 octobre 2026 : publications et e-mails d’OpenCode cités dans la presse, publications des équipes des fournisseurs et documentation des fournisseurs accessible via les liens ci-dessus. Le test avec un en-tête falsifié a été effectué sur la passerelle de production Synthorai le 21 octobre 2026.

← Retour au blog