Tu n’as pas besoin d’être expert en sécurité pour construire avec Highwind : les bonnes pratiques sont appliquées
d’office, pendant la construction comme à la publication. Cette page explique concrètement ce que fait Highwind pour
protéger ton compte, tes clés, tes apps et les données de leurs utilisateurs.
Un environnement par projet. Chaque projet tourne dans son propre bac à sable (sandbox), séparé des autres
projets et des autres comptes. Ce qui s’exécute dans l’aperçu d’un projet ne peut pas atteindre un autre projet.
Un agent aux outils limités. L’agent n’a qu’un petit nombre d’outils (lire et écrire des fichiers du projet,
vérifier le build, demander une clé…). Il n’a jamais accès à tes secrets ni aux clés de la plateforme : les fichiers
où sont rangées les clés de l’aperçu lui sont cachés et ne sont pas enregistrés dans les versions.
Une construction à la fois. Un compte ne lance qu’une demande à la fois, avec des limites d’usage (messages,
projets, publications) et un plafond de dépense global qui suspend la génération en cas d’emballement.
Les clés d’API que tu ajoutes (dans une carte du chat, sur la page Connecteurs ou dans les secrets d’un projet) sont
protégées à chaque étape :
Protection
Ce que ça veut dire
Chiffrées
Les valeurs sont chiffrées en base (AES-256-GCM) et ne sont jamais renvoyées par l’API de Highwind.
Jamais réaffichées
Une fois enregistrée, une clé secrète n’est plus visible dans l’interface : pour la changer, tu la remplaces.
Jamais montrées à l’agent
L’agent sait seulement si une clé est présente. Il ne voit ni ne recopie sa valeur.
Côté serveur seulement
Seul le serveur de ton app (routes /api) lit les clés. Elles ne sont jamais envoyées au navigateur des visiteurs.
Limitées au projet
Une clé ne sert que dans les projets auxquels tu la relies.
Testées sans effet de bord
La vérification d’une clé n’envoie aucun e-mail et ne crée aucun paiement.
Seules les valeurs explicitement publiques (un identifiant de mesure, un jeton public restreint à ton domaine)
sont affichées en clair et peuvent être écrites dans le code du navigateur. Voir
Connecteurs et Secrets de l’app.
Accès sur invitation. Pendant la bêta privée, seules les adresses invitées peuvent utiliser Highwind. Un compte
qui abuse du service peut être suspendu.
Google Sheets : Highwind ne demande à Google que la permission drive.file, limitée aux feuilles qu’il crée pour
tes apps. L’app passe par la passerelle Highwind : tes jetons Google ne quittent jamais Highwind. Par défaut, l’app
peut seulement ajouter des lignes, pas les relire. Voir Google Sheets.
Sources de contexte en lecture seule. Notion, Linear et Figma sont connectés en lecture seule : seuls les outils
de lecture sont donnés à l’agent. Kameleoon est en lecture seule par défaut ; les modifications demandent ton
autorisation explicite, et sont toujours refusées en mode Discussion. Ce que l’agent lit dans une source est traité
comme une information, jamais comme un ordre. Voir Sources de contexte.
Avant qu’une app soit accessible sur Internet, Highwind la vérifie :
Recherche de failles dans la base. Si l’app a un backend, sa base de données est analysée. Une faille critique
(par exemple une table lisible et modifiable par tous) bloque la publication (« Publication bloquée ») ; les
points moins graves s’affichent comme Points de sécurité à vérifier. Le bouton Corriger avec l’agent lui
demande de les corriger.
Détection d’hameçonnage. Le code et les textes de l’app sont examinés pour repérer les pages qui imitent une
banque, une administration ou un service connu afin de voler des identifiants ou des paiements. Une app jugée
dangereuse n’est pas publiée, et l’équipe Highwind est prévenue.
Un lien « Signaler » sur chaque app. Chaque app publiée affiche un petit badge « Made with Highwind » avec un
bouton de signalement, ouvert à tous ses visiteurs. Voir Utilisation acceptable.
Quand ton app a un backend, ses données sont protégées par défaut :
Règles d’accès obligatoires (row level security). Chaque table a des règles d’accès : un utilisateur ne voit et
ne modifie que ses propres données. Une table créée sans règles est refusée.
Aucune suppression accidentelle. L’agent ne peut pas supprimer, vider ni renommer une table ou une colonne
existante.
Mots de passe solides : 8 caractères au minimum pour les comptes des utilisateurs de tes apps.
Une base par app, hébergée à Paris, et un dossier par utilisateur pour les fichiers.