アドバイザリーって、セキュリティリサーチでは英語の意味とは同じじゃないんだよね。残念ながら、「アドバイザリー」っていうのはセキュリティインシデントについて書かれた報告書で、バグの公式な声明やその影響、修正方法についてのものなんだ。英語の意味とは違って、「人にアドバイスする」や「何かをアドバイザリーとして受け取る」っていう意味じゃないんだよね（これって通常、すごくソフトな表現）。

https://www.merriam-webster.com/dictionary/advise 意味2: 情報や通知を与えること : 知らせる アドバイザリーは何かについて通知や警告を出し、可能な行動についての推奨をすることもある（でも必ずしもそうする必要はない）。

このほとんど内容のないストーリーを書いたLLMは、何を言ってるのか分かってない。情報セキュリティ業界の基本的な区別は、アドバイザリーは顧客に対してバグがあってそのせいで攻撃にさらされる可能性があることを伝え、特定のアクションを取ってもらいたいときに出すもので、インシデントレポートは被害が発生したことが分かっていて、それが自社のインフラに関わるもので、何が起きたのか、再発防止策を共有したいときに出すもの。後者は公の注目や規制の厳しい目を引き寄せるから、Microsoftのような企業は可能な限りアドバイザリーに留まるようにする（あるいはインシデントを隠す）。過去にそういうことがあったかもしれないけど、私の知る限り、Microsoftがファーストパーティのセキュリティインシデントレポートを公開したことはないと思う。

厳しさを誇張すると、人々はインシデント警告を無視するだけだよ。セキュリティチームがここで実際に必要なアクションは何？特にないよ。嫌だと思うかどうかは別として、結局のところ、修正も緊急の危害もない。ただのDLPポリシーに関する潜在的な問題があるだけ。実際に対処しなきゃいけない0-dayのように見せないでほしい。

これって他のアクセス制御システムと何が違うの？

根本的な緊張関係は、AIが大量の低品質な出力を生み出すってことだと思う。人間がその中身をチェックするのが嫌になるんだよね。だからみんなAIに直接インターフェースさせたがるけど、質の悪いものを現実に持ち込むと、いろいろ問題が出てくる。

重要なのは、AIがローカルで動いていればこの問題は起きないけど、「内部のメールをクリアテキストでクラウドに送る」っていうのは、実際に機密性が求められる組織にとっては深刻な問題だよね。

レトロフィッティングの問題は確かにあるけど、もっと具体的な設計の失敗があるんだ。それはデータの流れが逆方向になってること。従来のアクセス制御では、パターンはこうだ：ユーザーがデータをリクエスト -> 権限をチェック -> データが返されるか拒否される。モデルは未承認のデータを見ない。今のCopilotやほとんどのLLMエージェントでは、パターンはこうだ：ユーザーが質問 -> モデルが広く取得 -> センシティビティラベルをフィルターとしてチェック -> モデルが回答を生成。ラベルチェックは、データがすでにモデルのコンテキストに入った後に行われる。これがバグが起こる原因なんだ。ラベルシステムがあってもなくてもね。「今読んだことを無視して」とモデルに指示するのは信頼できない。実際に機能するパターンは、事前取得フィルタリングなんだ。モデルが必要な構造化クエリを出して、そのクエリが何かが返ってくる前に権限レイヤーで評価される。そして許可されたコンテンツだけがコンテキストウィンドウに入る。モデルは見てはいけないものを見えないように設計されている。DLPラベルアプローチは、生成時のフィルターで取得の問題を解決しようとしている。それはカテゴリエラーで、ラベル検出がどれだけ良くなっても、こういうバグを生み出し続けるよ。

問題は、機密情報がクラウドAIに送信されてしまって、DLPポリシーに違反してることだと思う。