Écrire une politique

Il existe deux façons d’écrire une politique : laisser Failproof AI la rédiger à partir d’un résultat d’audit, ou écrire la source vous-même. Rien n’est publié ni déployé tant que vous ne le décidez pas.

Écrire une politique à partir d’un audit

Un audit détecte une défaillance ; une politique empêche qu’elle se reproduise. Failproof AI rédige la politique à partir des preuves propres au résultat.

1. Lancer un audit

Lancez un audit sur les sessions où la défaillance se produit. Chaque résultat contient ses sessions de preuves, une cause racine et un chemin de prévention suggéré. Partez d’un résultat avec un schéma d’action répétable — une politique ne peut bloquer que ce qu’elle peut reconnaître dans un événement de hook.

2. Générer le brouillon

Dashboard
CLI

Ouvrez le problème du résultat sous Analyze → issues et vérifiez ses sessions citées, sa cause racine et sa recommandation.
Sélectionnez generate policy. Failproof AI indique d’abord si une politique peut exprimer le problème. Un résultat no policy signifie que la correction passe par une alerte, un changement de flux de travail ou une intervention humaine — pas une politique.
Sélectionnez write this policy. Le titre du problème, le résultat, la cause racine, la recommandation et l’intention d’application proposée deviennent un brouillon dans Admin → policy editor. Utilisez open the editor anyway si vous n’êtes pas d’accord avec la vérification de candidature.

Lisez les preuves, puis rédigez avec l’assistant. compose affiche la source pour que vous la révisiez et ne publie rien :

fp issues show <issue-id>
fp audits finding <finding-id>
fp policies compose "Block git push --force on release branches"

compose nécessite une session connectée (fp login) dont le rôle dispose de policies:write ; il refuse les clés API.

3. Réviser le brouillon

Un brouillon est un point de départ, pas un verdict. Avant de publier, vérifiez qu’il :

Nomme le mode de défaillance dans un langage opérationnel.
Ne correspond qu’aux événements de hook et aux outils qui contiennent suffisamment de preuves pour décider.
Utilise la condition la plus étroite possible pour intercepter l’action non sécurisée.
Retourne une raison indiquant à l’agent ce qu’il doit faire à la place.
Utilise instruct lorsque l’agent peut corriger sa trajectoire en toute sécurité, et deny uniquement lorsque autoriser l’action est inacceptable ou irréversible.

Validez la source dans l’éditeur et corrigez chaque erreur signalée.

4. Tester, puis publier

Exécutez backtest sous la source avant de publier : cela rejoue le brouillon contre les appels déjà effectués par votre flotte et compte les appels en cours de fonctionnement qui auraient été interrompus. Tester une politique couvre cela ainsi que les autres vérifications. Une fois qu’elle se comporte correctement, saisissez l’identité de la politique et sélectionnez publish version. La publication crée une version immuable et ne déploie rien : elle reste inutilisée jusqu’à ce que vous la déployiez. Depuis un terminal :

fp policies publish checkout-guard ./checkout.policy.mjs --description "Block force-push"

publish vérifie la syntaxe de la source avant de l’envoyer, de sorte qu’une erreur de syntaxe apparaît ici plutôt que sur une machine au moment de l’application.

L’écrire vous-même

Une politique est du JavaScript ou du TypeScript utilisant l’API failproofai :

import { customPolicies, allow, deny } from "failproofai";

customPolicies.add({
  name: "protect-production-paths",
  description: "Block writes to production configuration",
  match: { events: ["PreToolUse"] },
  fn: async (ctx) => {
    if (ctx.toolName !== "Write" && ctx.toolName !== "Edit") return allow();
    const path = String(ctx.toolInput?.file_path ?? "").replaceAll("\\", "/");
    if (path.split("/").includes("production")) {
      return deny("Writes to production configuration require approval.");
    }
    return allow();
  },
});

Cela correspond à production/config.yml, /srv/production/config.yml, /srv/production et C:\\production\\config.yml pour Write et Edit, mais pas à production-backup : production doit être un segment de chemin complet. Le contexte contient également le type d’événement, la charge utile normalisée, les métadonnées de session, les paramètres et la CLI source lorsqu’elle est disponible — consultez le SDK de politique. Pour la publier en tant que version, collez la source dans compose sous Admin → policy editor et suivez les étapes 3 et 4 ci-dessus, ou publiez le fichier depuis un terminal avec fp policies publish. Pour l’exécuter sur une machine sans Cloud, enregistrez-la sous .failproofai/policies/ avec un nom se terminant par policies.js, policies.mjs ou policies.ts — ces fichiers se chargent automatiquement aux portées projet et utilisateur — ou installez-la par chemin :

failproofai policies --install --custom ./security.policies.ts --scope project

Donnez à chaque politique un nom unique parmi les politiques conventionnelles, personnalisées, en pack et gérées par Cloud.

Prevent repeat failures

Get a policy

Ship a policy