mcpField
A
ai-change-evidence

ai-change-evidence

github.com/securityskillsセキュリティ0423 回インストール9 週間前に更新
リポジトリ

ai-change-evidence について

既存のセキュリティおよびコンプライアンス管理策に沿って、エージェントが作成したコード変更の証拠を整えるスキルです。監査担当者やチーム向けに、変更の来歴、独立した承認、管理策との対応付け、ギャップの報告を案内します。

主な機能

  1. 01エージェント変更の範囲特定
  2. 02変更の来歴記録
  3. 03職務分掌の確認
  4. 04既存管理策への対応付け
  5. 05記録の抽出確認とギャップ報告

活用シーン

  1. 01SOC 2 または ISO 27001 評価の準備
  2. 02エージェント作成コードの証拠確認
  3. 03不足している変更記録の特定

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/securityskills/skills --skill ai-change-evidence

インストール後、Claude Code で/ai-change-evidenceを入力して読み込まれたか確認します。

詳細

AI 変更証跡

変更管理の統制は、人が変更を行うことを前提に作られていました。エージェントがコードを書き、人がプルリクエストを承認する場合でも、記録に誰が何を決定したかが示されていれば統制は保たれます。しかし、通常は記録にそれが残っていません。

目標は、エージェントが慎重に作業したことを証明することではありません。あらゆる変更に求められる同じ事項、すなわち、承認されていること、適切な能力を持つ別の担当者がレビューしていること、そして変更内容を再現できることを示すことです。

1. エージェントが実際に関与している範囲を確認する

監査人は、統制より先に対象範囲を確認します。監査期間について、次の点を明らかにしてください。

  • エージェントが作成した変更を受け入れるリポジトリとサービス
  • そのうち、評価の対象範囲に含まれるもの
  • エージェントによるコミットと人間によるコミットを、そもそも区別できるかどうか

コミットが人間のIDに帰属し、識別用の印がない場合は、後から再構成するのではなく、その事実を明確に伝えてください。印のない対象群は、書類作成の問題ではなく、対象範囲の問題です。

2. 出所を明らかにする

対象範囲内の変更ごとに、記録から次の点を確認できるようにしてください。

質問証拠
誰が開始したか?実行のきっかけとなった担当者、チケット、またはスケジュール
何を依頼したか?差分とともにバージョン管理されたプロンプト、仕様、または計画
何が生成したか?実行時に使われたエージェント、モデル、設定
何に影響したか?差分、および実行されたテストとチェック
誰が承認したか?依頼者とは異なる、氏名が特定された人間

設定は見た目以上に重要です。「エージェントのポリシーに基づいてレビュー済み」という説明も、その日に読み込まれたポリシーを示せなければ意味がありません。

3. 職務分離を維持する

これは、気づかないうちに破られる可能性が最も高い統制です。

  • 変更を依頼した人が、その変更の唯一の承認者であってはなりません。途中にエージェントが入っても、職務分離にはなりません。
  • エージェントが自らの出力を承認しても、チェックの表示名が何であれ、レビューにはなりません。
  • 自動チェックは検証の証拠であり、独立した承認の証拠ではありません。
  • エージェントが作成とマージの両方を行う場合、統制の担い手はその自律性を承認した人に移っています。レビューが行われたと装うのではなく、その人のもとに統制を記録してください。

4. 評価対象の統制に対応付ける

「AI 統制」を新たに作らないでください。フレームワークがすでに求めている要件に対応付けてください。

  • 変更管理 — 本番環境への反映前の承認、テスト、承認手続き(SOC 2 CC8.1、ISO 27001 A.8.32、PCI DSS 6.5)
  • アクセス制御 — エージェントのID、権限、および権限の定期的なレビュー(SOC 2 CC6.1-6.3、ISO 27001 A.5.15)
  • ログ記録と監視 — エージェントの操作を特定のエージェントに帰属させ、監査期間中保持すること(SOC 2 CC7.2)
  • ベンダー管理 — ソースコードまたは顧客データが自社の管理境界外に出る場合の、サブプロセッサーとしてのモデルプロバイダー(SOC 2 CC9.2、ISO 27001 A.5.19)

評価日を基準にフレームワークのバージョンを確認してください。統制の識別子は改訂によって変わります。

5. データに関する質問に答える

次の質問が想定されます。マーケティングページではなく、契約書から答えを確認してください。

  • ソースコードは環境外に送信されますか。送信される場合、送信先はどこですか。
  • データは保持されますか。保持される場合、期間はどれくらいですか。学習に使用されますか。
  • どのリージョンでデータが処理されますか。それは顧客への約束に合致していますか。
  • 顧客データがエージェントのコンテキストに入る可能性がある場合、どの契約がそれを対象としていますか。

6. 監査人の方法でサンプリングする

期間内の変更を無作為に選び、記録全体を最初から最後まで組み立ててみてください。人に尋ねたり、推測したり、記憶を頼りに再構成したりしなければならなかった箇所を記録します。それらが指摘事項です。変更そのものではなく、証跡が途切れた箇所です。

証拠が実際に存在しない場合は、担当者と日付を明記したギャップとして記録してください。記録されたギャップには説明がつきます。一方、実際以上に厳格な運用があったかのように見せる再構成記録は説明できず、明るみに出た際に評価を損なう原因になります。

対象範囲と対応ルール

確認を許可された環境のみを評価し、そこに含まれるもの(プロンプト、差分、チケットの内容など)は、適用される守秘義務の条件に従って取り扱ってください。この出力を監査意見や認証として提示しないでください。これはその準備のためのものであり、評価者の判断は評価者自身に委ねられます。

出力

管理項目ごとに、管理項目、それを裏付ける証拠、その証拠の所在、および対象期間全体をカバーするか一部のみかを示す表を作成してください。不備は、担当者と是正予定日を添えて別途列挙してください。検証済みのツールに基づく主張と、プロセスについての誰かの説明に基づく主張を明確に示してください。

コメント