Skip to main content
ポリシーは必ず2つの方法でテストしてください。エージェントが既に生成したトラフィックに対するテストと、必ず通過させなければならない正当な操作に対するテストです。安全でないケースしか確認していないポリシーは、テスト済みとは言えません。

ドラフトをバックテストする

ポリシーエディタは、公開前にドラフトをフリート(全エージェント群)が実際に行った呼び出しに対して再実行します。
  1. Admin → policy editor でドラフトを開きます。エディタはJavaScriptとして正しくパースされることを確認します。
  2. backtest で、再実行するエージェントと時間ウィンドウを選択します。デフォルトは every agent30d です。範囲を絞り込みたい場合を除き、最後のフィルターは everything のままにしてください。
  3. run backtest を選択します。 JavaScriptとして正しくパースされるドラフトの下にあるバックテストパネル。3つのフィルターとrun backeastアクション、その上のpublish versionが表示されている。
結果は、ドラフトがそれらの呼び出しに対してどのような動作をしたかを示します。正常に動作していた呼び出しのうち、どれだけが中断されていたかも含まれます。これは、エージェントが実際に遭遇する前に発見された誤検知です。その数が許容できるレベルになるまで、ドラフトを調整して再実行してください。

自分で定義したイベントに対して実行する

fp policies test は、ポリシーファイルをローカルマシン上で合成イベントに対して実行し、判定結果を確認します。何も公開されず、クラウドにも何も送信されません。
--event--tool--command--file でイベントの内容を指定します。ポリシー自身の match フィルターは引き続き適用されるため、指定したイベントをカバーしていないポリシーは判定ではなく skipped を返します。これはたいていの場合、match の範囲が意図より狭くなっているサインです。

1台のマシンで実行する

次に、自分のマシン上で自分のエージェントに対して実際に適用してみます。
最初のコマンドはファイルを検証してインストールします。2番目のコマンドは、このマシンで適用されている他のすべてのポリシーとともに、正しく読み込まれたことを確認します。ポリシーがブロックする操作をエージェントに試させて拒否されることを確認し、次に正当な操作を試させて通過することを確認します。他の誰にも影響はありません。 クラウドに接続されたマシンでは、Observe → policy で両方の判定結果を確認します。ポリシー名でフィルタリングし、リンクされた各セッションを開いて、マッチしたツール入力と返された理由を確認してください。

壊れたケースをテストする

インストールは、ファイルが存在しない場合、構文エラー、未解決のインポート、トップレベルの例外、またはロード中にタイムアウトするモジュールがある場合に失敗します。そのため、ファイルまたはインポートしているものを変更するたびに再実行してください。適用時には、同様に壊れたファイルはログに記録され skipped されるため、他のすべてのポリシーは引き続き実行されます。本番ログのロード警告は適用の欠落として扱ってください。Conventionファイルはインストールコマンドなしで読み込まれるため、CIには明示的な failproofai policies --install --custom <file> ステップを含めてください。これが壊れたポリシーでビルドを失敗させる仕組みです。 次に、期待する入力だけでなく、エージェントが実際に送信するものをすべて与えてテストしてください。フィールドの欠落、WriteEdit などの別のツール名、Windowsパス、不正な形式の入力などです。すべてのコードパスで意図的に allowinstruct、または deny を返し、関数を決定論的に保ち、外部呼び出しには短いタイムアウトを設定してください。

公開して観察する

バックテストは、既存のトラフィックに対してポリシーが何をしたかを示しますが、まだ見ていないトラフィックがどう動くかは示せません。エディタで publish version を選択(または fp policies publish を実行)し、まず observe モードでデプロイしてください。このモードでは判定結果が記録されるだけで何もブロックされません。マッチした結果が安全でない操作と正当な操作を正しく分離できていることを確認してから、実際の適用に切り替えてください。