Votre code reste dans votre runner GitHub Actions.

La vérification tourne dans votre propre runner GitHub Actions.

Paidwen lance un workflow dans votre dépôt. GitHub donne à chaque run une machine neuve et détruit la machine après le travail. La machine récupère votre code, construit votre application et rejoue vos parcours.

Les offres Scale et Enterprise peuvent aussi faire tourner la vérification sur vos propres runners, dans votre cloud ou chez un fournisseur de runners.

Les serveurs de Paidwen reçoivent des résultats et jamais du code.

Les serveurs de Paidwen reçoivent trois sortes de données :

• Le titre, la description et les messages de commit de la pull request.
• La configuration paidwen.yml lue par le moteur.
• Le verdict, le résultat de chaque parcours et les événements du run.

Les serveurs de Paidwen ne reçoivent jamais votre code source, vos vidéos, vos captures d'écran ni vos clés de modèle.

L'application GitHub demande cinq permissions et jamais le contenu.

• Métadonnées, en lecture.
• Pull requests, en écriture, pour un seul commentaire par pull request et pour lire son titre, sa description et ses commits.
• Checks, en écriture, pour le check Paidwen.
• Actions, en écriture, pour lancer, annuler et lire les runs de vérification.
• Files de fusion, en lecture.

L'application n'a pas la permission Contents. Sa permission Pull requests donne accès au diff d'une pull request, et les serveurs de Paidwen ne le demandent jamais. Le travail du workflow lit votre dépôt dans le runner, avec le GITHUB_TOKEN de votre propre workflow.

Une pull request ne peut ni modifier ni usurper sa vérification.

• Votre workflow appelle un workflow réutilisable publié par Paidwen. Paidwen lance le run par workflow_dispatch sur votre branche par défaut, et la pull request ne peut donc pas modifier le workflow qui la vérifie.
• Le moteur lit paidwen.yml sur la branche de base.
• Le travail tourne dans l'environnement GitHub nommé paidwen, et Paidwen vérifie le champ job_workflow_ref du jeton OIDC du travail.
• Avant tout code de la pull request, le runner échange le jeton OIDC contre un jeton d'envoi lié au dépôt, au run, à la tentative et à la vérification.
• Le travail lit le contenu et demande un jeton OIDC, et le checkout ne garde aucun identifiant.

Aucun code de la pull request ne tourne sur la machine hôte du runner.

La construction, les migrations, les données de test et l'application tournent dans des conteneurs lancés avec un environnement vide et une liste permise. Chaque conteneur a des limites de processeur, de mémoire et de processus.

Paidwen ne lance jamais tel quel le fichier compose de la pull request. Le moteur recopie une liste permise de clés et refuse les options privilégiées, les montages de dossiers de l'hôte, les constructions hors du dépôt et les variables non résolues.

L'application tourne sur un réseau interne sans accès à internet. Une passerelle laisse passer les seuls hôtes listés dans paidwen.yml.

Le moteur est signé et épinglé.

L'action publique sert seulement d'amorçage. Après l'échange OIDC, le runner télécharge le moteur versionné et refuse toute version dont la signature ne correspond pas à la clé publique épinglée. La clé privée de signature ne vit jamais sur les serveurs de Paidwen.

Vous pouvez épingler une version du moteur avec settings.engine dans paidwen.yml.

Les secrets ont des noms fixes, et les fourches n'en reçoivent aucun.

Paidwen lit cinq secrets dans l'environnement GitHub nommé paidwen, et le workflow ne transmet aucun autre secret :

• PAIDWEN_TEST_LOGIN et PAIDWEN_TEST_PASSWORD, le compte de test de vos parcours.
• PAIDWEN_STRIPE_TEST_KEY, votre clé de test Stripe.
• PAIDWEN_ENV, les valeurs de test dont votre application a besoin.
• PAIDWEN_MODEL_KEY, votre propre clé de modèle pour la couche modèle optionnelle.

Les secrets entrent dans les conteneurs au démarrage de l'application, jamais pendant la construction.

Une pull request venue d'une fourche tourne dans l'environnement paidwen-fork, sans aucun secret. La première pull request d'un nouveau contributeur attend qu'un mainteneur lance la vérification.

Aucun modèle d'IA ne lit votre code.

Le rejeu est un script Playwright déterministe. Sans clé de modèle, un échec s'explique en une phrase simple, construite à partir de l'étape en échec, de l'action d'avant et de ce que montre la page, avec la capture et l'instant dans la vidéo.

Votre agent de code enregistre un parcours à partir d'une phrase sur votre machine, avec npx paidwen mcp, et corrige la cible d'une étape quand sa pull request renomme exprès un contrôle. Cela ne demande aucune clé. La couche modèle optionnelle utilise votre propre clé, PAIDWEN_MODEL_KEY, pour faire de même pendant la vérification et expliquer une cassure à partir des deux pages. Votre modèle voit la page réduite à ses éléments actifs et le texte de la pull request, jamais votre code. Un parcours passe seulement quand ses vérifications finales déterministes passent, et un modèle ne décide jamais seul d'un succès.

Le moteur appelle votre modèle depuis la machine de votre runner, et lui seul lit la clé. Chromium et votre application gardent leur réseau sans internet, et aucun conteneur de votre application ne reçoit la clé.

Les runs qui exécutent le code d'une pull request n'enregistrent aucun cache.

Seuls les runs de référence de votre branche par défaut enregistrent des caches, sous des clés préfixées et plafonnées.

Les vidéos restent chez GitHub.

Le moteur dépose la vidéo comme artefact de votre run, gardé 90 jours. Le verdict renvoie vers l'artefact, et Paidwen ne stocke aucun média.

Les données de chaque client sont isolées dans la base.

La base de données de Paidwen applique la sécurité par ligne de Postgres à chaque client, et des tests d'isolation couvrent les règles.

Les secrets de Paidwen vivent dans un fichier d'environnement que seul son propriétaire peut lire sur le serveur. La clé de signature du moteur reste hors du serveur.

Vous signalez un problème de sécurité par email.

Écrivez à [email protected] avec les étapes qui reproduisent le problème.