Help Net Securityは今回、Nol8のCEOであるKelly Herrell氏にインタビューを行い、AIエージェントが組織内でどのようにデータの露出を生み出すのかを聞きました。まず調べるべきはデータの経路です。エージェントが到達できる範囲、コンテキストに取り込まれる情報、そして処理結果がどこへ送られるのかを確認する必要があります。
チケット管理システムやCRMプラットフォーム、共有ドライブには何年にもわたる機密性の高いコンテキストが蓄積されており、エージェントはこれらを数秒でまとめ上げてしまいます。今回のインタビューでは、データアクセス制限に関する90日間の計画、事業部門とセキュリティ部門の間に生じる緊張関係、そしてデータの経路上でポリシーを強制することの重要性について語られています。
すでに本番環境でエージェントを運用している組織に入る際、最初に確認するものは何でしょうか。その答えから、組織の露出状況について通常どのようなことが分かりますか
私はエージェントの一覧を求めません。データの経路を求めます。
エージェントが到達できる範囲、コンテキストに取り込まれ得るデータ、呼び出せるツールやモデル、他のエージェントと通信できるかどうか、そして処理結果のデータがどこへ送られ得るのかを見せてもらいます。
エージェントの一覧からは、その組織が「何を導入したと認識しているか」が分かります。一方、データの経路からは「実際に何を露出させているか」が分かります。この二つのギャップこそが露出そのものです。次に聞くのは、その経路を通過したすべてのやり取りを提示できるか、それともサンプルしか提示できないかという点です。答えはほぼ常に「サンプルのみ」です。
ほとんどの組織は最初の二つの問いには答えられます。すなわち、これは正当なエージェントか、そして何にアクセスする権限を与えられているか、という点です。しかし三つ目の問いに答えられる組織はほとんどありません。このエージェントは、この特定のやり取りの中で、何を見るべきか、何を先へ引き継ぐべきか、何を開示すべきかという問いです。
エージェントの露出ポイントとして、最も意外だったデータストアはどれですか
意外だったものは、必ずしもデータベースではありません。企業が長年かけて蓄積してきたシステムの中で、それを大規模で相互に連結されたデータストアだと誰も認識していなかったケースです。
最も多くの人を驚かせるのは、チケット管理システムです。一件のチケットの中に、有効な認証情報がまだ残った本番環境のログが貼り付けられていたり、顧客のアカウント情報や、直前に発生したインシデントの経緯を詳細に記した記録が含まれていたりすることがあります。これが何年分のチケットにも積み重なっているにもかかわらず、誰もそれを一つのデータセットとして捉えたことはありませんでした。CRMプラットフォーム、コラボレーションツール、共有ドライブ、ナレッジベース、チャット履歴にも、同種の機密性の高い組織的コンテキストが蓄積されています。
これまでは、こうした情報をまとめ上げるには、どこを探すべきかを知っている人間がクエリを組み立て、別のアプリケーションを開き、手作業でパズルのピースを組み合わせる必要がありました。この手間こそがセキュリティ上の役割を果たしていたのです。全体像を組み立てるには時間と知識が必要であり、その労力自体が静かに一種の制御として機能していました。エージェントは、ほぼ即座に同じピースを取得し、関連付けてしまいます。手間が取り除かれれば、その制御も一緒に失われてしまうのです。
AIの登場によって、元となるデータが突然機密性を帯びるようになったわけではありません。AIが変えたのは、そのデータを発見し、結合し、移動させる速度、規模、そして容易さです。
CISOから90日間と限られた予算を与えられ、エージェントに対するデータアクセス制限を導入するとしたら、1週目に何を行い、意図的に何を後回しにしますか
1週目に取り組むのは可視化であり、環境全体を再設計しようとすることではありません。
エージェント、企業内のデータソース、モデル、ツール、他のエージェントとの間の経路をマッピングします。その境界をどのような機密データが越えているかを測定し、実行時にポリシーを強制できる場所を特定します。
大規模な構築作業は後回しにします。ID管理の全面的な再設計、すべてのエージェントの書き直し、まず企業内のすべてのデータを完璧に分類すること、役割ごとにマスキングした複製データを構築すること、あるいはすべてのエージェントのコードにガードレールライブラリを組み込むこと、といった作業です。これらはいずれもエージェント数や役割数に応じて規模が拡大するものであり、リスクの大きさに応じて拡大するものではありません。
目的は、データが移動する地点において速やかに制御を確立することです。まず観測し、リスクが最も高い経路で強制を行い、その後カバー範囲を広げていきます。それより高度な取り組みはすべて、まずこれらの地点で見て、強制できることが前提になります。
AIガバナンスに関するすべての課題を90日間で解決する必要はありません。境界を越えるデータに対する制御を確立することが必要なのです。
事業部門とセキュリティ部門は、エージェントのアクセス権限についてどのような点で意見が対立しがちですか。組織はその緊張関係をどのように解消すべきでしょうか
事業部門は、コンテキストが多いほどエージェントの有用性が高まるため、エージェントにより多くのコンテキストを持たせたいと考えます。セキュリティ部門は、アクセス範囲が広がるほど露出も大きくなるため、当然ながらアクセスを制限したいと考えます。
どちらの立場にも合理性があります。誤りは、この選択を二択の問題として扱ってしまうことです。つまり、エージェントにシステムへのアクセスを与えるか、与えないかという二択です。
エージェントがSalesforce、Jira、あるいはデータベースへのアクセスを正当に必要とする場合でも、それらのシステムが返せるすべてのデータを必要とするわけではありません。これが、権限管理とデータガバナンスの違いです。
より優れたモデルは、データそのものに対して、やり取りの内部でポリシーを強制することです。機密フィールドはエージェントごと、役割ごとに、通過中にマスキングまたはブロックされ、残りの応答部分はそのまま通過します。エージェントは事業部門が望むアクセス権限を維持したまま、見るべきでないフィールドには決して到達しません。よくある代替策、つまり役割ごとにマスキングされたデータの複製を維持する方法は、役割やエージェントを追加するたびに規模が拡大していきます。この方法ではそうした拡大は起きません。
事業部門は自分たちのエージェントを本番環境で運用でき、セキュリティ部門は検証可能な制御手段を得られ、しかも維持すべきデータの影の複製は生まれません。これが「すべて許可する」と「エージェントをブロックする」の間にある第三の選択肢です。
次のエージェントを展開する前に、すべてのセキュリティ部門が導入すべき制御は何ですか。そして、その確信に至った苦い経験とはどのようなものでしたか
次のエージェントを展開する前に、組織はエージェント環境に入出力するデータに対して、決定論的なポリシー強制ポイントを確立すべきです。実際には、その強制ポイントは四つの条件を満たす必要があります。第一に、データの経路上に存在し、トラフィックがそれを回避できないこと。第二に、すべてのペイロードを読み取ること。第三に、ラベルやタグではなく、データの内容そのものに基づいて判断すること。そして第四に、決定論的であること、つまり同じ入力からは常に同じ判断が下されることです。これはセキュリティ部門がその仕組みを承認するための前提条件でもあります。私たちはこの層を「AIデータプレーン」と呼んでいます。
エージェントがあるシステムに対して認証・認可されているからといって、そのシステムが返すすべてのデータがエージェントに取得・開示されて構わないものだと決して思い込んではいけません。
認証はエージェントが何者であるかに答えます。権限管理はエージェントがどこまで到達できるかを決定します。データガバナンスは、どの情報が境界を越えるべきかを決定します。
この区別が重要なのは、エージェントが情報を取得し、結合し、移動させる速度が、既存の制御が想定していた人間の作業フローよりもはるかに速いからです。私がこの確信に至ったのは、代替策が失敗する様子を目にしたからです。各エージェントのコード内に組み込まれた制御は、すべての開発者がそれを呼び出すことを覚えていることに依存しており、どこか一つのチームが忘れた時点で破綻します。そうではなく、強制の仕組みをデータの経路そのものに組み込むべきです。そこでは「忘れる」という選択肢自体が存在しません。
翻訳元: https://www.helpnetsecurity.com/2026/09/24/kelly-herrell-nol8-ai-agent-data-security/
