Sécurité et frontières des données

La version en langage clair de « où va mon code » et « qu'est-ce qu'ARDS garde ». Si vous utilisez ARDS sur un vrai dépôt, c'est la page à lire attentivement.

Votre code

  • Dépôt d'origine (le vôtre) : ARDS n'y pousse jamais sans votre clic explicite d'approbation. Il n'existe pas de mode « auto-merge » en v1.
  • Miroir de revue (chez nous) : quand vous connectez un dépôt, ARDS le clone sur un serveur Git interne. Les coders travaillent contre ce miroir. Les changements approuvés sont repoussés sur votre origine à votre place.
  • Conteneurs des coders : chaque coder travaille sur son propre clone du miroir, dans un conteneur du pool de votre tenant. Les conteneurs sont réutilisés d'une tâche à l'autre et retirés après quelques minutes d'inactivité — et rien de ce qu'un coder ne commite et ne pousse pas sur le miroir ne survit à la tâche.

Si vous supprimez votre tenant, tous les miroirs et l'historique de conversation partent avec. (Des sauvegardes sont conservées sur rotation pour restauration à court terme. Demandez au support si vous avez besoin des chiffres de rétention exacts.)

Vos clés d'API

  • Stockées dans notre coffre de secrets (HashiCorp Vault côté plateforme).
  • Injectées dans les conteneurs coder uniquement comme variables d'environnement au démarrage du conteneur.
  • Jamais écrites sur disque dans le conteneur.
  • Jamais loguées en clair.
  • Jamais envoyées à des fournisseurs autres que celui à qui la clé appartient.

Vous pouvez les révoquer à tout moment. Soit en les retirant de la page LLM Config (on arrête immédiatement de les utiliser), soit en les révoquant chez le fournisseur — ARDS fera remonter le rejet en erreur.

Vos conversations et missions

  • Stockées dans notre base de données (Postgres).
  • Visibles uniquement par votre tenant.
  • Utilisées en interne pour :
    • L'orchestration des missions (le modèle planificateur lit la conversation qu'il planifie).
    • L'historique recherchable dans le tableau de bord Intelligence (votre recherche à vous ; restreinte au tenant).
    • La comptabilité des coûts (compteurs de tokens par tâche).

Nous n'entraînons pas de modèles sur vos données. Nous n'avons pas de modèle à entraîner.

L'assistant d'aide intégré Demander à Genesis répond uniquement aux questions produit — il ne peut ni voir ni modifier les données de votre projet.

Isolation des tenants

  • Chaque testeur a son propre sous-domaine : <slug>.ards.etiakorp.com.
  • Chaque tenant a sa propre base Postgres (base séparée par tenant dans un cluster Postgres partagé).
  • Chaque tenant a son propre namespace Vault pour ses secrets.
  • Les conteneurs coder sont mutualisés par tenant ; le coder d'un tenant ne peut pas voir les données d'un autre.

Les composants partagés (cluster Postgres, serveur Vault, control plane K8s) sont conscients du tenant : chaque requête est filtrée par tenant ID au niveau ligne et base.

Et les secrets dans le code ?

Si votre dépôt contient des secrets en dur et que vous les poussez via le miroir de revue, les coders les verront. Ils n'en feront rien délibérément, mais ils restent visibles. Recommandation : ne faites pas confiance au miroir pour des secrets non masqués ; rotez toute clé qui aurait vécu dans l'historique du miroir si vous décidez de quitter ARDS.

Le domaine secret-scan du Review Engine attrape les fuites évidentes (clés AWS, JWT, etc.) et les remonte en findings — voir Review Engine.

Ce qu'on logue

  • Les transitions d'état des missions.
  • Les démarrages, fins, échecs de tâches, avec durées et compteurs de tokens anonymisés.
  • Les erreurs HTTP qui touchent le tableau de bord.
  • Les métriques plateforme côté opérateur (CPU, RAM, etc.).

Les logs ne contiennent pas les prompts ni les sorties de modèle. Ils contiennent ce qu'il faut pour déboguer « pourquoi cette mission a échoué » sans faire de capture du contenu de votre conversation.