Skip to main content
カスタムポリシーは、トレースや監査から検出された障害パターンを、エージェントの実行中に評価される判断ロジックに変換します。ポリシーはアクションを許可したり、エージェントにガイダンスを提供したり、別のインシデントが発生する前にアクションを拒否したりできます。 ツール・パス・コマンド・環境・運用ルールに依存する動作には、カスタムポリシーを使用してください。既存のコントロールを再作成しないよう、まず組み込みポリシーカタログを確認してください。

カスタムポリシーを作成する

  1. Admin → ポリシーエディタに移動し、新規ポリシーを選択して、防止したい障害を説明します。
  2. ポリシーのソースを追加し、エディタで期待されるマッチと安全な非マッチをテストします。すべてのバリデーションエラーを解消してください。
  3. ドラフトを保存し、バージョンを公開を選択してイミュータブルなバージョンを作成します。
  4. Admin → 適用に移動し、observeモードでテストマシンにバージョンをデプロイして、適用前にObserve → ポリシーで判断内容を確認します。 カスタムポリシーの作成と公開に使用するポリシーエディタ。

狭いルールから始める

このポリシーは、コマンドがプロダクション環境を対象とする場合にのみ、破壊的なKubernetesコマンドをブロックします。その障害モード以外はすべてallow()を返します。
良いポリシーは1文で説明できるほど狭く絞られています。エージェントの意図ではなく、観察可能なアクションにマッチさせ、ルールが適用されなくなったらすぐにallow()を返してください。

判断を選択する

リカバリーが必要なエージェント向けに理由を記述してください。検出された内容と代わりに行うべきことを説明します。
安全境界にはinstruct()を使用しないでください。ガイダンスの配信はエージェントハーネスによって異なります。アクションを防止する必要がある場合はdeny()を使用してください。

ポリシーオブジェクト

ツールのフィルタリングはfnの内部で行ってください。match.toolNamesはパブリックなカスタムポリシー型には含まれていません。

ポリシーコンテキスト

すべてのポリシーはPolicyContextを受け取ります。 オプショナルな値はすべて本当にオプショナルとして扱ってください。エージェントのバージョンやイベントタイプによって、提供されるフィールドが異なります。

一般的なツール入力

Failproof AI はサポートされているハーネス全体で一般的なツールを正規化するため、ポリシーは通常1つの入力形式を使用できます。 ツール入力値はunknown型であるため、防御的な型変換を使用してください:

イベントを選択する

イベントの可用性とブロッキング動作はエージェントハーネスによって異なります。混合フリートでイベントを利用する前にエージェントハーネスを参照してください。
SessionStart, SessionEnd, UserPromptSubmit, PreToolUse, PermissionRequest, PermissionDenied, PostToolUse, PostToolUseFailure, Notification, SubagentStart, SubagentStop, TaskCreated, TaskCompleted, Stop, StopFailure, TeammateIdle, InstructionsLoaded, ConfigChange, CwdChanged, FileChanged, WorktreeCreate, WorktreeRemove, PreCompact, PostCompact, Elicitation, ElicitationResult, UserPromptExpansion, PostToolBatch, Setup

一般的なポリシーパターンを作成する

保護されたパスへの書き込みをブロックする

ノンブロッキングガイダンスを提供する

セッション完了をゲートする

Stopイベントを拒否するとエージェントがリトライする可能性があります。現在の環境でエージェントが満たせる条件のみをゲートし、すべてのサブプロセスやネットワーク呼び出しには必ず上限を設けてください。

ポリシーファイルを読み込む

コンベンションファイル

コンベンションファイルは自動的に読み込まれます:
  • プロジェクトとユーザーのポリシーディレクトリは両方読み込まれます。
  • ファイルは各ディレクトリ内でアルファベット順に読み込まれます。
  • ファイル名はpolicies.jspolicies.mjs、またはpolicies.tsで終わる必要があります。
  • 1つのファイル内で複数のcustomPolicies.add()呼び出しがサポートされています。
  • ローカルモジュールからの相対インポートがサポートされています。
  • プロジェクトポリシーはコミットできるため、同じルールがリポジトリに従います。

明示的なファイル

バリデーションや設定でエントリーファイルを直接指定する場合は、明示的なパスを使用してください:
明示的なファイルが最初に読み込まれ、続いてプロジェクトのコンベンションファイル、ユーザーのコンベンションファイルの順に読み込まれます。両方のパスで検出されたファイルは1度だけ読み込まれます。

バリデーションとテスト

バリデーションはプロダクションローダーを通じてモジュールを実行し、少なくとも1つのポリシーが登録されることを確認します。
バリデーションは、ファイルの欠如、構文エラー、未解決のインポート、トップレベルの例外、モジュールロードのタイムアウトを検出します。ただし、マッチロジックの正確性は保証されません。 少なくとも以下のケースをテストしてください:
  • マッチして意図したポリシー理由を生成するアクション1つ。
  • allow()を返す必要がある、類似しているが安全なアクション1つ。
  • ツールフィールドの欠如または不正な形式。
  • コマンド構文、パス、クォート、大文字小文字、空白の代替パターン。
  • 利用不可能なサブプロセスまたはネットワーク依存関係。
Observe → ポリシーで結果がカスタムポリシーに帰属していることを確認してください。別の組み込みポリシーが判断を行った場合、ブロックされたテストだけでは十分ではありません。

ランタイムの動作

  • 組み込みポリシーはカスタムポリシーより先に評価されます。
  • 最初のdenyでそれ以降のポリシー評価が停止します。
  • いずれのポリシーもイベントを拒否しない場合、複数のinstruct結果を組み合わせることができます。
  • ポリシー関数には10秒の実行期限があります。
  • スローされた例外またはタイムアウトはログに記録され、allow()として扱われます。
  • 読み込みに失敗したコンベンションファイルはスキップされ、他のカスタムファイルと組み込みポリシーは続行されます。
  • トップレベルのモジュール読み込みにも10秒の期限があります。
  • クラウドのobserveモードはポリシーを実行しますが、non-allowの判断を適用せずに記録します。
ポリシーモジュールは決定論的かつ高速に保ってください。トップレベルのネットワーク呼び出しやサーバー起動は避けてください。fn内の処理に上限を設け、依存関係の失敗をキャッチし、その失敗がアクションを許可するか拒否するかを意図的に選択してください。

APIエクスポート

TypeScriptはPolicyContextPolicyResultCustomHookPolicyDecisionPolicyFunctionをエクスポートします。

カスタムポリシーをデプロイする

バージョンを公開し、observeモードでデプロイして、判断内容を確認してから適用に移行する。