総仕上げ：個人セキュリティポリシー

セキュリティを定着させる

🔄 Quick Recall: 7つのレッスンで脅威の全体像（レッスン1）を学び、脅威モデルを構築し（レッスン2）、Docker分離を実装し（レッスン3）、権限境界を設定し（レッスン4）、スキル審査フレームワークを作成し（レッスン5）、監視を設定し（レッスン6）、プロンプトインジェクションが未解決の理由を理解した（レッスン7）。今度はそれを永続的なものにする。

Pixee.aiの調査で驚くべきギャップが判明：従業員500人以上の組織の98%がエージェンティックAIを展開しているが、79%が正式なセキュリティポリシーを持っていない。セキュリティの決定がインシデントごとにアドホックに行われ、教訓が忘れ去られる。

個人セキュリティポリシーがそのギャップを埋める。法的文書ではない——判断を記録し毎回決め直さなくて済むようにする、生きたリファレンス。

ポリシーテンプレート

以下のテンプレートはOWASP、NIST、Gartner、AWS、Auth0のフレームワークを組み合わせたもの。あなたの具体的なエージェント設定に合わせてカスタマイズする。

セクション1：エージェントインベントリ

使用しているすべてのAIエージェントをリスト：

なぜ重要か： 忘れたエージェントは守れない。シャドーAI——正式な承認なしに展開されたエージェント——はBitdefenderがエンタープライズ環境で見つけた主要な問題の1つ。個人にも起きる。

セクション2：権限ティア

脅威モデルに基づく3つの権限レベル：

ティア1 — 制限（低信頼）

• 指定ディレクトリへの読み取り専用アクセス
• インターネットアクセスなし
• 認証情報アクセスなし
• シェル実行なし
• 用途：未テストスキル、新しいエージェント、実験的ワークフロー

ティア2 — 標準（中信頼）

• プロジェクトディレクトリへの読み書きアクセス
• 許可リストのAPIエンドポイントのみ
• エージェント固有のスコープ付きトークン
• タスクごとに明示的に承認されない限りシェル実行なし
• 用途：審査済みスキル、日常ワークフロー、コーディング支援

ティア3 — 拡張（高信頼）

• より広いファイルアクセス（フルシステムではない）
• ロギング付きプロキシ経由のインターネットアクセス
• 事前承認されたコマンドに対するシェル実行
• 不可逆アクションにヒューマンインザループ
• 用途：長時間実行の自律タスク、マルチステップワークフロー

絶対に付与しない： 無制限シェル、フルファイルシステム、個人APIキー、承認なしのメール送信。

✅ Quick Check: 新しいスキルがDownloadsフォルダの整理を主張している。どの権限ティアから始めるべきか？（答え：ティア1——制限。まずDownloadsフォルダへの読み取り専用アクセスを与える。実行し、説明通りに動作することを確認し、動作をレビュー。問題なければティア2に昇格し、そのフォルダのみへの読み書きアクセスを付与。）

セクション3：インシデント対応

監視（レッスン6）がアラートを発火した場合：

ステップ1：停止（30秒）

docker stop agent-container --time=0

エージェントが実行中に調査しない。まず停止。

ステップ2：保全（2分）

docker logs agent-container > /tmp/incident-$(date +%Y%m%d).log
docker cp agent-container:/app/data /tmp/incident-data-$(date +%Y%m%d)/

何かに触れる前にログとデータをコピー。

ステップ3：無効化（2分）

• エージェントがアクセスしていたすべてのAPIキーを無効化
• エージェントの環境内のシークレットをローテーション
• 認証情報露出の疑いがある場合はパスワード変更

ステップ4：調査（15-60分）

• 何がアラートをトリガーしたか？
• 過去24時間にエージェントがアクセスしたファイルは？
• 予期しない宛先へのアウトバウンドネットワークリクエストがあったか？
• メモリファイルが変更されたか？

ステップ5：修復

• スキルが原因の場合：削除し、インストール済みの他のすべてのスキルを再審査
• プロンプトインジェクションが原因の場合：メモリファイルをクリーンアップし、処理されたドキュメントをレビュー
• 脆弱性が悪用された場合：エージェントを更新し、Docker設定をレビュー
• 何が起き何を変えたかを文書化

ステップ6：再開 新しい認証情報でエージェントを開始。48時間は注意深く監視。

セクション4：認証情報管理

Gartnerの「block, rotate, audit」フレームワークに従う：

Block： エージェントに個人の認証情報を渡さない。最小限の必要スコープでエージェント固有のトークンを作成。

Rotate： 認証情報ローテーションをスケジュール：

• クリティカル（金融API、メール）：毎週
• 標準（開発ツール、検索）：毎月
• セキュリティイベント後：即座に

Audit： アクティブな認証情報を四半期ごとにレビュー：

• どのトークンがアクティブか？不要なものはないか？
• 必要以上に広いスコープのトークンはないか？
• 廃止されたエージェントからの認証情報がまだ存在していないか？

セクション5：スキル管理

レッスン5の審査フレームワークを体系化：

インストール前：

• 5ポイント審査フレームワーク通過（ソース、スキャン、レビュー、前提条件、テスト）
• 権限ティアの割り当て（ティア1から開始）

インストール後：

• 強化ロギングで初回実行を監視
• 動作が説明と一致
• 予期しないファイルアクセス、ネットワーク呼び出し、メモリ変更なし
• 検証後に適切なティアに昇格

継続的：

• インストール済みスキルを毎月Cisco Skill Scannerで再スキャン
• スキルアップデートをチェックし更新前にチェンジログをレビュー
• VirusTotalでSuspiciousまたはMaliciousとフラグされたスキルは即座に削除

セクション6：週次レビューチェックリスト

毎週15分を費やす：

• エージェント活動ログの異常をレビュー
• 過去1週間の監視アラートを確認
• 設定ファイルに新しい認証情報パターンがないことを確認
• Dockerハードニングフラグがまだ設置されていることを確認（docker inspect）
• エージェントソフトウェアのアップデートとセキュリティパッチをチェック
• メモリファイルの予期しないエントリをレビュー
• キルスイッチがまだ機能することを確認（クイックテスト）

スケジュールする。 カレンダーに入れる。やることを覚えておくことに依存するセキュリティは実行されない。

✅ Quick Check: 週次レビューで、エージェントのDockerコンテナが–cap-drop=ALLなしで実行されていることに気づいた。設定したはず。何が起きたか？（答え：何かがハードニングフラグなしでコンテナを再作成した——エージェントのアップデート、再起動スクリプト、またはdocker-compose変更の可能性。週次レビューにDocker設定の確認を含める理由。即座に修正し、再作成をトリガーしたものを調査する。）

コースレビュー

ここから先へ

知識を深める：

• OWASP Top 10 for Agentic Applicationsを読む——業界標準
• Simon Willisonのブログでプロンプトインジェクション研究の最新情報をフォロー
• 使用しているエージェントのセキュリティアドバイザリを購読

スキルを構築する：

• インシデント対応手順をシミュレートされたアラートで練習
• スキル作成者の視点からスキルを理解するために「Build Custom OpenClaw Skills」コースを受講——スキルの仕組みを知ることがスキル審査の向上につながる

最新情報を追う：

• エージェントセキュリティは急速に進化——新しい脆弱性、防御、フレームワークが毎月登場
• セキュリティポリシーを四半期ごとに再評価
• 最良のセキュリティポリシーは実際に従い、アップデートするもの

Key Takeaways

• 98%がエージェンティックAIを展開、79%がポリシーなし——書面のポリシーでほとんどの組織より先を行く
• 3つの権限ティア（制限、標準、拡張）があらゆる状況にフレームワークを提供
• インシデント対応は手順であり即興ではない——停止、保全、無効化、調査、修復、再開
• 認証情報は「block, rotate, audit」——個人キーを共有しない、定期ローテーション、四半期レビュー
• 週次レビューは15分で設定ドリフト、予期しないアクセス、新たな脅威を捕捉
• ポリシーは生きたドキュメント——セットアップが変わったり新しいことを学んだりしたら更新する