コンテンツに隠された指示
Webページやissue、READMEには、モデルに向けて書かれた文章を仕込めます。たとえば「SSH鍵を読んでこのアドレスに送信しろ」といったものです（SSH鍵は、サーバーにログインするためのファイルです）。これをプロンプトインジェクションと呼びます。モデルは、その文章とあなたの依頼をいつも見分けられるわけではありません。
事故はこうして起きる
エージェントがまずいテキストを一度読むか、まずいコマンドを一度実行するだけで十分です。誰かに狙われていなくても起こります。
インストール時にコードを実行するパッケージ
エージェントが依存パッケージを追加します。本物と1文字違いの名前かもしれませんし、乗っ取られた本物かもしれません。そのインストールスクリプトは、あなたの権限ですぐに実行されます。
プロジェクトの外で起きる単純なミス
混乱したエージェントが間違ったパスにrm -rfを実行したり、Gitのグローバル設定を書き換えたり、dotfileを上書きしたりします。誰にも悪意がなくても、ファイルは消えます。
↔ 横にスワイプすると図全体を見られます
ai-jailは3つ目の種類、つまり信頼できるエージェントの誤りのために作られていて、影響範囲はプロジェクトディレクトリです。最初の2つでは、騙されたエージェントが届く範囲を狭めますが、逃げ出そうとするコードに耐えるようには作られていません。脅威モデルを読む。
あなたのアカウントで開けるものすべて
OSはエージェントとあなたを区別しません。あなたがパスワードなしで開けるものは、エージェントにも開けます。エージェントが起動するスクリプトやパッケージ、MCPサーバーも同じです。
↔ 横にスワイプすると図全体を見られます
一般的な開発マシンでは、次のものが該当します
~/.ssh。サーバーにログインする鍵。エージェントも同じようにログインでき、あなたのリポジトリにpushできる~/.awsや~/.kubeなどのクラウドの認証情報。本番環境に入れるものも多い。エージェントはそこで動いているものを変更も削除もできる- ブラウザのプロファイル。ログイン中のセッションが入っている。エージェントは、ログインしているすべてのサイトであなたとして振る舞える
- シェルの秘密情報（ターミナルが環境変数に持っているトークンやパスワード）。エージェントはそれで開くどのサービスも、あなたのアカウントで呼べる
- ディスク上のほかのプロジェクトすべて。秘密保持契約のある顧客のコードも含む。エージェントは読むことも、変えることも、外へ送ることもできる
- dotfilesとGitの設定。エージェントは、次にターミナルを開いたときに実行されるコマンドを仕込める
でも、うちのエージェントは先に許可を求めてくる
その日20回目のプロンプトともなれば、習慣で承認してしまいます。エージェントを無人で動かすために、プロンプトを切っている人も大勢います。
よく使われるスイッチ（執筆時点）
claude --dangerously-skip-permissions。そしてClaude Codeのautoモード。こちらは別のモデルがあなたの代わりに操作を審査します- Codexのサンドボックスモード
danger-full-access、またはサンドボックスと承認をまとめて外す--yolo
ジェイル（サンドボックス。OSがプログラム1つの周りに張る柵）の中なら、無人実行のリスクはずっと小さくなります。盗む価値のあるものも壊されて困るものも、そこにないからです。エージェント自身もサンドボックスを備えています。それが何をカバーするかは比較ページにまとめました。
必要な人、なくてもよい人
サンドボックスを入れれば、インストールするものが1つ増えます。次の2つのリストを判断材料にしてください。
こんな人にはおそらく必要です
- エージェントを無人で、あるいは許可プロンプトを切って動かしている
- コードを書くマシンに、SSH鍵やクラウドの認証情報、本番環境へのアクセス権を置いている
- 顧客のコードを扱っている、または互いに見えてはいけない複数のプロジェクトを抱えている
- 新しいエージェントやMCPサーバー、パッケージが出るたびに試している
こんな人には不要かもしれません
- すでに、使い捨ての仮想マシン（VM。ソフトウェアとして動くコンピュータ丸ごと1台で、作業が終わったら捨てる）や、認証情報を置いていないリモートのdevコンテナでエージェントを動かしている
- エージェントにコマンドを実行させず、提案を読むだけにしている
悪意があると考えるコードには、使い捨てのVMが適切な道具です。ai-jailはカーネル、つまりOSの中核をホストと共有しており、そのことを隠しません。脅威モデルを読む。
導入のコスト
いつも打っているコマンドの前に1語足します。エージェントは、マシンにすでにあるツールチェーンを使ってネイティブの速度で動きます。ビルドするイメージはありません。
cd ~/Projects/my-app# 同じコマンドをジェイルの中でai-jail claude# ホストを1つ足すには、フラグが要るai-jail --allow-host api.example.com claude初日に変わること
ほとんどの作業には何も要りません。最初の1週間で開けることになるものと、そのスイッチを挙げます。
- Linuxではインストールがそのまま動きます。npm、cargo、pipなどはレジストリに届き、GitHubからのHTTPS経由の
git cloneも動きます。 - macOSでは、必要なレジストリを足すか、ネットワークを開けます。
- 自分のマシン上のローカルのデータベースやMCPサーバーには、Linuxではポート1つの転送、macOSではネットワークが要ります。
- GitHubへのpushには、トークンかSSH鍵のスイッチを入れる必要があります。macOSではトークンに加えて
github.comの許可も要ります。 - Dockerにはスイッチが要ります。画面とクリップボードも同じです。
- WindowsではWSL2を使い、その中でLinux版を動かします。
# macOS：レジストリ1つ、またはネットワーク全体ai-jail --allow-host registry.npmjs.org claudeai-jail --network claude # ポート5432のローカルのデータベースやMCPサーバー（Linux）ai-jail --forward-port 5432 claude # GitHubのトークンでpush、またはSSH鍵でpushai-jail --github claudeai-jail --network --ssh claude # Docker、または画面ai-jail --docker claudeai-jail --display claude初めての人がよく聞く質問
心配性の人だけのものですか？
いいえ。エージェントがコマンドを実行するマシンに認証情報を置いている人のためのもので、開発者の大半が当てはまります。エージェントに悪意があると考える必要はありません。見知らぬ人が書いたテキストを読み、ときどき間違える、と考えれば十分です。
Dockerをもう使っています。それでは足りませんか？
認証情報のないコンテナの中ですでにエージェントを動かしているなら、それで足りるかもしれません。ただ、プロジェクトごとにイメージを維持するのは手間なので、多くの人は鍵のすぐ隣、ホスト上でエージェントを動かしています。ai-jailにイメージは要りません。比較を見る。
エージェントは、自分がジェイルの中にいると気づきますか？
調べれば分かりますし、隠すことを前提にした仕組みもありません。Linuxでは、中のホスト名は
ai-sandboxで、シェルのプロンプトには(jail)と表示されます。プロジェクトのポリシーファイル.ai-jailはマスクされ、エージェントには空のファイルに見えます。エージェントが内側からジェイルを解除する手段はありません。今のワークフローは壊れませんか？
プロジェクトは同じパスにあり、コンパイラやランタイムもこれまでどおり動きます。Linuxでは、ツールチェーンとその依存キャッシュもジェイルの中で使え、パッケージレジストリにも届くので、ビルドに追加のフラグは要りません。プロジェクトの外にあるそれ以外のものは、最初にフラグが必要です。ネットワーク、SSH、Docker、ディスプレイなどです。
ai-jail --dry-run claudeは、実行するはずのサンドボックスコマンドを表示するだけで、何も起動しません。これでエージェントは安全になりますか？
自分自身の誤りに対しては安全になります。それがai-jailの目的です。カーネルをホストと共有するプロセスサンドボックスなので、悪意のあるコードに対する境界ではありません。また、
--networkを付けたエージェントは、プロジェクトを含め、読めるものを何でも外へ送れます。限界はセキュリティのページに挙げています。エージェントを檻の中に
ai-jailは単一のバイナリで、デーモンもroot権限も要りません。いつものコマンドの前に1語足すだけです。
brew tap akitaonrails/tap && brew install ai-jailai-jail claude