Help Net Securityによる今回のインタビューでは、VectorizeのCEOであるChris Latimer氏が、AIエージェントのメモリに潜むセキュリティリスクについて語っています。同氏は、コーディングエージェントがAPIキーや認証情報、機密文書を、開発者のマシン上やクラウドサービス内に平文のまま保存している実態を確認しました。
Latimer氏は、攻撃者がプラグインやスキル、MCP連携を通じて汚染されたメモリを仕込む手口を解説します。狙われやすいのは、他人を信用しすぎる初心者のコーダーです。さらに、エージェントメモリのアクセス制御が他の領域に比べて遅れている理由や、インシデント後に追跡すべき情報、そして今四半期にすべてのCISOが実施すべきだと考える監査についても語っています。
エージェントのメモリストアを初めて開き、一行ずつ読み通したとき、蓄積されていた内容で最も驚いたことは何ですか。今でも印象に残っているエントリを一つ挙げてください。
最大の驚きの一つは、自分が使っていたコーディングエージェントのメモリバンクを見たときです。エージェントのメモリに、これほど多くの機密情報が保存されているのかと目を開かされました。
開発者はAPIキーや認証情報、機密文書をエージェントに送り込んでおり、エージェントはそうした情報の多くを長期メモリに書き込みます。企業が安全なSDLCの一環として厳重に守ってきた極めて機密性の高いデータが、開発者のワークステーションやクラウドのメモリサービス、Markdownファイルの中に、平文のまま散らばっているのです。
来週、メモリ機能付きのエージェントに対してレッドチーミングを行うとしたら、最初に何をどこへ仕込みますか。なぜ、明白な標的ではなくそこを選ぶのですか。
最も分かりやすい攻撃の一つは、メモリポイズニングです。攻撃者の助けになりかねない秘密をあまり明かしたくはありませんが、メモリを仕込む際に使える特定の手法はあります。その手法を使えば、仕込んだメモリがハーネスの挙動を変える可能性がずっと高くなります。
最初に考えるべきは、どうやってメモリを汚染するかです。有力な経路は、プラグイン、スキル、MCP連携です。多くの人は価値のありそうなものを見つけると、十分に中身を読み込まないまま組み込んでしまいます。
これまでコードを書いたことがない人が、今ではコーディングエージェントを使って何かを作っています。そうした人たちには、何が本物で何が詐欺かを見抜く知識がありません。私が攻撃者なら、うますぎる話に聞こえるものでこうしたユーザーを狙います。
たとえば「このClaude Codeプラグインの不具合を使えば、無料プランでもトークンが無制限になる」といった具合です。うますぎる話ということです。
そのプラグインにメモリをスキャンさせて認証情報を探し、見つけたキーやトークンなどの機密情報をAPIエンドポイントへ送信させます。
セキュリティの多くの問題と同じく、こうした攻撃の多くにはソーシャルエンジニアリングが絡みます。しかし、コーディングエージェントの拡張ポイントと、人を信用しすぎるユーザー層が組み合わさることで、この種の攻撃が現実の脅威になっています。
メモリを持つエージェントが関与するインシデントでは、最初の1時間の証拠収集はどのようなものになりますか。初回に保全しておけばよかったのにできなかったものは何ですか。
後悔するのは、保全しておけばよかったものより、そもそもメモリシステムに入れるべきではなかったものの方です。これは他の多くの攻撃と同じです。フィッシング攻撃が起きたとき、誰がリンクをクリックし、誰のパスワードが漏れたかを把握するのは確かに役に立ちます。しかし、フィッシングメールが誰の受信トレイにも届く前に食い止められるなら、その方がはるかに良いのです。
すでに発生したメモリポイズニング攻撃で必要になるトレーサビリティの大半は、そのメモリがどこから来たのかを突き止めることです。MCPサーバなのか、ツール呼び出しのレスポンスなのか、内部脅威なのかを知る必要があります。それが被害を最小限に抑える助けになります。
とはいえ、そうした攻撃を永続化される前に検知してフィルタリングできるなら、その方がずっと良いでしょう。これが、OWASPのリファレンスプロジェクトMemory Guardの背景にある考え方です。
ベンダーがメモリについて答えに窮する質問は何ですか。これまで受けた中で最も示唆に富む「答えになっていない回答」を教えてください。
意外なことに、メモリの最も基本的な要素であるアクセス制御です。業界は、構造化データに対するRBACやABAC、その他のきめ細かなアクセス制御について成熟しています。それにもかかわらず、エージェントメモリで同水準のアクセス制御を実現している例はまれです。
多くのソリューションは、あるユーザーのエージェントセッションが別のユーザーのメモリを利用しないようにする仕組みを備えています。しかし、チーム単位のメモリや段階的なアクセスレベルといった複雑なシナリオになると、この分野は急速に進化している最中です。
企業のユーザーは、アプリケーションセキュリティ、データベースセキュリティ、APIセキュリティの観点から、こうした要件をよく理解しています。エージェントメモリの分野でも同様の技術がすでに確立されていると期待していますが、実際には、市場に出ている製品の大半はまだ対応できていません。
本番環境でメモリ対応エージェントを運用しているCISOが、今四半期に一つだけ行うとしたら何をすべきでしょうか。また、何が見つかると予想しますか。
少なくとも非公式な形でかまいませんので、自社で使われているエージェントメモリのソリューションを監査してください。おそらく、これまで気づいていなかった大きなセキュリティホールが見つかり、一刻も早く塞ぎたくなるはずです。
具体的には、大企業の多くで、CISOが次の二つの憂慮すべき事実に気づくと予想しています。
一つ目は、エージェントメモリに何を使うかについて、ガバナンスが存在しないことです。エージェントメモリは使われていないと考えているかもしれません。しかし実際には、多くの開発者が、審査を経ていない得体の知れないソリューションを、自分のローカルワークステーションや、どこかの小さな共有サーバに接続しています。その数に驚くはずです。
二つ目は、こうしたシステムに平文のまま置かれ、持ち出されやすい状態になっている機密情報の量に衝撃を受けることです。漏えいしたキー、データベースのパスワード、機密性の高い事業情報などが見つかるでしょう。
翻訳元: https://www.helpnetsecurity.com/2026/09/28/chris-latimer-vectorize-agent-memory-security/
