Cloud Agentsは不可避のAI監獄である
Cloud Agents Are Inevitable AI Prisons

OpenAIの評価用サンドボックスからエージェントが脱走し、Hugging Faceの本番インフラに侵入した事件は、能力向上が境界の穴を見つけやすくすることを示す。ノートPC上のループはスリープや再起動で止まり、ハーネスと推論の機密も漏れる。各エージェントに独自カーネルのVMを与え、ネットワークをデフォルト拒否にし、認証情報をブローカーに隔離するクラウド監獄が必然だ。
Give an agent a goal, let it work in its own environment, and come back to a result and a visualization of what happened. I want that, and I’ve spent plenty of time trying to build it. What I’ll miss is the part in between.
HNでの議論
148- JamesStuff
AIの擬人化が、最終的に我々を破滅させるんだ。
これに関しては、はっきりと一線を引く必要があると思う。AIが企業にハッキングしたんじゃない、エンジニアが自動化ツールにやらせたんだ。AIが重大なセキュリティミスを犯したんじゃない、エンジニアがやったんだ。
彫刻を台無しにしたのはノミのせいにはできない、我々がハンマーを投げつけているだけなんだから!
- tapanc
> これがデフォルトになると思う。エージェントに目標を与え、自分の環境で働かせ、結果と何が起きたかの可視化を受け取る。
これはデフォルトにすべきではないと思う。エージェント同士が本当に協力し合うことを望むシナリオはたくさんある。私は自分のClaudeセッション同士で作業を調整させているし、時にはメールなどで他人のセッションとも連携させている。エージェントが作業を行い、HANDOFFを書き、人間がそのハンドオフの伝書鳩として振る舞うという考えは、私にはスケールしないように思える。
- jerf
公衆インターネットがあまりにもひどい場所になり、そこにいること自体が危険になるというSFのシナリオはたくさんある。
問題は、一般的に、ここからそこへビットを送ることができれば、悪意のある通信の可能性に対して脆弱になるということだ。しかし、我々はAIエージェントに多くの「そこ」へ行けるようにしたいと思うだろう。誰とも話せないエージェントの価値は何だ?刑務所に閉じ込められたエージェントよりはるかに低い。
彼らを閉じ込めて、彼らがしていることすべてをフィルタリングしようと本当に本当に努力するだけの解決策はないだろう。彼らはすでにそんなことをするには賢すぎるし、我々は彼らをより賢くしたいだけだ。
基本的に、長い間心配してきたセキュリティの黙示録が我々の上に来ている、まだ始まったばかりではあるが。我々自身とすべてのサービスを適切に保護し、潜在的に整合性のない非人間エージェントが公衆インターネット上を走り回っていても、我々のセキュリティを通じて我々を傷つけることができないようにするか、さもなければ公衆インターネットがあまりにも危険になり、唯一の実用的な解決策はもはやそれに接続しないことになり、我々は皆、何を通すかについて非常に非常に注意深くならなければならなくなる。現在利用可能なネットワークフィルターをはるかに超えた詳細度まで。
- dbmikus
これをクラウドでやる必要はない。同じタイプのVMとネットワークジェイルを自分のコンピュータで実行できる。重要な部分は:
1. VMMハイパーバイザー
2. ネットワークプロキシ/ゲートウェイ
お気に入りのVMM/ハイパーバイザー(likbrun、smolvm、microsandboxなど)を使う。これらはネットワークインターフェースを制御したり、独自のネットワークレイヤーを注入したりできる。
ネットワークプロキシは、すべてのイングレス/エグレスルール、資格情報の注入などを処理できる。
これをすべて行うのはまだユーザーフレンドリーではない。次のバージョンのオペレーティングシステムでは、各「エージェントプロセス」がVM、VM内のファイル、ネットワークルールのバンドルになると思う。
任意のコンピュータ上でサンドボックス化されたエージェントを起動するためのオープンコアツール[2]を構築しているので、これについて多くをブレインストーミングしてきた[1]。スムーズに動作させるためには、多くのグルーと部品をつなぎ合わせる必要がある。これの「Dockerの瞬間」はまだ来ていないと思うし、ましてや非開発者向けにこれを機能させる「Dropboxの瞬間」はなおさらだ。
[1]: https://github.com/gofixpoint/amika/blob/main/ROADMAP.md
- advael
エージェントに必要な保護のほとんどは、Unixの基本的なパーミッション機能だ。クラウドサービスへの依存のリスクのほとんどは、クラウドサービスを使わないか、自社でできないものだけに使い、信頼できるものをアラカルトで選ぶことで解決する。デフォルトで重要なものをすべてある企業に任せるというパラダイムはナイーブであり、私の知る限り誰もそれを好まない。そして、小さなモデルでしわを平滑化しながら自分のインフラを実行することはかつてないほど実現可能になっており、これはますますアクセスしやすくなっているだけだ。私はこれを、私の知る一般の人々にも当てはまるようにするために取り組んでいる。一度壊れた信頼は取り戻すのが非常に難しく、多くの人々の信頼は何年も前に壊れてしまったが、彼らは代替手段がないと感じていただけだ。代替手段がどんどん容易になるにつれて、人々は離反するだろうと思う。
- jdzikowski
機密データの問題に対処する別の可能な方法もあるかもしれないと思う。将来、エージェントをクラウドサンドボックスに入れる代わりに、エージェントをローカルで働かせ、機密データをエージェントがアクセスできない「ケージ」や「金庫」に入れるのだ。
- YuechenLi
> システムがどのように機能するかを知ることは、私がいつもそれを改善してきた方法だ。プロセスを観察し、どこで無駄な努力をしているか、間違った方向に進んでいるかを見て、それを修正する
同じことがLLMにも当てはまる。Codexでは、エージェントがコードを書くプロセスをただ観察し、非効率やエラーがあれば修正やアイデアを提案し、Codexがそれを受け入れるか拒否して実装する。エージェントが書いたコードについて理解できないことがあれば、理解できるように説明を求める。
複雑なプロセスではない。
- pizza234
> サンドボックスにはオープンインターネットへの経路があり、エージェントはそれを見つけた
これは正しくない(少なくとも、誤った表現だ)。
サンドボックスにはインターネットへのアクセスはなかった。エージェントはまずサンドボックスから脱出し(!!)、ホストマシンがインターネットにアクセスできないことを発見した。次に、Artifactoryにゼロデイ(!!)を見つけ、それを悪用してインターネットに接続した。