AIエージェントを端末で使う企業が知っておきたい隔離用OSS「Agent Safehouse」の要点

「開発者が自分の端末でAIエージェントを動かしているが、どこまで触れられるのか誰も把握していない」「承認の確認を毎回出すと仕事にならないと言われ、確認を省く設定を止めきれない」——開発部門にAIエージェントが広がった企業の、情報システム担当者がよく口にする悩みです。こうした悩みは、エージェントの性能や設定の問題に見えます。しかし本当の問題は、エージェントが利用者と同じ権限で端末全体に手が届く状態のまま、仕事をさせていることです。この記事では、macOSの端末で動かすAIエージェントの読み書きの範囲を必要な分だけに絞るOSS「Agent Safehouse」を取り上げ、一次情報で確かめられる仕組みと限界、企業として使うときの使いどころと注意点を整理します。導入や設定の手順は扱いません。

Agent Safehouseとは何か。2026年10月時点で確かめられる事実

Agent Safehouseは、GitHubで公開されているOSSです。リポジトリの説明は「手元のAIエージェントを隔離し、必要なものだけを読み書きできるようにする」、READMEの冒頭は「macOS上の、プログラムを書くAIエージェントを隔離し、本当に必要なファイルと連携先にだけ触れられるようにする」です。つまり、AIエージェントそのものではなく、エージェントを外側から囲い、触れられる範囲を決める道具という位置づけです。

配布の形を確かめます。リポジトリは個人のアカウントで2026年2月9日に作られ、ライセンスはApache-2.0です。2026年10月18日時点でスターは2,110、派生は118、最後の更新は10月17日でした。作者のアカウントは2009年11月に作られ、公開しているリポジトリは26件あります。一日あたりのスターの伸びは約8.4件で、作ったばかりのアカウントが急に注目を集めている形ではないことが分かります。

中身は、シェルのスクリプトと、macOSの隔離の仕組みに渡す規則の部品の集まりです。貢献者向けの文書によると、規則は段階ごとに番号を振った部品に分かれ、それを組み立てて一つの規則にします。配布は、一つのファイルにまとめたスクリプトと、パッケージ管理の仕組み経由の二通りです。公開されている版は17あり、最初の0.1.0版が2026年3月11日、最新の0.12.0版が9月7日でした。半年ほどの間に版を重ねてきた、若いOSSだと言えます。

なぜ手元の端末で動くAIエージェントが問題になるのか

プログラムを書くAIエージェントは、ファイルを読み書きし、コマンドを走らせ、外のサービスに問い合わせます。端末で動かす場合、エージェントは起動した利用者と同じ権限を持ちます。公式の説明は、この点を脅威の出発点に置いています。悪意ある指示の紛れ込み（プロンプトインジェクション）や、権限を持つ者が他者に利用される形の誤動作、あるいは単純に誤ったコマンドによって、サーバー接続用の鍵、クラウドの認証情報、無関係なリポジトリ、個人のファイルにまで手が届きうるという整理です。

多くのエージェントには、操作の前に利用者へ確認を求める機能があります。ところが確認が多すぎると作業が止まるため、確認を省く設定で使う開発者も少なくありません。実際、Agent Safehouseの公式サイトや導入の解説にも、エージェント側の確認を省く設定と組み合わせた例が載っています。その場合、端末側の隔離が、事実上ただ一つの歯止めになると公式の文書も認めています。

企業の立場から見ると、問題は個々の開発者の注意力では片づきません。端末には、社内システムへの接続情報や、別の案件の資料が並んでいます。エージェントの判断が一度でも外れたときに、影響がどこまで広がるかを端末の仕組みとして区切っておくことが、この種の道具が求められる理由です。

仕組み：macOS標準の隔離機能で「すべて拒否」から始める

Agent Safehouseは、独自の隔離の仕組みを作っているわけではありません。READMEと公式の文書によると、macOSに標準で入っている隔離の仕組み（Apple が用意したサンドボックスの機能）に、組み合わせ可能な規則を渡して使います。考え方は「まずすべてを拒否し、エージェントが役に立つ仕事をするのに必要な分だけ許す」です。

公式サイトは、この制限がOSの中核（カーネル）の段階で効くため、許されていない操作はファイルに触れる前に失敗すると説明しています。エージェントが端末全体を消すような命令を走らせても、許されていない場所では「操作は許可されていません」として止まる、という例が示されています。また、エージェントが起動した子のプロセスにも同じ規則が引き継がれます。エージェント本体だけでなく、そこから呼ばれた道具にも同じ線が引かれる点は、運用上の意味が大きいところです。

比較の文書では、Agent Safehouseの方式を、仮想マシンやコンテナとは別の「端末上のプロセスに規則をかける」方式と位置づけています。端末のOSの中核は共有したままなので、負担はごく小さく、普段使っている道具やエージェントがそのまま動きます。その代わり、仮想マシンほど強い壁ではないと、文書自身がはっきり書いています。

初期状態で読み書きできる範囲と、閉じられる範囲

公式の文書「初期の前提」には、何が開いていて何が閉じているかが細かく並んでいます。企業の担当者が押さえておきたい部分を、表にまとめました。いずれも2026年10月18日に確かめた文書の記載で、版によって変わる可能性があります。

区分	初期状態	補足
エージェントを起動したフォルダ	読み書きできる	親にあるリポジトリまで自動では広げない
システムと開発用の道具の場所	読める	シェルやコンパイラ、パッケージ管理の動作に必要な範囲
ホームフォルダの中身	閉じる	一覧の取得や中身の読み取りは、個別に許したものだけ
サーバー接続用の秘密鍵	閉じる	接続先の設定と既知の接続先の記録は読める
ブラウザの閲覧データ	閉じる	クッキーやログイン状態を含む
鍵束（パスワードの保管庫）とクリップボード	閉じる	使うには明示的に開ける
他のプロセスの一覧や操作	閉じる	デバッガも同様
外への通信	開いている	パッケージの取得や外部の窓口への接続のため

表で目を引くのは最後の行です。ファイルの読み書きは細かく閉じる一方、外への通信は初期状態で開いています。公式の文書は、パッケージの取得、外部の窓口への接続、リポジトリとのやり取り、MCPサーバーへの接続のためだと説明しています。ファイルを守る道具であって、通信を絞る道具ではないという性格を、ここで確かめておく必要があります。

もう一つ、環境変数（プログラムに渡す設定値）の扱いも押さえておきます。公式の文書によると、初期状態では利用者のシェルの設定をそのまま引き継がず、絞り込んだ環境で動かします。ただし、導入の解説には、端末の環境変数をまるごと渡す使い方も載っており、その場合は秘密の値までエージェントに渡ると注記されています。文書は、よく使うAIの利用キーだけを渡す狭いやり方を勧めています。

必要に応じて開ける機能と、その重み

閉じた状態のままでは仕事にならない場面もあります。そのため、用途ごとに許可を足す仕組みがあります。公式の文書に並ぶのは、鍵束、クリップボード、クラウドの認証情報、同期フォルダ、ブラウザの起動、コンテナの操作、パスワード管理の道具、画面を伴うアプリケーション、マイクなどです。いずれも初期状態では閉じていて、利用者が明示的に選んだときだけ開く形になっています。

文書は、とくに影響の大きい選択肢を「広い許可（危険度が高い）」として分けています。端末全体を読み取りだけで見えるようにするもの、全エージェントや全アプリケーションの規則をまとめて読み込むものです。また、アプリケーションを開く仕組みを許すと、そこから起動したプロセスは隔離の外で動くと注記されています。一つの許可で、隔離の効果が大きく崩れる選択肢があるということです。

企業として見るべきは、どの許可を誰が開けているかです。隔離の道具を入れていても、開発者が手間を嫌って広い許可を常に有効にしていれば、守りの厚みはほとんど残りません。許可の一覧は文書で公開されているため、社内で「原則として開けない許可」と「申請すれば開けてよい許可」を分けて決めておくことができます。道具の選択肢を、そのまま社内の規程の項目に置き換えられるのは、この道具の扱いやすい点です。

対応するOSとAIエージェント

対応するOSはmacOSだけです。READMEは「macOSに特化している」と明記し、Linuxで同じことをしたい人向けに、別のOSSをいくつか紹介しています。ほかのOSで動かす方法は、確認した一次情報には書かれていませんでした。また、必要なmacOSの版の下限は、確認した範囲の文書には書かれていませんでした。社内の端末がmacOSとそれ以外で混在しているなら、この道具だけで全社の方針はそろわない点に注意が要ります。

エージェントについては、公式サイトが主要なエージェントで試したとして、Claude Code、Codex、Cursor、Cline、OpenCode、Copilot系、Gemini系など14種を挙げています。公式の文書には、エージェントごとにどんな場所へのアクセスが必要かを調べた記録も公開されています。さらに、Claude、Cursor、Visual Studio Codeのデスクトップ版は、起動したときに対応する規則が自動で選ばれると説明されています。

試験の範囲も確かめておきます。試験の文書によると、自動の試験はmacOS上で動き、10種ほどのエージェントについて、起動し、受け付けの状態になり、簡単な指示に応答するところまでを確かめています。言い換えると、各エージェントのあらゆる操作が規則の中で正しく動くことまでは、試験の対象になっていないということです。社内で使うときは、自社でよく使う作業で一度確かめる必要があります。

守れないもの：作者自身が挙げる限界

この道具の一次情報で評価できるのは、守れないものを作者自身が明記している点です。READMEは「強い意志を持つ攻撃者に対する完全な防御の壁ではなく、守りを固める一枚の層だ」と書いています。概要の文書は、守れないものとして次の四つを挙げています。

一つ目は、隔離の中から読めるファイルが、通信で外へ送られることです。二つ目は、隔離そのものを抜け出されることで、これは仮想マシンのような別の壁ではないためです。三つ目は、すでに許している連携の経路や認証の経路を悪用されることです。四つ目は、明示的に許した場所にある情報が漏れることです。まとめると、許した範囲の中で起きることと、通信で外へ出ることは、この道具の守備範囲の外です。

さらに、導入の解説には、利用者が隔離を通さずにエージェントを直接起動する方法も普通に書かれています。隔離はエージェントを起動するときに外から囲う方式なので、囲わずに起動すれば、何の制限もかからないということです。企業として使うなら、隔離を通しているかどうかを本人任せにしない工夫が要ります。

仮想マシン・コンテナとの違い

公式の比較の文書は、仮想マシン、コンテナ、Agent Safehouseの三つを並べています。その記載をもとに、企業の担当者が判断に使える形で整理しました。どれが優れているかではなく、何を守りたいかで選ぶ話です。

見る点	仮想マシン	コンテナ	Agent Safehouse
壁の種類	別のOSの中核を持つ	端末のOSの中核を共有	端末のOSの中核を共有し、プロセスに規則をかける
初期の見え方	自分のファイルだけが見える	結びつけた場所だけが見える	規則で許した場所だけが見える
負担	最も大きい	小から中	ごく小さい
普段の道具との相性	道具の入れ直しや同期が要る	画面を伴う作業には不向き	普段の道具がそのまま動く
向いている場面	悪意を前提にした強い隔離	再現できる実行環境の用意	日常の開発での被害範囲の縮小

表のとおり、Agent Safehouseは「日々の作業を止めずに被害の範囲を小さくする」ことを狙っています。公式の文書は、仮想マシンの代わりにはならないと明記し、より強い隔離が必要な場合は仮想マシンの中でエージェントを動かし、その中でさらにAgent Safehouseを使う重ね方を勧めています。

企業の使い分けに置き換えると、機密度の高い案件や、外から受け取ったデータを扱う作業は仮想マシンなどの強い隔離に回し、日常の開発作業の底上げにAgent Safehouseを使う、という組み立てが考えられます。端末で直接動かすか、強い隔離に移すかの二択ではなく、作業の重さに応じて隔離の強さを選ぶという発想です。

安全性の評価：紹介可とした根拠

このラインでは、紹介するOSSを公開されている事実だけを基に精査しています。OSSを入手したり動かしたりはしていません。Agent Safehouseの判定は「紹介可」です。

根拠にした事実は次のとおりです。作者は個人ですが、アカウントは2009年に作られ、公開しているリポジトリが26件ある実績のあるものです。ライセンスはApache-2.0で、商用を含めて使えます。GitHub上にこのリポジトリのセキュリティ勧告は登録されていませんでした。取り込みのときに自動で動く処理を含む設定も見当たりませんでした。スターの伸びは1日あたり約8.4件で、不自然な水増しの兆候は見られませんでした。

ただし、勧告がないことや自動実行がないことは、安全の保証ではありません。精査は公開情報の範囲に限られ、コードの中身や規則の正しさを検証したものではないからです。また、確認した時点で、弱点を見つけたときの報告の窓口をまとめた文書（セキュリティポリシー）はリポジトリに見当たりませんでした。弱点が見つかったときに、どこへ報告し、どう知らされるのかが明文化されていない点は、次の章の保守の話と合わせて押さえておいてください。

個人開発であることと、保守の継続性

企業として使うときに最も気にすべきなのは、保守がどこまで続くかです。GitHubの貢献者の一覧を見ると、貢献者は25（自動処理を含む）で、作者の変更が192件と最も多く、次に多い一人が66件でした。主な作業は作者と少数の協力者が担っている形です。作者の事情しだいで更新が止まる可能性は、組織が運営するOSSより高いと見ておくのが妥当です。

この道具の場合、保守の重みはとくに大きくなります。守りの中身が、エージェントごと・道具ごとに必要な場所を書き並べた規則だからです。エージェントは頻繁に版を上げ、設定の置き場所を変えます。規則が追いつかなければ、エージェントが動かなくなるか、動かすために利用者が広い許可を開けてしまうかのどちらかになりがちです。規則の更新が止まることは、そのまま守りの穴になりうるという性格を持っています。

加えて、土台にしているmacOSの隔離の仕組みそのものの扱いも見ておく必要があります。海外の解説記事では、この仕組みのコマンドがApple の説明書で非推奨と記されていると指摘されていますが、一次情報としてAgent Safehouseの文書に記載はなく、将来の扱いは確認できませんでした。macOSの大きな更新のたびに、動作と規則の効き方を確かめる担当を決めておくのが現実的です。

悪用されうるリスク

Agent Safehouseは守りのための道具で、攻撃に使うためのものではありません。それでも、使い方しだいで生まれうる危険はあります。最も大きいのは、隔離を入れたことが、エージェントの承認の確認を省く免罪符になることです。公式の例にも確認を省く設定との組み合わせが載っているため、そのまま社内に広がる可能性があります。

次に挙げるのは推測ですが、検討の材料として無視できません。外への通信が初期状態で開いているため、作業中のフォルダにある情報や、許した場所の情報は、悪意ある指示を紛れ込ませた文書をエージェントが読めば、外へ送られうる状態に残ります。また、隔離の規則を作る機能として、AIに端末を調べさせて規則を書かせる手順が公式に用意されています。AIが書いた規則を確かめずに使えば、必要以上の許可が混ざっても気づけないおそれがあります。

さらに、配布の形にも目を向けます。配布の文書によると、配られるのは一つのスクリプトで、確認した範囲ではそのファイルへの署名や改ざんの確認方法の記載は見当たりませんでした。守りの要になる道具が差し替えられれば、守っているつもりで何も守られていない状態になりえます。入手元と版を固定し、社内で配る形にすることが前提になります。なお、Agent Safehouseが実際に悪用された事例は、2026年10月18日時点で確認した一次情報からは見つけられませんでした。

社内で使うときの使いどころ

ここまでの事実を踏まえると、企業での使いどころは三つに整理できます。一つ目は、開発者の端末でエージェントを日常的に動かしている部門の底上げです。作業中のフォルダ以外を初めから閉じておけるため、秘密鍵やクラウドの認証情報が、エージェントの誤動作一つで読まれる状態を減らせます。

二つ目は、社内規程の具体化です。前の章で見たとおり、開けられる許可が一覧になっているため、「鍵束とクラウドの認証情報は原則として開けない」「端末全体の読み取りは禁止」といった決まりを、道具の選択肢に沿って書けます。抽象的な「AIに重要な情報を触らせない」という方針を、端末の上で確かめられる決まりに落とし込めるのは利点です。

三つ目は、事故が起きたときの調べ方の手がかりです。デバッグの文書によると、拒否された操作はmacOSの統合された記録に、プロセスの番号、操作の種類、対象の場所とともに残ります。どの操作が止められたかを後から確かめられるため、エージェントが想定外の場所に手を伸ばしていないかの点検に使えます。逆に、強い隔離が必要な作業や、macOS以外の端末には向かないため、そこは別の手段で補います。

導入を検討するときに確かめること

実際に検討するときは、動かす前に、資料と社内の取り決めで確かめられる点から整理します。下の手順は、OSSを動かす前の段階で終えられるものに絞っています。

この手順の要は、道具を入れる前に「開けない許可」と「通信の扱い」を決めておくことです。隔離の道具は、入れた瞬間から「守られている」という安心を生みます。その安心の範囲を先に言葉にしておかないと、確認を省く設定だけが広がり、守れない部分が見えなくなります。

企業が取るべき対策

一つ目は、エージェント側の承認の確認を省く設定の扱いを決めることです。隔離の有無にかかわらず、どの作業なら省いてよいかを決め、省くなら隔離を通すことを条件にします。隔離は確認を省く理由ではなく、省くときの最低条件と位置づけます。

二つ目は、端末の中の秘密の棚卸しです。隔離が閉じるのは決まった場所だけで、作業中のフォルダに置いた設定ファイルや、環境変数に入れた鍵は守れません。作業中のフォルダに秘密を置かない、長く使える鍵を端末に置かない、といった基本を先に整えます。三つ目は、通信の監視です。読める情報が外へ出ることは防げないため、端末や社内の出口で、想定外の送信先への通信を見られるようにしておきます。

四つ目は、隔離を通しているかの確認です。隔離を通さずに起動すれば制限はかからないため、端末管理の仕組みで起動のされ方を確かめられるかを検討します。五つ目は、調達のときの確認です。個人開発のOSSを業務で使う場合は、ライセンス、弱点の報告の窓口、更新の頻度、止まったときの代わりを、導入前に文書で残します。使い続けるかどうかを、半年ごとなど決めた間隔で見直すことも含めておきます。

AIに任せる範囲と、人が決める範囲

Agent Safehouseは、AIエージェントに端末の上で仕事をさせるための守りです。そして、規則そのものをAIに書かせる機能まで用意されています。便利な一方で、何を許すかの判断をAIに委ねてしまうと、守りの線を引く人がいなくなります。

公式の文書でも、AIが作る規則は、許可を足す前に利用者へ確かめる設計だとされています。ただ、それは手順の意図であって、出てきた規則の正しさを保証するものではありません。AIに下書きをさせるなら、許可ごとに理由を書かせ、人がすべての許可を読み、理由に納得できないものは外すという確認の段階を必ず置きます。やってはいけない向き合い方を挙げます。

• 「隔離してあるから」を理由に、エージェントの承認の確認を一律に省く
• AIが書いた規則を、許可の中身と理由を読まずにそのまま使う
• 手間を嫌って、端末全体の読み取りなど危険度の高い許可を常に開けておく
• 外への通信が開いていることを知らないまま、機密の資料を作業中のフォルダに置く
• 入手元も版も決めず、開発者ごとにばらばらの版を使わせる
• 保守の状況を誰も見ず、更新が止まっても気づかない

裏を返せば、人が決める範囲ははっきりしています。どの作業で確認を省くか、どの許可を開けるか、どこへ通信してよいか、誰が保守を見るか。この四つを決めたうえで、決めた範囲の作業をエージェントに速く回させるのが、道具とAIの正しい使い分けです。

よくある質問：これを入れれば承認の確認を省いてよいのか

答えは「それだけでは足りない」です。Agent Safehouseが閉じるのは、端末の中のファイルや機能への手の届き方です。作業中のフォルダの中で起きる誤った変更や、読める情報が通信で外へ出ることは、作者自身が守備範囲の外だと書いています。確認を省くかどうかは、作業の中身と扱う情報で決める話で、隔離の有無だけで決めるものではありません。

では入れる意味がないのかというと、そうではありません。エージェントの判断が外れたときに、秘密鍵やクラウドの認証情報、別の案件の資料にまで手が届く状態を、普段の作業を大きく変えずに減らせます。止められた操作が記録に残るため、後から点検する手がかりにもなります。もう一つ、「macOS以外の端末ではどうするか」という問いもありそうです。READMEはLinux向けに別のOSSを紹介していますが、それらはこの記事の調査の範囲外で、評価はしていません。

• Agent Safehouseの機能・初期の設定・対応環境・保守の状況は、GitHubのリポジトリとその中の文書、公式サイトと公式の文書を2026年10月18日に確かめた範囲に基づきます。内容は版によって変わる可能性があります
• 必要なmacOSの版の下限、配布ファイルの署名、土台にしているmacOSの隔離の仕組みの将来の扱いは、確認した一次情報の範囲では確かめられませんでした
• この記事は守りと評価の目線で書いています。導入・設定・実行の手順は扱いません

まとめ

Agent Safehouseは、macOSの端末で動かすAIエージェントが読み書きできる範囲を、作業中のフォルダなど必要な分だけに絞るOSSです。macOS標準の隔離の仕組みを使い、すべて拒否する状態から必要な分だけ許す考え方をとります。秘密鍵やクラウドの認証情報、ホームフォルダの大半を初めから閉じ、普段の道具をそのまま使える軽さが特徴です。Apache-2.0で公開され、セキュリティ勧告は登録されていません。

一方で、外への通信は初期状態で開いており、読める情報が外へ送られることや、隔離を抜け出されることは防げないと作者自身が明記しています。個人の作者が中心に保守しており、エージェントの変化に規則が追いつき続けるかは、使う側が見ていく必要があります。開けない許可、通信の扱い、確認を省く条件、保守を見る担当を先に決めたうえで使うことが、端末でAIエージェントを動かす企業にとってのAgent Safehouseの使いどころです。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。