Tag Archives: art

漏えいの経路を可視化する：入力、メモリ、ログ、外部連携

データ漏えいを防ぐには、まず「秘密情報がどこに存在し得るか」を網羅的に把握する必要がある。AIエージェントの世界では、秘密情報はデータベースの中だけに閉じない。会話、参照資料、要約、実行ログ、学習用データ、キャッシュなど、あらゆる場所に一時的・永続的に残り得る。しかもそれぞれが次の処理の入力になり、意図せず拡散することがある。

最初の経路は入力である。エージェントはメールやチャット、チケット、PDF、社内Wiki、顧客の問い合わせ文などを読み取り、そこから必要情報を抽出して動く。ここで起きる漏えいは単純で、入力に含まれていた秘密情報を、出力やツール実行を通じて外に出してしまう。例えば顧客対応で、問い合わせ文に含まれていた個人情報をそのまま別の宛先に転送してしまう、社内限定の手順書の一部を外部向け返信に混ぜてしまう、といった事故だ。人間なら「この段落は社外秘」と判断して切り分けるが、エージェントは材料を同列に扱いやすい。入力段階で「これは外に出してよい情報か」を識別できない設計だと、漏えいは時間の問題になる。

次の経路がメモリである。エージェントを便利にする機能として、会話履歴の保持や長期メモリ、あるいはRAG用のベクトルインデックスが使われることが多い。しかしメモリは“便利な永続化”であると同時に、“漏えいの温床”にもなる。会話履歴にPIIや契約情報が残れば、後続のタスクで意図せず参照される可能性がある。長期メモリに書き込まれた情報が別のユーザー対応に混入すれば、顧客間の情報混線が起きる。RAGのインデックスに取り込んだ文書が過剰に広い権限で検索されると、本来アクセスできない人が情報を引き出せる。メモリは「いつ」「誰が」「どの条件で」読み書きできるのかを設計しないと、アプリケーションのデータ分離が崩れる。

さらに見落とされがちなのがログである。エージェントシステムは、トラブルシューティングや監査のために多くのログを残す。プロンプト、入力データ、参照したドキュメント、ツール呼び出しの引数、APIのレスポンス、エラー内容などが記録される。しかし、ログは一度残ると長く残り、アクセス範囲が広くなりがちだ。開発者や運用者が調査用に閲覧できるログに、顧客データやAPIキーが混入していると、それ自体が大きな漏えい面になる。さらに、ログが外部の解析サービスやSaaSに転送されている場合、その転送経路もリスクになる。エージェントは観測性が重要だが、観測性のために秘密情報がばらまかれるのは本末転倒だ。

最後に外部連携である。エージェントは外部ツールを使って価値を出す。SaaS、社内API、データウェアハウス、クラウド操作、決済、メール送信、ファイル共有など、連携先が増えるほど漏えいの出口も増える。特に危険なのは、連携のための認証情報をエージェント周辺に置くことだ。長期トークン、広いスコープのAPIキー、共有アカウントの資格情報などが残っていると、エージェントが誤って漏らすだけでなく、攻撃者に悪用される可能性も高まる。外部連携は「データが出ていく」だけでなく、「認証情報が露出する」という二重の意味でリスクがある。

このように、漏えい経路は一つではない。入力、メモリ、ログ、外部連携という四つの通り道を地図として描き、秘密情報がどこで発生し、どこに残り、どこから出ていき得るかを具体的に整理することが第一歩になる。

秘密情報の扱いを標準化する：ポリシーから実装へ

経路が見えたら、次は扱い方を“標準化”する必要がある。秘密情報は「気をつける」では守れない。エージェントが関わる限り、うっかりや誘導、バグ、更新によって必ず揺らぐ。だからこそ、分類とルールを決め、それを実装で強制する形にする。ここで重要なのは、セキュリティチームの規程だけで終わらせず、開発と運用が実際に守れる仕組みに落とし込むことだ。

最初にやるべきは、データ分類である。個人情報、認証情報、契約情報、財務情報、機密ソースコード、営業情報など、漏れると困るものは多い。だが現場で運用するなら、分類は細かすぎても回らない。ポイントは、エージェントが扱える範囲を決めるための分類にすることだ。例えば「外部に送信してよい」「社内限定」「権限者限定」「絶対にログに残してはいけない」のように、扱いのルールと直結するカテゴリに落とす。ここが曖昧だと、後段の技術対策も曖昧になる。

次に、認証情報の扱いを徹底する。エージェントにツールを触らせるなら、必ず認証が必要になるが、長期的に使える固定キーを持たせる設計は避けたい。理想は短命クレデンシャルで、必要なときだけ発行し、短時間で失効させる。権限のスコープも最小化し、読み取り専用と書き込み権限を分ける。可能なら環境ごとに分離し、開発環境のキーが本番に通用しないようにする。秘密情報をプロンプトに直埋めしない、会話コンテキストに混ぜない、エージェントが説明文として吐き出せないようにする、といった基本もここに含まれる。

さらに、データマスキングと最小開示を原則にする。エージェントが顧客データを参照するとき、必要な項目だけを渡す設計にする。例えば本人確認が目的なら、フルの住所やクレジット情報まで渡す必要はない。問い合わせ対応なら、注文番号とステータスだけで十分かもしれない。エージェントのコンテキストに渡した瞬間から、その情報は生成物やログに混入する可能性がある。したがって、エージェントに渡すデータは「最小で、短時間で、目的限定」にするのが基本になる。

この標準化を現実にするには、ポリシーをコードに変換する必要がある。具体的には、ツール実行前のフィルタで引数や送信先を検査し、禁止データが含まれていればブロックする。出力段階でも、外部送信や公開共有が絡むときは検査を強化し、マスキングや警告を入れる。加えて、メモリへの書き込みも制御する。長期メモリに保存してよい情報の条件を限定し、PIIや認証情報が混入する可能性があるものは保存しない。RAGのインデックスに入れる文書も、アクセス制御とセットで管理し、検索結果が不用意に広いユーザーに渡らないようにする。

ここまでの話は「厳しくして便利さを下げる」ように見えるかもしれない。しかし標準化の目的は、便利さを保ったまま事故を減らすことにある。ルールが曖昧なままだと、現場は不安になり、最終的にエージェントを信用できなくなる。標準化は、運用者にとっての安心材料でもある。

ログは武器にも爆弾にもなる：観測性とプライバシーの両立

AIエージェントを業務に入れるなら、ログと監査が重要になる。何かが起きたときに、どの入力が原因で、どのツールが実行され、どこに影響が出たのかを追えないと、インシデント対応ができないからだ。しかしログは、取り方を間違えると最大の漏えい源になる。観測性を上げようとして、秘密情報を記録しすぎる。この矛盾を解くには、ログを「調査に必要な最小限」に設計し直す必要がある。

まず考えるべきは、ログに残すべきものと、残してはいけないものの線引きだ。エージェントの調査で重要なのは、入力そのものの全文よりも、参照元と要点であることが多い。どのメールを参照したのか、どのドキュメントを引いたのか、どの検索結果を使ったのか。ツール実行については、どのツールをいつ呼び、成功したか失敗したか、影響を与える引数は何だったか、が重要になる。一方で、顧客の全文や認証情報、支払い情報、個人の詳細などを丸ごと残す必要はほとんどない。必要なら、マスキングした形やハッシュ化した識別子で追跡できるようにする。ログは「内容」ではなく「証跡」を残す、という発想が鍵になる。

次に、ログ閲覧権限を絞る。エージェント関連のログは、開発者全員が見られる状態になりがちだが、そこに顧客データが混入するリスクを考えると危険である。閲覧は必要最小限のロールに限定し、監査ログで誰が見たかを追えるようにする。保存期間も重要だ。長く残すほど調査には便利だが、漏えい面が増える。目的に応じて期間を分け、短期で十分なものは短く、監査上必要な証跡だけを長期保存する。ここも最初に決めておかないと、いつの間にか無制限に溜まっていく。

さらに、外部へのログ転送に注意する。可観測性のためにログ解析SaaSを使うこと自体は普通だが、そのSaaSに秘密情報が流れる設計だと、リスクが増える。転送前にマスキングを徹底し、そもそも外部に出してはいけない種類のログは出さない。エージェントはモデルプロバイダや外部APIとも通信することが多いので、通信とログの境界が曖昧になりやすい。どこまでが社内で、どこからが外部かを明確にし、外部に出る前に必ずフィルタがかかる構成にする。

ここまで設計しても、インシデント時には「詳細が欲しい」となる。そこで最後の工夫として、平時は最小ログ、非常時は一時的に詳細ログという切り替え設計が有効になる。常に詳細ログを取り続けるのではなく、異常検知や人間の判断で“観測モード”を上げ、短期間だけ詳細を残す。もちろんこの切り替え自体も権限管理が必要だが、プライバシーと調査能力の両立には合理的な選択肢になる。 AIエージェントのデータ漏えいは、特別なハッキングからだけ起きるわけではない。入力に混ざり、メモリに残り、ログに溜まり、外部連携から出ていく。だからこそ、秘密情報を守るには、通り道を地図として描き、分類とルールを標準化し、ログを証跡として設計し直す必要がある。エージェントは便利だが、便利さの裏には必ずデータの移動がある。移動を制御できる設計に変えれば、エージェントは怖い存在ではなく、統制可能な業務基盤として扱えるようになる。