Sécurité
Ce que while vérifie lui-même à chaque construction et chaque nuit, et la revue de sécurité que fait votre agent avant chaque mise en production.
Mis à jour le 9 novembre 2026.
Vous, à votre agent : Fais une revue de sécurité avant de mettre en production.
Quand vous en servir
Elle est toujours là, sans rien déclarer, et votre agent la relit avant chaque mise en production.
Comment ça marche
while vérifie lui-même la sécurité de chaque appli, et l’agent fait sa propre revue avant la production. L’appli tourne isolée (gVisor), Internet lui est fermé par défaut, et ses secrets sont au coffre.
À chaque construction, while analyse le code reçu et ce que l’image livre au navigateur (Gitleaks, Opengrep). Une clé de production dans ce qui part au navigateur retient la production jusqu’à une validation, et le reste est signalé par deploy_app et get_app_status. Une page qui imite la connexion d’une marque connue ou demande une carte bancaire est signalée (un essai sans compte est coupé).
La liste des composants de l’image entière, paquets du système compris (Syft), est croisée avec les failles connues à chaque construction puis chaque nuit (UpdateFOMO), et une faille grave ouvre un incident qui réveille l’agent.
Après chaque mise en production puis chaque nuit, Probr contrôle de l’extérieur ses adresses publiques, à la recherche par exemple d’un fichier .env servi : ses constats sont dans status, et un constat grave ouvre l’incident « Failles graves ».
L’agent fait sa propre revue des changements avant la production, par exemple /security-review dans Claude Code, ou la revue de sécurité de Cloudflare, cloudflare/security-audit-skill, et deploy_app la lui rappelle à chaque mise en production.
Ce qu’il faut savoir
L’hameçonnage est une heuristique bornée : une page rendue seulement en images lui échappe.
Les outils MCP de votre agent
Votre agent s’en occupe avec les outils get_app_status et deploy_app.