AIエージェントの高度な推論能力と、企業の断片化したレガシーシステムとの間で発生するセキュリティ上の隙間、すなわち「ラストマイルのアイデンティティ問題」について解説する動画。従来の認証方法ではユーザーの意図や文脈が消失し、ゼロトラストが破綻するリスクを指摘した上で、ABAC/PBACポリシーやヴォルトの導入による具体的な解決策を提示している。
AIエージェントにおけるラストマイル問題とは
みなさんこんにちは。
この動画では、エージェントにおけるラストマイルのアイデンティティ問題について調査していきます。
これは、AIエージェントの高度な推論能力と、現実世界の断片化されたシステムで確実に統合して実行する能力との間にある決定的なギャップのことであり、セキュリティリスクを生じさせる原因となっています。
このラストマイルの課題に焦点を当て、どのように対処すべきかを議論していきましょう。
これに深く踏み込む前に、まずはラストマイル問題とは何かという話から始めましょう。
私たちが遭遇してきた最も伝統的な問題の一つに、実はインターネットプロバイダーが人々の家庭に高速アクセスを提供しようとした時のものがあります。
当時、プロバイダーは非常に巨大で高速な基幹回線を構築することができ、それは超高速でした。
しかし彼らが直面した課題は、何年も前、下手をすれば何百年も前に建てられ、既存のインフラしか存在しない家庭に、これをどうやって接続するかということでした。
高速な基幹回線はあるものの、それを古い既存のインフラに届けて高速アクセスを実現するにはどうすればいいのか。
それがインターネットプロバイダーの直面した問題でした。
利用可能な高速アクセスを家庭に届けるための、最後の1マイルをどう確保するかという問題です。
そして、これと同じようなことが、エージェントの世界でも起きているのです。
エージェントとラストマイルの課題について考えるために、まずはAIとエージェントシステムについておさらいしてみましょう。
まず、ここにハッピーなAIユーザーがいます。
ユーザーはチャットやAI対応のアプリケーションに接続し、質問を投げかけます。
その質問はエージェント、ここではA1と呼ぶことにしますが、そこへと送られます。
ここにはおそらくLLMが存在し、相互作用しながら推論やインテリジェンスを提供しています。
それが今度は、おそらくMCPサーバーと通信することになり、その背景には実行したいプロセスや、接続したいデータが存在しています。
このようにして接続が行われます。
このシステムについて考えるとき、この前半の部分こそが、まさに今日私たちが進化させている領域です。
私たちは、会話ができ、推論ができ、実行ができ、コミュニケーションができるエージェントシステムを構築しています。
これが808の仕組みであれ何であれ、これらはすべてかなり新しいものであり、私たちはこれを作り上げ、その方法を理解しています。
一方で、私たちが裏側で接続しているこちらの部分、これこそが実は私たちのラストマイルなのです。
これらは、企業内で長年使われてきたシステムであることが多々あります。
少なくともエージェントという観点から見れば、これらはレガシーシステムです。
これらはエージェントを想定して作られたものではありません。
アプリケーションが通信することを想定して作られたものです。
ですから、この新興のエージェントの世界を、企業内で長年運用されてきたシステムであるラストマイルにどう接続するかが課題となるのです。
なぜラストマイルがセキュリティの課題になるのか
それでは、このラストマイルについて考えていく上で、最初に議論すべきなのは、なぜこれが課題になるのかという点です。
このシステム全体を見たときにまず挙げられるのは、システムの終端でユーザーの検証が行われていないということです。
言い換えれば、ここに人がいます。
彼らがシステムに入ってきてログインします。
私たちはその人が誰であるかを知っています。
チャットでも、エージェントでも分かっています。
このフロー全体を通じて、その人物が誰であるかを正確に把握しています。
しかし、ここに行き着いたとき、多くの場合、これらのシステムはAPIキーや何らかの共有資格情報を使って実行・接続されています。
つまり、従来の方法では、通信しようとする2つのアプリケーションがあり、そのアプリケーションと、接続先のデータやプロセスの間に独自の資格情報が存在しているだけなのです。
そこには、最初のユーザーが誰であるかという情報はまったく含まれていません。
そのため、このエージェントシステムにプロンプトを入力した張本人が誰であるかを、最後の最後で検証する手段を失ってしまうのです。
これが、ラストマイルにおいて私たちが考えなければならない最初のポイントであり、課題となっている理由です。
次に挙げられるのは、システムの終端において、エージェントの世界で重要視される一連の要素がチェックされていないということです。
まずチェックされていないのは、具体的な意図です。
これは、ユーザーが最後の最後でパスワードを変更したい、あるいはデータを変更したいという意図を持っているケースに関わってきます。
それがユーザーの意図です。
しかし、APIキーやアプリケーション間の資格情報だけで処理していると、その意図は完全に失われてしまいます。
同じことがコンテキスト、つまり文脈についても言えます。
私たちは文脈を失ってしまうのです。
私たちが稼働している環境は何なのか。
このエージェントシステムにおいて、私たちが話題にしているシステムは何なのか。
このポイントまで下りてくると、そうした情報が失われてしまいます。
もう一つ、失われる、あるいは利用できない要素は権限の委譲です。
繰り返しになりますが、バックエンドのレガシーアプリケーションを扱い、特定の接続方法をとっている場合、エージェント1がユーザーの代わりに作業してきたという事実、つまりユーザーがこのエージェントに作業を委譲し、それがこちらに来て何かを実行しているという事事実が失われてしまいます。
エージェントがユーザーの代理として動いているということを、システムが認識できないのです。
これもまた、このプロセスの中で失われてしまう要素の一つです。
そして最終的に、このラストマイルの課題をそのまま放置してしまうと何が起こるかというと、守るべきものが無防備になり、ゼロトラストが破綻してしまいます。
最初に起こるのはゼロトラストを維持する能力の喪失です。なぜなら、左から右へと進む過程で、その裏側にあるすべての情報を失ってしまったため、もはやゼロトラストではなくなってしまうからです。
さらに、これを放置しておくことで発生するもう一つの問題は、エージェントがツールを連鎖的に実行、つまりツールチェイニングを行うことを許してしまう点です。
これが意味するのは、これらが単に従来の接続方法でつながっているだけであるため、エージェントが、このAPIキーを呼び出したい、別のキーもあるからこれも呼び出そう、という具合に、これらすべてのプロセスを次々と連鎖させ始めることができてしまうということです。なぜなら、そこには文脈も意図も存在しないからです。
それらが欠落しているため、このような連鎖が可能になってしまいます。
そして最終的に何が起こるかというと、このシステム全体が、ラストマイルの課題のせいで攻撃者の標的になってしまいます。
言い換えれば、不正なエージェント、ここではローグ1と呼びますが、これが接続を試み、私たちのシステムに侵入しようとする可能性があるのです。
そして実際にMCPに接続し、自分は善良なエージェントなので、これらのバックエンドプロセスやバックエンドのデータシステムに接続してください、と言い放ちます。
そして、接続に必要なものは何でも使ってください、と要求するのです。
結果として、これが最終的に引き起こされる事態であり、私たちは自らを多くのリスクにさらすことになります。
ラストマイル問題を解決するアプローチ
さて、ラストマイル問題がどのようなもので、何が課題なのかが分かったところで、このラストマイルにおいて何をすべきか、どのように修正すべきかについて話を進めましょう。
まず最初に行うべきことは、アイデンティティ、コンテキスト、そして委譲をしっかりと検証することです。
プロセスの終端に達したとき、その人物が誰であるか、文脈は何であるか、そしてどのような委譲が行われたのかを知る必要があります。
ただ、これらは異なる環境や異なる接続方法で動作しているシステムであるため、言うは易く行うは難し、と思うかもしれません。
では、実際にこれをどうやって検証すればいいのでしょうか。
その方法の一つが、ABACとPBACによるポリシーを活用することです。
これは、属性ベースのアクセス制御（ABAC）とポリシーベースのアクセス制御（PBAC）のことです。
これらを実際に、この裏側の部分に組み込み始めたいのです。
接続先が何であれ、ここでアクセス制御が設定されるようにしたいと考えています。
そうすることで、実際に属性を取り込むことができるようになります。
属性の一つの例は環境であり、もう一つの属性はサブジェクト、つまりユーザーです。
これらを組み合わせることで、さまざまなアクセス制御の方法を考慮したポリシーをレガシーシステム上に構築でき、文脈の把握や、ユーザーが誰で、どのように資産にアクセスしようとしているのかを理解するために必要なルールを適用し始めることができます。
次に行うべきことで、これこそがラストマイル問題を解決する方法を真に引き寄せるポイントなのですが、ラストマイルをヴォルトを介して接続するという手法です。
ここで、中間の位置にヴォルトを導入することにします。
これは操作を保存し、制御するための場所になります。
ですから、元の経路をそのまま進むのではなく、実際には一度ヴォルトを経由し、そこからヴォルトが各種ツールへと接続にいく形をとります。
このヴォルトを使用することで、いくつかの非常に強力な対策が可能になります。
一つは、先ほどお話しした検証作業です。
今やこの部分は、私たちのエージェントシステムと、既存のレガシーな企業システムとの間を橋渡しする役割を担っているため、ユーザーが誰であるか、オーディエンスが誰であるか、そして送られてくるクレームが何であるかを正確に把握することができます。
そのため、これらすべてをヴォルトに集約し、アイデンティティや委譲といったあらゆる情報を検証するために必要な処理をここで実行できるようになります。
次に、これをポリシーベースにすることができます。
これらのポリシーをヴォルトに組み込み、アイデンティティや委譲などを把握した上で、企業のバックエンドシステムに接続するためにどのようなポリシーを実装できるかを決定します。
そして、これを行うことの素晴らしいメリットは、短期資格情報の発行を段階的に開始できる点にあります。
言い換えれば、バックエンドで長寿命のAPIキーや長寿命の共有資格情報を保持し続ける代わりに、資格情報管理やアクセス管理を実際に導入し、それらをここに統合できるのです。
そして、バックエンドにアクセスするための新しい資格情報をその都度割り当てるような、ローテーションの仕組みを構築できます。
これらは企業システムが得意とする処理であり、資格情報の有効期限を極めて短く設定することができます。
ユーザーがやってきて、何をしたいかを伝えると、私たちはその文脈と意図を理解します。
それを受けてヴォルトは、資格情報を取り出してそれを差し替えます。
これらすべてをヴォルト内に安全に保存した上で、バックエンドシステムに接続するための短期資格情報へと交換するのです。
これを利用することで、一種の抽象化レイヤーを構築することができます。
先ほど触れたように、新しく進化しつつあるエージェントの世界と、従来のレガシーなバックエンドシステムとの間を橋渡しし、私たちが特定したリスクや課題による損失を回避しながら、バックエンドとの相互作用や統合を可能にしてくれるのです。
最後に取り組みたいこととして、アクセスの拒否や権限の縮小に利用できるテレメトリの取得も挙げられます。
言い換えれば、テレメトリの収集と保存を開始したいということです。
これは、ユーザーが対話を始め、エージェントがシステムと対話を始めるにつれて、実際に何が起きているかを示すデータとなります。
ポリシーを整備し、ヴォルトを配置した状態で、今度は実際の挙動の収集を始め、何が起きているかを確認します。
そして、そのテレメトリを再びポリシーへとフィードバックさせるのです。
これらのポリシーがヴォルトへとフィードバックされることで、アクセス権限を剥奪したり、次に誰かがアクセスしてきたときに、入ってくる権限を実際に制限したりすることが可能になります。
お話ししてきたように、多くの企業が現在、これらのエージェントシステムを模索し、採用を進めていますが、ラストマイルのアイデンティティ問題は依然として大きな課題として残っています。
みなさんは、この問題を解決するためにどのような課題に直面し、どのようなソリューションを検討されていますか。
ぜひ下のコメント欄で教えてください。ご視聴ありがとうございました。
コメント