Skip to main content
.failproofai/policies/ 配下に policies.jspolicies.mjs、または policies.ts で終わるファイルを作成してください。規約ファイルはプロジェクトスコープおよびユーザースコープで自動的に読み込まれます。

クラウド公開前にポリシーをテストする

  1. 1台のテストマシンにカスタムポリシーをインストールし、マッチするアクションと正当な非マッチの両方をトリガーします。
  2. Observe → policy に移動して、2つの判定結果を比較します。
  3. リンクされた各セッションを開き、イベントペイロードにルールの根拠となる十分な証拠が含まれていることを確認します。
  4. 動作が正しければ、レビュー済みのソースを Admin → policy editor に移動してバージョンを公開します。
これは production/config.yml/srv/production/config.yml/srv/production、および C:\\production\\config.yml に対して WriteEdit の両方でマッチします。production は完全なパスセグメントである必要があるため、production-backup のような名前にはマッチしません。 明示的なファイルのバリデーションとインストール:
ポリシーコンテキストには、イベントタイプ、正規化されたペイロード、ツール名と入力、セッションメタデータ、パラメーター、および利用可能な場合はソース CLI が含まれます。

失敗パスのテスト

エントリファイルまたはそれがインポートするローカルモジュールを変更した後にバリデーションを実行します:
strict な CLI パスは、ファイルが存在しない場合、構文エラー、未解決のインポート、トップレベルの例外、およびモジュールロードのタイムアウトで失敗します。強制適用時に壊れたカスタムファイルはログに記録されてスキップされるため、組み込みポリシーは引き続き動作します。ロード警告は期待された強制適用の喪失として扱い、本番ログでアラートを発報してください。 明示的なポリシー、規約ポリシー、クラウド管理ポリシーにわたってグローバルに一意な名前を使用してください。ポリシー関数は決定論的に保ち、外部呼び出しには短いタイムアウトを設け、すべてのパスで意図的な allowinstruct、または deny を返すようにしてください。
カスタムポリシーは強制適用コードです。期待されるマッチだけでなく、フィールドの欠落、別のツール名、不正な入力についてもテストしてください。