Voyez les limites actuelles d'accès, d'isolation, de journalisation et d'exploitation, sans allégation de conformité non vérifiée.
Dernière mise à jour : 17 juillet 2026
Posture de sécurité
BizPilot traite les demandes publiques comme une surface sensible. Le flux garde l'accès limité, les secrets hors du code et les messages finaux sous le contrôle de l'entreprise.
Les pages de soumission publiques valident le lien actif, le formulaire attendu, le consentement, les champs cachés, le temps de soumission et les signaux d'abus avant d'accepter une soumission synthétique ou pilote.
Le smoke authentifié du tableau de bord reste local seulement parce qu'il crée des utilisateurs, entreprises, prospects et métadonnées de source synthétiques. Il doit bloquer les projets Supabase gérés/non locaux et les URLs de production.
L'accès aux données d'entreprise passe par l'authentification, l'adhésion, l'état du cycle de vie et la sécurité RLS de la base de données. Les helpers de rôle service doivent rester côté serveur.
L'IA aide seulement à préparer un brouillon. BizPilot ne doit pas envoyer automatiquement, inventer des prix, confirmer des réservations ou agir comme opérateur caché.
Les secrets doivent rester dans les environnements fournisseurs, jamais dans le code, les journaux, captures, docs ou commits. Les clés manquantes doivent échouer proprement ou utiliser une solution de repli documentée.
La preuve d'export et de restauration est enregistrée pour la cible synthétique. La preuve stricte de l'application restaurée, du tableau de bord et de la sécurité RLS reste différée à P1 avant un pilote payant, des migrations de production, un nettoyage destructif ou un travail à plus grande échelle.
Référence