Ce que nous pouvons prouver aujourd'hui
Écrit de manière vérifiable : un document à lire, un en-tête à inspecter, un comportement à tester.
Des documents juridiques versionnés
Ils sont six, par langue : conditions, confidentialité, cookies, usage responsable, avenant de traitement des données et contrat commercial. Chacun porte la date de sa dernière modification.
RGPD et LGPD en pratique
Consentement aux cookies avant tout script non essentiel, avenant de traitement pour qui en a besoin, et un canal publié pour une demande de personne concernée.
Durci après un vrai test d'intrusion
La plateforme a subi un test d'intrusion et les constats ont été corrigés, pas classés. Les règles de bordure, l'origine directe fermée et la politique de stockage viennent de ce tour.
Ce que nous n'avons pas encore
Dit clairement, parce qu'une page sécurité qui ne liste que des forces est celle en laquelle personne ne devrait croire. Si l'un de ces points est une exigence pour vous, parlez-nous-en avant de construire sur la plateforme.
- SOC 2 Type II et ISO 27001. Nous ne sommes pas certifiés et nous n'avons pas de rapport à vous envoyer.
- Résidence des données par région. Tout tourne aujourd'hui dans une seule région ; vous ne choisissez pas où vivent les données de votre application.
- Un programme de primes aux bugs. Les signalements sont bienvenus et traités, mais aucune récompense n'est prévue.
Ce qui protège les données dans votre application
Les utilisateurs de votre application ne sont pas nos utilisateurs, et leurs données ne nous regardent pas. Voici les mécanismes qui tiennent cette ligne.
Données séparées par compte
Les données de chaque projet sont isolées par tenant, et l'accès à chaque enregistrement est décidé par les règles de l'application elle-même — public, authentifié, par rôle ou par propriété.
Les données de carte ne passent pas par votre application
Les paiements passent par Stripe, Pagar.me et Mercado Pago. Les champs de carte sont rendus par un composant-coffre hébergé ; le numéro de carte ne traverse pas le code écrit par l'IA.
Les builds tournent isolés
Le build d'une application tourne dans un conteneur éphémère, sans l'environnement de l'hôte, avec des capacités retirées et des limites de CPU, de mémoire et de temps. Les secrets restent dehors — le bac à sable n'en voit jamais un.
Des fichiers servis prudemment
Les types de documents actifs sont forcés en privé et livrés via une URL signée de courte durée ; une vidéo n'est jamais un lien public.
Un secret est gardé, pas copié
Les identifiants d'intégration vivent dans des lignes chiffrées de notre côté et sont injectés au moment de l'appel. Transformer une application en modèle n'emporte jamais un secret.
Protection en bordure
Les applications publiées et la plateforme sont derrière Cloudflare, avec HTTPS, limitation de débit et protection anti-bots devant.
Ce qui protège la plateforme autour
La partie que vous ne voyez jamais, et celle qui décide si une application générée par une IA peut être publiée sans crainte.
Une analyse qui peut bloquer la publication
Avant la mise en ligne, le code généré est vérifié contre un secret écrit dedans et contre une règle d'accès qui laisserait une table ouverte. La publication s'arrête plutôt que d'expédier l'un ou l'autre.
Le conteneur de build ne détient aucun secret
Chaque application est construite dans un conteneur qui naît et meurt, avec des capacités retirées, sans l'environnement de la machine et sans aucune clé de la plateforme à l'intérieur. La seule chose qui en sort est le dossier compilé.
L'origine directe est fermée
La plateforme ne répond que par Cloudflare, avec un pare-feu applicatif et une limitation de débit devant. L'adresse du service sous-jacent renvoie 404 à qui la trouve.
Identifiants chiffrés, jamais renvoyés
Les identifiants d'intégration et de store sont chiffrés au repos et injectés au moment de l'appel. Une fois enregistrés, aucun écran ni aucune API ne les relit : les changer, c'est en écrire de nouveaux.
Second facteur et clés d'accès
Votre compte accepte un second facteur par application, par e-mail ou par passkey. Les outils internes derrière exigent le second facteur à chaque action sensible, pas une fois par session.
Vingt-quatre permissions, cinq rôles
Qui invite, qui dépense du crédit, qui publie. Publier est une permission à part, donc quelqu'un peut construire toute la semaine sans pouvoir le mettre devant des clients.
Là où l'IA n'a pas le droit d'aller
L'objection qui compte vraiment pour une application générée n'est pas de savoir si le code compile. C'est jusqu'où le modèle et l'agent peuvent atteindre.
L'agent hérite de l'appelant, jamais davantage
L'IA dans votre application publiée tourne sous la permission de la personne qui l'a appelée. Elle ne lit pas un enregistrement que cette personne ne pourrait pas lire, et c'est ce qui empêche un prompt de devenir une fuite.
Le modèle ne voit jamais un identifiant
L'appel d'un connecteur part de notre côté avec la clé. La clé n'est ni dans le prompt, ni dans le code généré, ni dans le navigateur.
Un appel sortant ne peut pas être retourné vers l'intérieur
L'adresse du connecteur est validée avant l'envoi, les redirections ne sont pas suivies et la réponse DNS est épinglée : impossible de l'amener vers une adresse interne.
Les questions qu'on nous pose
Signaler une vulnérabilité
Écrivez à security@fabapp.com. Notre canal de divulgation est publié sur /.well-known/security.txt, conformément à la RFC 9116. Laissez-nous une chance de corriger avant publication.
Documents: Les conditions d'utilisation, la politique de confidentialité, l'avenant de traitement des données et la politique d'usage responsable sont publiés intégralement et versionnés.