Ox Alpha : un modèle anonyme dans vos agents de code — verrouiller les routes LLM avant la fin du preview gratuit

Pendant une semaine, des dizaines de milliers de développeurs ont envoyé leur code source à un fournisseur dont personne ne connaît le nom. Ce n’est pas un scénario d’exercice de red team : c’est ce qui s’est passé entre le 20 et le 27 août 2026 avec le modèle stealth/ox-alpha. La fin de la fenêtre gratuite est le bon moment pour regarder ce que cet épisode dit de nos chaînes d’outillage agentiques — et pour verrouiller ce qui doit l’être.

Ce qui s’est passé, factuellement

La chronologie est courte et dense.

• 20 août 2026 : stealth/ox-alpha apparaît sur OpenRouter. OpenCode l’annonce le même jour, gratuit « pour une semaine ».
• 21 août : la disponibilité est étendue à OpenCode Go, avec un identifiant de route distinct de celui de Zen.
• 22 août : les premières analyses communautaires côté serving circulent — une trace d’exception Java remontée dans une réponse d’erreur, un code d’erreur 1214, des correspondances de tokenizer. La piste évoquée est celle d’un dérivé GLM de Zhipu / Z.ai. Aucune confirmation officielle n’a été publiée.
• Autour du 27 août : fin annoncée de la fenêtre gratuite.

Les caractéristiques annoncées et vérifiables sur les fiches de route sont les suivantes : fenêtre de contexte de 1 048 576 tokens, sortie maximale d’environ 131 072 tokens, entrées texte, image et vidéo, API compatible Chat Completions, et une tarification à 0 $ / 0 $ par million de tokens pendant le preview. OpenCode a par ailleurs communiqué sur une capacité de l’ordre de « 100 000 milliards de tokens par jour » — chiffre repris avec des ordres de grandeur variables selon les sources, ce qui suffit à le classer dans la catégorie « communication », pas dans celle des engagements de service.

Ce qui n’est, en revanche, pas vérifiable : l’éditeur, l’architecture, le corpus d’entraînement, la juridiction de traitement, le prix après le preview, et la capacité réelle.

L’adoption, elle, a été immédiate : le modèle s’est classé n°3 en volume sur OpenCode sur sa première semaine, avec environ 7 100 milliards de tokens consommés et ~134 000 utilisateurs uniques. Autrement dit, l’adoption a très largement précédé l’analyse. Des équipes entières ont poussé du code propriétaire dans une route dont elles ne pouvaient pas nommer le destinataire.

Le vrai sujet : trois routes, trois politiques de données

Le même modèle, atteint par trois chemins différents, n’est pas encadré par les mêmes règles.

C’est là que beaucoup d’équipes se trompent de lecture. Une mention favorable sur une fiche modèle ne prime pas mécaniquement sur des conditions générales de programme. Une fiche modèle est de la documentation produit ; les CGU sont l’instrument contractuel. En l’absence de clause explicite de préséance, la règle opérationnelle raisonnable est simple : appliquer la borne la plus stricte du faisceau contractuel, c’est-à-dire, ici, considérer que le contenu envoyé via la route Stealth d’OpenRouter est susceptible d’être sous-licencié pour entraînement.

Le seul garde-fou de pseudonymisation généralement mis en avant est l’identifiant utilisateur haché transmis au fournisseur. Il protège contre la corrélation directe avec un compte. Il ne protège strictement rien quand le prompt lui-même contient le code, les chemins de fichiers, les noms de domaine internes, les schémas de base, les identifiants de clients — et, dans les cas les moins heureux, des secrets non révoqués. Un hash d’identité n’anonymise pas un payload qui décrit votre système d’information.

Enfin, ce n’est pas un incident isolé. Les modèles stealth antérieurs — GLM-5, MiMo-V2-Pro sous les noms Hunter Alpha / Healer Alpha, Ling-2.6-flash, LongCat-2.0 — ont tous été revendiqués après la fermeture de leur fenêtre de preview. L’anonymat n’est pas un accident de mise en production : c’est une pratique marketing normalisée, qui échange du volume de test gratuit contre de la donnée d’usage réelle.

L’angle RGPD, en clair pour une équipe technique

Deux articles suffisent à cadrer le problème.

Article 28. Le recours à un sous-traitant suppose un contrat écrit qui l’identifie et fixe l’objet, la durée et la nature du traitement. On ne peut pas conclure un accord de sous-traitance avec une entité qu’on ne peut pas nommer. Un « fournisseur anonyme derrière une passerelle » n’est pas un sous-traitant documentable ; c’est un trou dans la chaîne.

Chapitre V. Sans fournisseur identifié, aucun transfert hors UE n’est documentable : ni clauses contractuelles types, ni analyse d’impact du transfert, ni évaluation de la législation locale. La piste Zhipu / Z.ai, non confirmée, illustre précisément l’ampleur du problème : selon la juridiction réelle, l’exercice de conformité va de « formalité » à « impossible ».

La conséquence pratique est celle que les équipes techniques ont le plus tendance à sous-estimer : un preview gratuit branché dans un agent de code est un traitement de données, pas une expérimentation de laboratoire. Deux questions valent audit immédiat : qui, dans votre organisation, a autorité pour ajouter une route de modèle ? Et où en est la trace écrite ?

Runbook : reprendre le contrôle des routes de modèles

1. Inventorier

Cherchez les points d’entrée, pas les intentions.

# Configurations d'agents versionnées ou locales
fd -H -t f 'opencode.json|opencode.jsonc|\.cursorrules|settings\.json' ~ /srv/repos

# Modèles référencés en dur dans les dépôts et la CI
rg -n --hidden -g '!node_modules' \
  -e 'stealth/' -e 'ox-alpha' -e 'openrouter' \
  -e 'OPENROUTER_API_KEY' -e 'OPENROUTER_BASE_URL'

# Variables d'environnement en cours d'usage sur les runners
env | rg -i 'OPENROUTER|OPENCODE|ANTHROPIC_BASE_URL|OPENAI_BASE_URL'

Ajoutez à l’inventaire les clés API partagées : une clé unique par équipe rend impossible toute imputation.

2. Se méfier des alias mouvants

Les identifiants de route ont changé pendant le preview (Zen puis Go). Ne codez jamais en dur un ID récupéré d’une capture d’écran ou d’un thread. Passez par un alias interne résolu au niveau de la passerelle :

{
  "model": "corp/agent-default",
  "providers": {
    "corp": {
      "baseURL": "https://llm-gw.interne.example/v1",
      "apiKey": "{env:CORP_LLM_TOKEN}"
    }
  }
}

Le poste de travail ne connaît qu’un nom logique. La cartographie vers un modèle réel reste une décision centralisée, révocable en une modification de configuration.

3. Liste blanche à la passerelle, pas sur les postes

Le contrôle doit être deny by default, avec refus explicite de tout préfixe stealth.

# llm-gateway/policy.yaml
default_action: deny
deny_patterns:
  - "stealth/*"
  - "*-alpha"
  - "*-preview"
allow:
  - id: corp/agent-default
    upstream: <fournisseur nommé, DPA signée>
    max_output_tokens: 32768
  - id: corp/agent-longctx
    upstream: <fournisseur nommé, DPA signée>
audit:
  log_fields: [subject, route, repo, request_id, bytes_in, bytes_out]
  retention_days: 90

4. Egress et journalisation

Sans contrôle d’egress, la liste blanche est décorative : un développeur peut appeler openrouter.ai directement. Restreignez les sorties HTTPS des postes et des runners vers le proxy LLM d’entreprise, et journalisez le triplet (utilisateur, route, dépôt). C’est la seule façon de répondre, sous une semaine, à la question « qu’est-ce qui est parti, et où ? ».

5. Hygiène du prompt

Le scan de secrets au commit arrive trop tard : l’agent lit le worktree, pas l’index. Faites le scan avant l’envoi, côté proxy ou hook d’agent.

#!/usr/bin/env bash
# pre-prompt-guard.sh — refuse l'envoi si des secrets sont détectés
set -euo pipefail
payload="$1"

if rg -q -e 'AKIA[0-9A-Z]{16}' -e 'sk-[A-Za-z0-9]{20,}' \
      -e 'BEGIN (RSA|EC|OPENSSH) PRIVATE KEY' "$payload"; then
  echo "Secret détecté dans le contexte : envoi bloqué." >&2
  exit 1
fi

# Exclusions dures, indépendamment du .gitignore
rg -q -e '(^|/)\.env' -e '\.pem$' -e '\.kubeconfig$' -e '\.sql\.gz$' "$payload" \
  && { echo "Fichier sensible dans le contexte." >&2; exit 1; }

Complétez par une redaction systématique des identifiants clients et des noms de domaine internes.

Comment évaluer un modèle stealth sans exposer votre code

Rien n’oblige à renoncer à tester ces modèles — ils sont souvent techniquement intéressants. Il faut simplement séparer l’évaluation de la production.

Bac à sable strict : dépôt jetable, données synthétiques, branche isolée, aucune connexion aux serveurs MCP internes, aucun accès aux secrets de CI. Un agent branché sur vos MCP internes est un exfiltrateur potentiel bien plus efficace qu’un copier-coller.

Grille de décision en six questions, à répondre par oui/non avant tout usage sur du code propriétaire :

1. Le fournisseur est-il nommé ?
2. Une DPA est-elle signable avec cette entité ?
3. La rétention est-elle bornée contractuellement, et non seulement affichée ?
4. Le prix post-preview est-il publié ?
5. La disponibilité fait-elle l’objet d’un engagement ?
6. La route est-elle réversible sans modification de code applicatif ?

Un seul « non » sur les questions 1 à 3 suffit à cantonner le modèle au bac à sable.

Prévoir la disparition. Un modèle stealth peut s’éteindre du jour au lendemain, sans dépréciation ni préavis. Une route de repli et un test de bascule automatisé sont obligatoires :

{
  "model": "corp/agent-default",
  "fallbacks": ["corp/agent-longctx", "corp/agent-local"],
  "on_error": { "retry": 1, "then": "fallback" }
}

Coût. « Gratuit » n’est pas un palier tarifaire, c’est une subvention de preview. Toute évaluation économique fondée sur 0 $/million de tokens est nulle et non avenue : rattachez le sujet à votre suivi réel du coût au token, avec l’hypothèse d’un tarif de marché à la sortie du preview.

À retenir

La fermeture de la fenêtre, autour du 27 août, doit déclencher trois actions concrètes : audit des logs de passerelle sur la période du 20 au 27 août pour identifier les dépôts concernés, rotation des clés API partagées qui ont pu transiter dans des contextes envoyés, et note écrite au DPO si du code propriétaire ou des données personnelles sont partis vers une route Stealth. Cette note ne coûte presque rien à écrire aujourd’hui et vaut beaucoup si la question remonte dans six mois.

La leçon dépasse ox-alpha, qui sera identifié, renommé et intégré comme les précédents. Dans une chaîne d’outillage agentique, le choix du modèle n’est plus une préférence de développeur : c’est une décision de sécurité et de conformité, prise à l’échelle d’une organisation, avec une trace. Le jour où un fournisseur anonyme peut entrer dans votre boucle de développement par une simple ligne de configuration locale, ce n’est pas le modèle qui est en cause — c’est l’absence de point de contrôle.