エージェントが私のパソコンを借りたいと言う。どこまで権限を渡すべきか
前回の「ターミナル信頼スペクトラム」は、こう結んだ。エージェントが本当に放たれる日、誰もがまず問うのは——それは何に触れられるのか、だと。今回はその問いの裏側に答える。エージェントがあなたのパソコンを借りたいと言ったとき、どこまで権限を渡すべきか。
OpenAB Connect のエージェントはリモートのサンドボックスで動き、本来あなたのパソコンには触れられない。それでも触れてほしい場面はある。画面を見てどこがおかしいか教えてほしい、ブラウザでフォームを埋めてほしい、Mac で Xcode のビルドを一度走らせてほしい。そのときあなたは Connect か Remote からパソコンを貸し出す。期間を選び、プロファイルを選ぶ。プロファイルが、エージェントの手に渡るものを決める。
直感的な答えは間違っている
まず思いつくのは「コマンドを実行させなければ安全だ」という考えだ。見る、クリックする、入力する、そこまでは許して、シェルだけは渡さない。
問題は、デスクトップを操作できればシェルがあるのと同じだということだ。
osascriptはdo shell scriptを実行できる。keyはターミナルに文字を打ち込める。mouseはターミナルを開ける。
AppleScript の中身をフィルタしても塞げない。JXA の doShellScript、
ObjC.import から NSTask、Terminal の do script、System Events
のキー入力。入口が多すぎる。「コマンドを実行させない」は便利な入口を一つ減らすだけで、権限は何も減らない。
私たち自身がそこでつまずいた
つい最近まで、自分用の owner 以外の選択肢は sandbox という名前だった。中身は owner から exec を抜いただけだ。
この名前は間違っていた。サンドボックスではなく、シェルと同等だった。sandbox と名乗りながらシェルを渡す選択肢は、選択肢がないより悪い。安心して貸してよいと思わせてしまうからだ。だから捨てた。sandbox は実際にできることに合わせて desktop に改名し、本当の境界として observe を加えた(#45)。
三つの選択肢、それぞれで渡すもの

| プロファイル | シェルと同等? | ツール数(macOS / Linux) | 渡すもの |
|---|---|---|---|
observe | いいえ | 2 / 2 | 画面とシステム情報。それだけ |
desktop | はい(GUI 経由) | 20 / 20 | デスクトップ、つまりシェル |
owner | はい(直接) | 42 / 37 | すべて。自分の CLI 用 |
desktop は macOS では exec を持たないが、マウス、キーボード、AppleScript
は持つ。Linux では bash をそのまま残している。mouse と key
でどうせターミナルを開けるのだから、bash を隠してもエージェントが不便になるだけで権限は減らない。だから、減ったふりはしない。ツールの完全な一覧は
tool-profiles.md にある。
なぜ「見る」だけが境界なのか
observe のツールは sys_info と screenshot の二つだけだ。入力も、クリックも、コマンド実行も、状態の変更もできない。境界として成り立つのは、次の三つによる。
- denylist ではなく allowlist であること。今後追加されるツールは、ローカルでもブラウザでも、誰かが明示的に加えるまで
observeでは拒否される。 - 名前が能力を表していること。
observeは「見る」、desktopは「デスクトップを操作する」。何を取り除いたかで名付けるのはやめた。 - ルールがドキュメントではなくテストにあること。
ProfileBoundaryTestsがすべてのプロファイルを検査し、シェルより狭いと称しながらシェルに届くツールを一つでも許すものがあれば CI が落ちる。
限界もはっきり書いておく。スクリーンショットは画面に映っているものを明かす。
observe が保証するのは「手を出せない」ことで、「何も見えない」ことではない。貸す前に、見られたくないウィンドウは閉じておこう。
もう一つ。observe が守るのはあなたのパソコンであって、エージェントではない。スクリーンショットはエージェントのコンテキストに入るので、画面に悪意あるページやメッセージがあれば、その文字がプロンプトインジェクションになりうる。パソコンには手を出せなくても、エージェントは
pod の中に自分のシェル、既定で開いた外向きインターネット、そのセッションが持つ認証情報(git など)を持っていて、読んだものをどこへでも送れる。
ブラウザは別に考える
owner には 32 個すべてのブラウザツールが見え、desktop には 15 個だけが見える。移動、読み取り、クリック、フォーム入力だ。外したのは、任意の JavaScript を実行できる
browser_evaluate と browser_run_code_unsafe、ファイルのアップロードと
PDF、ネットワークの監視、座標指定の生のマウス操作などだ。
ただし、狭めたのはツールであって、ブラウザそのものではない。そのブラウザはこのパソコンの永続プロファイルを使う。ログイン済みサイトの cookie はそこにあり、このパソコンから届くネットワーク、localhost や tailnet にも届く。
では、どれを選べばいいのか
- 既定は「見るだけ」。「ちょっと見て」という依頼の多くは
observeで足りる。次の Connect ではobserveが既定の選択肢になる(未公開)。 - 手を動かさせるなら、専用のパソコンを貸す。Linux の hands node、使い捨てのマシンや VM であって、今作業しているパソコンではない。
desktopを選ぶことは、貸出期間中ずっと、そのパソコンのデスクトップユーザーのシェルを渡すことだ。 ownerは自分のために取っておく。自分の CLI から自分のパソコンにつなぐためのものだ。
アップグレードの前に
今回は破壊的変更だ。instance-mcp v0.7.0 から:
sandboxは拒否される(HTTP 400)。黙って別の層に読み替えることはしない。- Connect と貸し出すパソコンは一緒に更新する。古い Connect が送る
sandboxは新しいパソコンに拒否され、新しい Connect が送るdesktopやobserveは古いパソコンに拒否される。Connect がまだ古いなら、パソコンを v0.7.0 に上げるのは待とう。 - 古いビルドが保存した
sandboxの貸出は、新しいビルドが読み込むときに破棄される。もう一度貸し出してほしい。
背後にある原則は一つだけだ。知らないプロファイルに出会ったら貸出を終わらせる。決して
owner に広げない。
なお v0.6.7 から、貸し出したパソコンはデーモンが再起動しても自動でつなぎ直す(macOS と Linux)。デプロイやクラッシュのたびに貸し直す必要はもうない。
次に来るもの(開発中)
browser層:ブラウザツールだけを持ち、貸出ごとに使い捨てのブラウザプロファイルを使う。境界はブラウザ自身が担う。- 型付きのアプリ操作:汎用の
osascriptの代わりに bundle ID の allowlist を使い、Terminal、Script Editor、System Settings は除外する。 - カスタムポリシー:貸出時に allow / deny リストを渡す。これも「シェルと同等か」の検査を通す。
- 使い捨ての macOS VM を貸し出す:ホストそのものではなく。
名前はインターフェースの一部だ
前回、最初に問われるのは「何に触れられるのか」だと書いた。エージェントがパソコンを借りたいと言うとき、その答えは、あなたが選ぶプロファイルの名前に書いてある。だから名前は本当のことを言わなければならない。sandbox はできないことを約束していた。私たちはそれを
desktop に置き換え、本当に見るだけの選択肢をもう一つ用意した。