input / output）ごとにGuardianへ割り当てられます。
StarfortのGuard Policy Type Catalogは固定の集合 — PIIとTOPIC — です。System Guardianは評価できるサブセットを宣言し、Project Guardianはそのサブセットを継承します。各ポリシーはPolicy Nameを持ち、これはプロジェクト内で一意です。この名前はGuardianの出力やOpticonのトレースタグで使われる識別子であるため、ポリシーの名前を変更することは履歴を書き換えるのではなく、新たなアイデンティティを開始することを意味します。
PIIポリシー
個人データや機微なデータを検出し、各一致に対する処理を決定します。PIIポリシーは3種類のルールで構成されます。| ルールの種類 | 一致方法 | 一般的な用途 |
|---|---|---|
| NER | 学習済みエンティティモデル（氏名、住所、…） | 自然言語のエンティティ |
| Regex | 正規表現 | 構造化されたID（電話番号、住民登録番号、カード、メール） |
| Keyword | 完全一致する単語/フレーズ | 拒否リストに登録された用語 |
MASKING— 一致箇所をマスクワードトークンに置き換えます（例:PHONE_NUMBER→[PHONE_NUMBER_1]）。BLOCKING— 一致した場合、リクエスト全体をブロックします。PASSING— 明示的に許可します（例: テストデータを許可リストに登録）。これにより、より広範なルールに捕捉されないようにします。
Starfortに標準で付属するPIIポリシーは、韓国の電話番号、住民登録番号、パスポート/運転免許/通関ID、銀行口座、カード、メール、車両ナンバープレートを対象としており、加えて一般的なテストパターン向けの
PASSINGルールも含まれています。カスタマイズしたPIIポリシーの追加を参照してください。Topicポリシー
定義されたトピックに照らしてコンテンツを分類し、その分類結果に基づいて処理します。各トピックはsafe、controversial、unsafeのコンテンツを定義し、その分類は直接アクションにマッピングされます。
safe→ PASS — そのまま通過します。controversial→ CHECK — レビューが必要としてフラグ付けされます。Desktop AgentおよびProxy Serverでは、CHECKはPASSとして適用されます（コンテンツはブロックもマスクもされずに通過し、トレースに記録されるのみ）。API呼び出し元にはCHECKがそのまま返されます。unsafe→ BLOCK — リクエストが停止されます。
ポリシーがGuardianに渡される仕組み
ポリシーは、Policy Type → Policy Nameという2階層の構造でGuardianに渡されます。同じタイプの複数のポリシーは名前によって区別されたまま保持されます（そのまま渡され、決してマージされません）。そのため、1つのinputスロットは、例えば2つの異なるPIIポリシーと1つのTopicポリシーを同時に保持でき、それぞれが独立して評価されます。
バージョン管理と割り当て
Guard Policyはセマンティックバージョニングを使用し、Project Guardianは特定のバージョンを**Pin（固定）**します。- ポリシーのルールを編集すると、新しいバージョンが作成されます（例:
v0.1.0→v0.1.1）。 - Project Guardianは、明示的に再Pinするまで、Pinされたバージョンを使い続けます — 保存 ≠ 適用。新しいバージョンを公開しても、Pinが自動的に変わることはありません。
- 1つのprocess typeスロットには、複数のポリシーを保持できます（例:
inputにPIIポリシーとTopicポリシーの両方）。