Politiques personnalisées

Créez un fichier se terminant par policies.js, policies.mjs ou policies.ts dans .failproofai/policies/. Les fichiers de convention se chargent automatiquement aux portées projet et utilisateur.

Tester la politique avant la publication Cloud

Tableau de bord
CLI

Installez la politique personnalisée sur une machine de test et déclenchez à la fois une action correspondante et une non-correspondance légitime.
Rendez-vous dans Observe → policy et comparez les deux décisions.
Ouvrez chaque session liée et vérifiez que le payload d’événement contient suffisamment d’informations pour la règle.
Lorsque le comportement est correct, déplacez la source vérifiée dans Admin → policy editor et publiez une version.

failproofai policies --install --custom ./security.policies.ts \
  --cli claude --scope project
failproofai policies

Les fichiers de convention dans .failproofai/policies/ se chargent sans --custom. Conservez une commande d’installation explicite en CI lorsque la validation doit échouer sur un module défectueux.

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();
  },
});

Ce code correspond à production/config.yml, /srv/production/config.yml, /srv/production et C:\\production\\config.yml pour les deux outils Write et Edit. Il ne correspond pas à des noms tels que production-backup, car production doit constituer un segment de chemin complet. Valider et installer un fichier explicite :

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

Le contexte de la politique inclut le type d’événement, le payload normalisé, le nom et les entrées de l’outil, les métadonnées de session, les paramètres, ainsi que le CLI source lorsqu’il est disponible.

Tester les chemins d’échec

Exécutez la validation après avoir modifié le fichier d’entrée ou tout module local qu’il importe :

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

Le chemin CLI strict échoue en cas de fichiers manquants, d’erreurs de syntaxe, d’imports non résolus, d’exceptions au niveau supérieur et de délais d’expiration au chargement du module. Au moment de l’application, un fichier personnalisé défectueux est journalisé et ignoré afin que les politiques intégrées puissent continuer à fonctionner. Traitez tout avertissement de chargement comme une perte d’application attendue et signalez-le dans les journaux de production. Utilisez des noms globalement uniques pour les politiques explicites, de convention et gérées par Cloud. Gardez les fonctions de politique déterministes, encadrez les appels externes avec des délais courts, et retournez un allow, instruct ou deny intentionnel sur chaque chemin d’exécution.

Une politique personnalisée est du code d’application. Testez les champs manquants, les noms d’outils alternatifs et les entrées malformées — pas uniquement la correspondance attendue.

​Tester la politique avant la publication Cloud

​Tester les chemins d’échec

Tester la politique avant la publication Cloud

Tester les chemins d’échec