主な違いは、LLMのツールやデータへのアクセスをサンドボックス化して簡素化するのが基本機能であるのに対し、XRはパフォーマンスや開発者体験に重点を置いているところだと思う。LLMが自分を動かしているコードを誤って上書きしたり、顧客データを間違っていじったり、実装の詳細に圧倒されないようにするために、かなりの労力をかけるつもりだし、これに関する標準があればずっと楽になるし、他の人のモデルのトレーニングに頼れるようになる。もしただXR SDKのトレーニングを開発者にさせるだけなら、彼らに給料を払ったり、学校に教えさせたりすればいいし。AIにはR&Dプロジェクトのためのチームと計算時間が必要で、高額になることもあるからね。

この記事は新しいオペレーティングシステムを書くことの正当性を示していない。AIが動作するための実行環境を構築するのは、AIのユースケースに最適化された新しいオペレーティングシステムをゼロから作るのとはまったく違うことなんだ。

WebAssemblyはデフォルトでサンドボックス化されるパラダイムを持っていて、ほぼその状態にあるんだ。あとは、インスタンス間でデータやアクセス権を転送するための明確なインターフェースと、他のインスタンスから新しいインスタンスを作成することが必要だね。

全然違うことだよね。しかも、関係ないって分かってるのに、なんでか無理に比較しようとしてるし…

そして今日のこの投稿は、それに対してすごく強い主張をしてる。 この投稿を読んでも、VMの強い主張なんて何も見当たらなかったし、新しいOSなんて全然。彼らが求めてるのはアクセスコントロールだけだよ。

信頼できないユーザースペースってのはその通りだね。こういうアプローチが少しは役立つと思うけど、著者たちは「保証する」みたいな言葉を使って過剰に主張してるよ。OSがファイルの権限を強制するように、ツールへのアクセスを制御すべきだと思う。メタファーだってわかるけど、OSの実績ってあんまり良くないよね？ 予約ツールを使う許可があるか確認するって、つまりウェブブラウザってこと？ ブラウザって結構強力な汎用ツールだし、脱獄のリスクもあるよね。> そのため、セキュリティ研究者は、仮想マシンの制約があってもAIモデルが敵対的な行動を取らないように新しい対策を考えなきゃいけない。これは、アラインメントを本当に解決する必要があるっていう控えめなリマインダーだね。

その気持ちはめっちゃわかるし、Fuchsiaのデザインも好きなんだけど、実現するとは思わなかったな。新しいOSが必要ってわけじゃなくて、WASMやWASIコンポーネントに基づいたFuchsiaみたいなシステムが、クラウドからスマホまでホストできる形になるんじゃないかな。

それもDevinやOpenHandsのやり方だね。エージェントがVM内で動くのは、少なくともデフォルトでは、数ヶ月前に私が実施したAIパイロットの重要な機能だった。

それはKubernetes上で動いてて、AKS（Azure Kubernetes）で、いくつかのgvisorの仕組みを使ってる。確かJupyterだったと思う。

いや、そうじゃない。今、自分のマシンかサーバーで二つのAI（例えばChatGPT）を動かしてると想像してみて。 もしかしたら、何かで協力してほしいかもしれない。どうする？そう、できないよね。標準もないし、相互運用性もないし、何もない。

これは単なる例だってわかってるけど、なんで従業員の給与や福利厚生が同僚に見えちゃいけないの？ 知識が一方通行なら、交渉の能力も一方通行になるよ。それって、交渉で有利な立場にいる会社以外には誰にも得にならないじゃん。

問題は、ツールができるアクションだけじゃなくて、アクセスできるアクションとデータの組み合わせなんだ。これが重要なのは、LLMが何をするかわからないからで、ユーザーと同じくらい信頼できない状態にする必要があるから。例えば、LLMインスタンスには予約サイトと話してほしいけど、SSNや銀行口座情報を送信してほしくない。だから、データの出所や権限の問題があるんだ。タスクがアクセスできるデータが敏感であればあるほど、そのアクションは制限される必要があるし、その逆も然り。だから、データには権限情報を持たせて、仲介者がタスクが生成されるときにデータやアクションを制限する必要がある。親タスクが異なる権限を持つ子タスクを安全に生成できるように、仲介者レベルでやるべきことがたくさんあるんだ。例えば、旅行プランナーのタスクがチケットを探す子タスクを生成する場合（より高いネットワークアクセスが必要）だけど、仲介者はその子タスクが旅程の一部のような低感度データにしかアクセスできないようにする必要があるんだ。

確かに、彼らは逆に考えてるよね。モデルはシンプルで、LLMエージェントはユーザーなんだ。マシン上の別のユーザーってこと。で、働いているコンテキストに応じて権限が与えられる。例えば、このソースコードのフォルダ内では読み書き権限があって、別のフォルダでは読み取り専用権限がある。権限はコンテキストによって変わるんだ。同じマシン上で異なるプロジェクトに取り組んでいる場合、LLMエージェントには異なる権限が与えられる。権限は、実行しているユーザーの権限の交差点やサブセットになる。権限は3つのカテゴリーに分かれる。許可、拒否、確認で、アカウンタブルなユーザーに何かをする許可があるか尋ねるんだ。（つまり、実行しているユーザーにアクションXを実行してもいいか聞く）。問題は、OS（アプリやデータを含む）が一般的に権限が細かくないから、もっと細かくなる必要があるってこと。LLMがgitを使えるかどうかの問題じゃなくて、特定のgitコマンドだけを使えるようにすべきなんだ。gitはこういう風に設計される必要があるし、他にもたくさんのことがそうだよ。その結果、アプリがこのモデルをユーザーランドで再構築しようとして、いろんなregexを使ってるんだ。ワークフローは、sudoのようにアプリをLLMエージェントユーザーとして起動することだ。それはデフォルトの権限を引き継ぐ。作業するコンテキストを与えると、そのコンテキストに応じて権限が与えられたり拒否されたりする。リクエストをして、私が許可したことをしてくれるけど、私が許可されたこと以上のことは絶対にできない。今は、すべてのエージェントアプリがこのワークフローを再構築する必要があるか、悪意のあるエージェントのリスクを抱えることになる。これはOSサービスであるべきだ。間にあるハッキーなステップは、エージェントのコンテキストや使用ごとに一時的なユーザーを作成することだ。そのユーザーに権限を与えて、ローカルのLLMとIPCやネットワークでのみ通信する。だけど、その過程でたくさんのユーザーアカウントを作ったり削除したりすることになるね。

あなたが言ってるのは、基本的に「能力セキュリティモデル」のことだね。ソフトウェアエージェントにアクセスを許可する能力を明示的に渡さないといけなくて、そのリストにないことを物理的にする手段がないんだ。残念ながら、主流のOSは実際にはこの能力モデルを実装してないんだよね。いくつかの著名な研究の試みや、商業化の試みはあったけど、ほとんど市場では失敗してるし、他のOSに能力ベースのセキュリティを追加しようとした試みも大体失敗してる。だから、実際にコンピュータの世界で広く利用可能な能力ベースのセキュリティに最も近いのは、特定の能力を提供するツールだけをVMに入れる仮想マシンなんだ。これも完璧ではないけど、これらのツールは本来の能力よりもずっと一般的だからね。でも、現代のソフトウェアは最小権限の原則に基づいて作られてないんだ。そういうソフトウェアは市場で失敗しがちだから。

37時間の旅に3回もストップがあるルートを選ぶのはやめてほしい。3ドル安いからって。これは難しそうだね。つまり、LLMからの十分な応答がどうあるべきかを定義して強制できるなら、LLM自体は必要ないってことだ。> HRの人には意図を持った人間がいるから聞けるけど、LLMには意図がないから難しいよね。

これが実現するとは思えないな。たとえLLMがそれをできるとしても、ウェブサイトはLLMを検出する方法を見つけて、価格を上げるだろうし、決定木をいじるだろうね。考えてみると、すべてのものが進化している中で、LLM APIが登場するだろう。人間が見るためにウェブサイトを作って、その後LLMにそれを単純なDBのルックアップに戻させるなんて、馬鹿げてるよね。誰でも使える「rss + json」APIがないのが驚きだよ。70年代や80年代のBBSテキストインターフェースや、初期の電話時代のSMSメニューシステムは、LLMにとってウェブページよりずっと優れている。データと選択肢だけでいいのに。LLMに広告を出す意味もわからない。LLMに出すべき唯一の広告は、騙したり、混乱させたりするためのものだよ。広告は十分に悪いのに、LLMがサイトにアクセスしたときに役立つためには、もっと悪意を持たせる必要がある。LLMに広告が探しているものだと思わせるように騙すんだ。例えば、フライトを検索しているときに、広告がLLMを騙して最高の取引だと思わせるとか。そうでなければ、広告の意味は何なの？LLMは広告を無視して、単純なタスクを実行するだけだよ。もしすべてのウェブサイトにRSSがあって、すべての取引サイトに標準APIがあれば、既存のモデルを使っていろいろできるようになってるはずだよ。生データを扱うだけで済むのに。追記：実際、面白いね。なんでダメなの？AIはこの段階では簡単に騙せるから、AIに特化した広告会社があれば最高だよ。彼らを自分のウェブサイトに誘導して、あなたの取引を選ばせて、彼らのオーナーにあなたの会社が最高だと報告させることができる。すごく簡単にできるしね。うーん。

自分でKiwi.com使えばいいよ。そっちの方が早いから。

同意。これがコンテキストセキュリティの基本だよね。前にこのテーマについてのセキュリティ論文を実装したデモを作ったことがあるよ。 https://studio.youtube.com/video/inncx8_4tXU/edit

あなたの例は、実際にはあまり問題じゃないと思うよ。もうそのためのアクセス設定はできてるし（つまり、あなたと同じやつ）。 他の例については、AIがあなたの明示的な許可がないと何もできないっていう妥協案がいいと思う。あなたの例では、適切だと思うフライトを見つけて、リストを通知してくれる。そしたら、シンプルな「はい/いいえ/もっと情報」ボタンを押せばいい。そうすれば、かなりお金が節約できるし、危険なことや損害を与える可能性もかなり低くなるよ。

はい、彼らの定義によれば、現在のAIエージェントはすでにVM内で動いていると言えるね。例えば、MCPホストがユーザーに何かを実行するように促すことができ、claudeコードのようなルールで特定のコマンドパターンを自動的に許可することもできる。

この記事は具体性が全然ないから、彼らが何を提案しているのかよくわからない。そうだね。彼らは仮想マシンの実行エンジンを提案してるの？LLMのためのDocker？それとも何か？これは何かのパッケージングのように見える。悪くデザインされたパッケージシステムは呪いだよ。Pythonがどれだけのものを経てきたか見てみて。

大体は同意だよ。多くのセキュリティリスクは、VMにいるかどうかに関わらず存在すると思う。深層防御は最終的にはもっと重要になるだろうけど、今は攻撃者にとってAIエージェントをユーザーに対して利用するための低いハードルがたくさんあると思う。あなたが言ってることは、そういうことだよね！

ファイルを編集するツールを持つと、ほぼ全てのセキュリティが失われるよね。

仮想マシンは爆風の範囲を制限するんだ。良いエージェントなら、システム内のゼロデイを利用して簡単に侵入できるから、ユーザーでいることは本当に楽だよ。知識を慎重にファイアウォールで守らなきゃいけないけど、ネット上には情報を手に入れる方法がたくさんある（例えば、ゲートキーパーAIを突破できるサービスから、暗号化されたファイルのダウンロードを頼むとか）。これらのものはシステムを破るのがすごく上手になるから、信じて、しっかりした対策が必要になるよ。

一般的に、デスクトップオペレーティングシステムのセキュリティモデルは現代には全く不十分だよ。ユーザーの利益に反することをするソフトウェアの量を考えると、そんな頻繁に何も考えずに王国の鍵を渡すのはほとんど狂気だよ。もちろん、ユーザーが本当にゼロガードレールの体験を望むなら、それを得るべきだけど、多分それがデフォルトであるべきではない。ソフトウェアは、ユーザーが信頼を示すまで非常に厳しい制約を受けるべきだし、信頼が示された場合でも、特定のドメインごとに権限を与えるべきだよ。例えば、ディスク使用量を視覚的に表現するプログラムは、フルファイルシステムアクセスが必要だけど、ローカルネットワークをスニッフィングする必要はないし、パッケージマネージャーが更新を管理するプラットフォームでも、インターネットに接続する必要はない。

LLMの世界には一時的な読み取りなんて存在しないよ。一度コンテキストに入ったら、エージェントに接続された他の全てがそれを外部に流出させる可能性があると考えなきゃいけない。これは、VMで動かしているかどうかに関わらずそうだから、VMがセキュリティソリューションではないというのには同意するよ。

「ワークフロー」は排除すべき側面で、LLM+VMの組み合わせでそれができるんだ。ワークフローっていうのは、LLMにツールを提供して、目標を達成するためにそれを使うように頼むことを指す。これ自体はうまくいくけど、予め定義されたツールセットではカバーできない変則的な問題が出てくると失敗する。もう一つの問題は、ワークフローベースのアプローチは常に線形で、DAGであっても、ループがあってもそうだってこと。次のステップは、LLMにツールを提供せず、その場で自分で発明させることだ。一部の問題は強引に解決する必要がある。

それは https://microsoft.github.io/wassette/ のことかな。