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 dans le 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.
Accédez à Observer → politique et comparez les deux décisions.
Ouvrez chaque session liée et vérifiez que le payload de l’événement contient suffisamment de preuves pour la règle.
Lorsque le comportement est correct, déplacez la source vérifiée dans Admin → éditeur de politiques 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éfaillant.

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. Cela ne correspond pas aux noms tels que production-backup car production doit constituer un segment de chemin complet. Validez et installez 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 l’entrée de l’outil, les métadonnées de session, les paramètres et 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 pour les fichiers manquants, les erreurs de syntaxe, les imports non résolus, les exceptions de niveau supérieur et les délais d’attente de chargement de module. Lors de l’application, un fichier personnalisé défaillant est journalisé et ignoré afin que les politiques intégrées puissent continuer. 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 le Cloud. Gardez les fonctions de politique déterministes, limitez les appels externes par des délais d’attente courts, et retournez un allow, instruct ou deny intentionnel sur chaque chemin.

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 seulement la correspondance attendue.

​Tester la politique avant la publication dans le Cloud

​Tester les chemins d’échec

Tester la politique avant la publication dans le Cloud

Tester les chemins d’échec