この工程は何をするのか
全工程にまたがる。IT パスポート試験シラバス Ver.6.5 の「61. 情報セキュリティ」は、守る対象をこう挙げている。
企業における情報資産の代表的な種類として，顧客情報，営業情報，知的財産関連情報，人事情報などがあること
脅威は3種類に分けて整理される。
| 種類 | 用語例（シラバスより） |
|---|---|
| 人的脅威 | 漏えい、紛失、破損、盗み見、盗聴、なりすまし、クラッキング、ソーシャルエンジニアリング、内部不正、誤操作、ビジネスメール詐欺（BEC）、二重脅迫（ダブルエクストーション）、ダークウェブ |
| 技術的脅威 | マルウェア（コンピュータウイルス、ボット、スパイウェア、ランサムウェア）、ファイルレスマルウェア、ワーム、トロイの木馬、RAT、マクロウイルス、キーロガー、バックドア、迷惑メール |
| 物理的脅威 | 災害、破壊、妨害行為 |
脆弱性についてはこう定義されている。
情報システムの情報セキュリティに関する欠陥，行動規範の組織での未整備，従業員への不徹底などの脆弱性の概要 用語例 バグ，セキュリティホール，人的脆弱性，シャドーIT
シャドーIT が用語例に入っている点が、AI ツールを使う場面では直接効いてくる。会社が把握していないツールに業務情報を入れる行為がこれにあたる。
具体的な成果物
| 成果物 | 中身 |
|---|---|
| 守るべき情報資産の一覧 | 顧客情報・人事情報など、どこに何があるか |
| 触れてよい範囲の定義 | AI を含む道具が、どのファイル・どの通信先に触れてよいか |
| 脆弱性への対処記録 | 見つけた欠陥と、どう塞いだか |
つまずきやすいところ
「読ませない」設定をしても、書き込みは止まっていないことがある。 実践レシピ practices/protect-secret-files.md は、素朴な deny 設定に3か所の穴があることを具体的に示している。
- 穴1:
Readの deny は同じパスのEditもブロックする（v2.1.208 以降）が、WriteとNotebookEditは対象外。読めないが上書きはできる状態になる - 穴2: deny が効くのは組み込みファイルツールと、中身を解釈できる Bash コマンド（
cat、head、sedなど）だけ。python -c "print(open('.env').read())"は素通りする - 穴3: 評価順は deny → ask → allow で、ルールの具体度は順序を変えない。広い deny は狭い allow を打ち消す
設定した気になるのが一番危ない。 3つとも「書いたルールが効いていない」ではなく「効く範囲が思っていたのと違う」という形の失敗になる。
AI に任せられる範囲
この工程で任せられるのは、判断ではなく強制にあたる部分。境界を人が決めれば、その境界を守らせるところは機械がやる。
触れる範囲を OS 側で区切る
Claude Code の sandboxing は、Bash コマンドとその子プロセスに対して、OS レベルでファイルシステムとネットワークの境界を強制する（facts/claude-code/sandboxing.md）。コマンドごとの承認の代わりに、触れてよいファイルとネットワークドメインを定義する形になる。
上の「穴2」を塞げるのがこの層。 ルールを解釈して判断するのではなく OS が止めるので、Python スクリプト経由でも抜けられない。
Codex も同じ考え方で、既定でエージェントはネットワークアクセスを切った状態で動き、OS 強制の sandbox（通常は現在のワークスペースに限定）と承認ポリシーの2層で制御される（facts/codex/approvals-and-security.md）。
許可・拒否をルールとして共有する
permissions は、何にアクセスし何をできるかをルール・モード・managed policy で制御する仕組みで、permission 設定はバージョン管理にチェックインして組織で共有でき、開発者ごとに個別調整もできる（facts/claude-code/permissions.md）。
Gemini CLI の policy engine も同様に、ツール呼び出しを allow / deny / ユーザー確認のいずれにするかを .toml ファイルで書く（facts/gemini-cli/policy-engine.md）。ユーザーと管理者の両方が定義できる。
ルールがファイルになっていることが効く。 口頭の申し合わせと違い、リポジトリに入れれば全員に同じものが適用され、変更履歴も残る。シラバスが脆弱性として挙げる「行動規範の組織での未整備」「従業員への不徹底」に対する、直接の手当てになる。
まだ人がやること
何を守るかを決めること。 情報資産の棚卸しは業務を知っている人にしか作れない。守る対象が決まらなければ、どんなルールも書けない。
穴が空いていないか確かめること。 practices/protect-secret-files.md が示した3つの穴は、どれも設定を読んだだけでは気付けない。実際に読み出しを試して止まることを確認する作業が要る。
内部不正を想定すること。 シラバスは人的脅威の筆頭級に内部不正を挙げている。技術的な境界は誤操作を防ぐが、権限を持つ人が意図してやることは、権限設計そのものを見直さないと防げない。
ai_leverage を high ではなく medium にしているのはこのため。境界を守らせる部分は完全に機械化できるが、境界をどこに引くかの判断が人に残っている。