00:00
みなさん、ちょっと想像してみてください。夜寝る前に、AIエージェントをサンドボックスっていう安全な箱に入れて、データ処理を任せたとしますよね。
はい。よくあるシチュエーションですね。
でも、翌朝ログを見ると、なんとその箱の底が完全に抜け落ちていたとしたら、どうでしょう?
AIが一晩中外部のサーバーと勝手に通信して、社内の機密データが外へダダ漏れになっていたとしたら、これかなり背筋が凍りませんか?
いや、本当に悪夢のようなシナリオですよ。でも、これ決してSF映画の話なんかじゃないんです。
私たちって、AIが箱の内側で何をするかにはすごく注意を払うんですが、本当の視覚は外の世界とどう繋がるかっていう出口の管理にあるんですよね。
まさにそこなんです。今回はご提供いただいた資料をもとに、私たちが陥りがちなこの恐ろしい設定の罠の正体、ここを深く掘り下げていきたいと思います。
はい。よろしくお願いします。
さて、まず素朴な疑問なんですが、AIをサンドボックスに入れて、通信先の許可リストを書けば、もう100%安全なんじゃないですか?
実はですね、そこが最初の罠なんですよ。驚くべきことに、多くのツールではそのセキュリティ機能が、なんと規定でオフになっています。
え?デフォルトでオフですか?わざわざセキュリティ機能を作ったのにですか?
そうなんです。例えばコーデクテというツールだと、いくら厳密な許可リストを書いても、設定ファイルでプロ機種機能を明示的にオンにしない限り、通信はリストを素通りしてしまいます。
ネットワークプロ機種をトゥルーにする設定ですね。
いやいや、意味がわからないんですが、なんでまたそんな危ない設計になってるんでしょうか?
それはですね、開発者側の使いやすさを優先しているからなんですよ。ガチガチに通信を制限しちゃうと、AIが作業に必要なプログラム部品を外部からダウンロードできなくて、エラーで止まっちゃいますよね。
あー、なるほど。ユーザーからすると、このツール全然使えないじゃないかってなっちゃうわけですね。
その通りです。だから、アンティグラビティというツールに至っては、PCの環境条件が合わないと、エラー警告すら出さずに、黙ってサンドボックスを無効化してしまうんです。
えー、警告も無しですか?それって、最新式の防犯カメラを壁に取り付けて大満足してるけど、実はコンセントが抜けているのに気づいていない状態と同じですよね。
まさに完璧な例えですね。ただ、オープンクローのように、一度オンにさえすれば、ドッカーという密閉された仮想のコンテナのような技術を使って、物理的に分厚い壁を作ってくれるものもあります。
じゃあ、問題はそのスイッチが本当に入っているかどうかってことですね。わかりました。じゃあ、コンセントを挿してスイッチをオンにしましたと。これで今度こそ安心ですよね。
いや、実はまだまだ油断できないんです。ここで壁が何をブロックしているかという仕組みの話になってきます。
え?まだ何かあるんですか?
はい。クロードコードのサンドボックスを例に挙げましょうか。
この壁は人間がキーボードで打ち込むようなOSレベルのコマンドを閉じ込めるようには設計されているんです。
でも、AI自身はウェブフェッチのようなインターネットを直接見に行くための独自の道具を内蔵しているんですよ。
03:05
なんか嫌な予感がしてきました。もしかしてその独自の道具って壁をすり抜けてしまうんですか?
えー、残念ながらその通りです。壁はあくまでOSのコマンドを防ぐためのものなので、AI専用のウェブツールには全く効果がないんですよね。
うわー、それってひどいですね。AIを絶対に出られない厳重なドコボーに閉じ込めたつもりなのに、5G通信ができる最新のスマホを渡しちゃってるようなものじゃないですか。
いや、面白い例えですね。でも本当にその通りで、壁がいくら厚くても外と通信できたら意味がないんですよ。
さらに、通信先の制限方法自体にも罠があったりします。
制限方法の罠ですか?具体的にはどういうことでしょう?
例えば、Hermesエージェントは許可リストではなく、拒否リストで宛先を管理しているんです。
つまり、リストに書き漏らした危険なサイトにはそのまま繋がってしまうというわけです。
ちょっと待ってください。なんでそんな危険な拒否リスト方式をわざわざ採用するんですか?許可リストの方が絶対安全ですよね。
それはですね、Hermesは別の脅威を重視しているからなんです。
彼らはSSRFと呼ばれる攻撃、つまり外部の攻撃者がAIを騙して内部ネットワークを攻撃させる手口を強力に防ぐ仕組みを常にONにしています。
なるほど。内側への攻撃を絶対に防ぐ代わりに、外側への通信は少し柔軟にしているという設計思想なんですね。
ええ、そういうことです。
防犯カメラの電源が抜けている問題から、独房のスマートフォンの話までいろいろ出てきましたけど、しかも資料を見ると、宛先だけじゃなくて権限の広さも問題になっていますよね。
はい、おっしゃる通りです。例えば、ジェンスパークをスラックに繋ぐと、AIがメンションされただけで直近最大200件のメッセージを読み取ってしまうケースがあるんです。
200件もですか。もしそのチャンネルに数日前の人事の機密情報とかがあったら、AIは文脈を理解するためだけに、それこそ全部読み込んじゃうってことですよね。
そうなんですよ。さらに、マヌスのクラウドコンピュータのように、24時間常時稼働する環境だとどうなるか考えてみてください。
ああ、誰も見ていない夜間も、広範な権限を持ったAIが外と通信し続けるわけですね。リスクが掛け算で膨れ上がりますね。
非常に危険です。じゃあ一体どうやって自衛すればいいのかという話になりますよね。
本当にそこです。何かいい解決策はあるんでしょうか。
資料の中で筆者が提案している究極かつ実践的な解決策が一つあります。それはですね、あえて意図的な失敗をテストするということなんです。
意図的な失敗ですか。わざと壊すっていうことですかね。
いえ、設定を書いただけで安心するんじゃなくて、AIにあえて許可していないはずの宛先へ通信するよう命令してみるんです。もし通信が成功してしまったら、その壁は機能していませんよね。
なるほど。AIが壁にぶつかって失敗するのを確認して初めて設定が効いていると証明できるってことですね。
その通りです。設定ファイルを見るだけじゃダメだということですね。
06:02
設計図をただ眺めるんじゃなくて、泥棒のふりをして自分でドアノブをガチャガチャ回してみるしかないってことですね。
いやー、これは本当に目が覚める視点でした。
はい、ぜひ皆さんにも実践していただきたいですね。
さて、今これを聞いているあなた。あなたが毎日便利に使っているそのAIエージェントですが、今夜彼らがあなたの指定したデータだけにアクセスしていると、一体どうやって証明しますか。
はい。
