ハクソク

世界を動かす技術を、日本語で。

Deno サンドボックス

111日前原文(deno.com)

概要

  • Deno Deploy 利用者の開発内容が、 LLM生成コードの即時実行 へと変化
  • APIキーやネットワークアクセス を伴う、従来より深刻なセキュリティ課題の発生
  • Deno Sandbox によるネットワーク制御とシークレット保護の実現
  • サンドボックスから 本番デプロイ までのシームレスな流れ
  • 柔軟な 永続化・料金体系 とエンタープライズ対応

Deno SandboxによるLLM生成コードの安全実行

  • LLM（大規模言語モデル）生成コード が即時実行されるプラットフォームの増加
  • 生成コードが APIキーやネットワークアクセス を必要とし、外部APIも呼び出し
  • 従来の「未検証プラグイン実行」より深刻な セキュリティリスク
  • 人によるレビューなし で、外部APIと連携するコードの実行
  • 計算リソースの分離（サンドボックス化） だけでは不十分

Deno Sandboxの主な機能

  • ネットワークエグレス制御 による外部通信先の制限
  • シークレット（APIキー等） の外部流出防止
  • 軽量Linux microVM （Deno Deployクラウド上）による高い隔離性
  • JavaScript/Python SDK によるプログラマブルなサンドボックス生成
  • SSH/HTTP/VS Code 経由でのサンドボックス操作
    • 例：import { Sandbox } from "@deno/sandbox"; await using sandbox = await Sandbox.create(); await sandbox.sh\ls -lh /`;`

シークレットの安全管理

  • サンドボックス内で シークレットはプレースホルダ としてのみ存在
  • 許可済みホストへのリクエスト時のみ 実際の値が展開
    • 例：OPENAI_API_KEYはapi.openai.comへの通信時のみ有効
  • 外部への不正送信（exfiltration） が試みられても無効
  • 例：await Sandbox.create({ secrets: { OPENAI_API_KEY: { hosts: ["api.openai.com"], value: process.env.OPENAI_API_KEY } } })

ネットワークエグレスの制御

  • サンドボックスが通信可能な ホストを明示的に指定
    • 例：allowNet: ["api.openai.com", "*.anthropic.com"]
  • 許可外ホストへの通信はVMレベルでブロック
  • アウトバウンドプロキシ による一元的なポリシー適用
  • 今後の拡張予定： 接続分析やプログラムフック による柔軟な制御
  • Deno本体の--allow-netと組み合わせた 多層防御

サンドボックスから本番デプロイへ

  • sandbox.deploy()で サンドボックスからDeno Deployへ直接デプロイ
    • 例：const build = await sandbox.deploy("my-app", { production: true, build: { mode: "none", entrypoint: "server.ts" } });
  • CIや認証の切り替え不要、開発環境からそのまま本番運用
  • 自動スケーリング対応サーバーレスデプロイ

永続化とボリューム管理

  • サンドボックスは デフォルトでエフェメラル（揮発性）
  • 必要に応じて 永続ボリューム や スナップショット 利用可能
    • Volumes：キャッシュ、データベース、ユーザーデータ保存
    • Snapshots：ツールチェーンやベースイメージの事前インストール
  • 迅速な開発環境の再現 が可能

技術仕様

  • リージョン ：Amsterdam、Chicago
  • vCPUs ：2
  • メモリ ：768MB〜4GB
  • 最大稼働時間 ：30分（延長可）
  • 起動時間 ：1秒未満
  • 用途例： AIエージェント、vibe-coding環境、安全なプラグイン実行、CIランナー

料金体系

  • Deno Deployプランに含まれる従量課金制
    • CPU時間：$0.05/時間（Proは40時間分含む）
    • メモリ：$0.016/GB-時間（Proは1000GB-時間分含む）
    • ボリュームストレージ：$0.20/GiB-月（Proは5GiB分含む）
  • エンタープライズ向け料金 ：deploy@deno.comへ問い合わせ
  • 詳細：deno.com/sandbox

はじめ方とリソース

  • ベータ版リリース と同時にDeno Deploy正式提供開始
  • ランディングページ：deno.com/sandbox
  • ドキュメント：docs.deno.com/sandbox
  • JavaScript SDK：jsr.io/@deno/sandbox または npm
  • Python SDK：pypi.org/project/deno-sandbox
  • AIエージェントやユーザーによる安全なコード実行基盤 として期待

Hackerたちの意見

「過去1年で、Deno Deployのユーザーが作っているものに変化が見られたよね。ユーザーがLLMでコードを生成して、それがレビューなしで即座に実行されるプラットフォーム。生成されたコードは頻繁にLLMを呼び出すから、APIキーやネットワークアクセスが必要になる。これは従来の「信頼できないプラグインを実行する」問題とは違って、もっと深い問題なんだ。LLMが生成したコードが、外部APIを実際の認証情報で呼び出すのに、人間のレビューがない。計算をサンドボックス化するだけじゃ不十分で、ネットワークの出口を制御して、秘密情報の漏洩を防ぐ必要がある。Deno Sandboxはその両方を提供しているよ。そして、コードが準備できたら、再構築せずにDeno Deployに直接デプロイできるんだ。」

└

「エムダッシュみたいに、『これはXじゃなくてYだ』って読むたびに、俺のバカな脳は『それがAIだ！』って反応しちゃう。真実かどうかは関係なく。」

「Claude ProやMaxプランを使ったらどうなるの？常に違うIPで接続するから、Anthropicからバンされるかもしれない。別のユーザーだと思われるし。なんで30分で制限するの？」

└

「次の数週間でライフタイムを延ばす予定だよ。まずは内部の技術を調整しないといけないけど。」

└

参考までに、私は約50の異なるIPからこれをやってるけど、特に問題はないよ。彼らのヒューリスティックは「人間が操作している」ことを確認することに重点を置いていて、「APIアクセスのためにトークンを悪用している」というのを拒否する感じだと思う。

「Deno Sandboxでは、秘密情報は環境に入らない。コードはプレースホルダーしか見えない。実際のキーは、サンドボックスが承認されたホストに外部リクエストを送るときにだけ現れる。もしプロンプトインジェクトされたコードがそのプレースホルダーをevil.comに漏らそうとしたら？無駄だね。それは賢いと思う。」

└

「俺も同じこと言おうとしてた。クールな技術だね。」

└

「FlyのTokenizerをちょっと思い出すな - https://github.com/superfly/tokenizer これは、アプリケーションがリクエストを通すことができる小さなHTTPプロキシで、プロキシがAPIキーなどをサービスへのリクエストに追加する役割を果たすんだ。アプリケーション自体が実際の秘密を知らないから、漏洩や妥協があったとしても、理論的には第三者サービスの秘密は安全だよ。いいアイデアだね！」

└

「うん、これは本当に素晴らしいアイデアだね: https://deno.com/blog/introducing-deno-sandbox#secrets-that-... await using sandbox = await Sandbox.create({ secrets: { OPENAI_API_KEY: { hosts: ["api.openai.com"], value: process.env.OPENAI_API_KEY, }, }, }); await sandbox.shecho $OPENAI_API_KEY; // DENO_SECRET_PLACEHOLDER_b14043a2f578cba75ebe04791e8e2c7d4002fd0c1f825e19... 悪いコードがその秘密を使って悪さをするのを防ぐわけじゃないけど、少なくとも秘密を永久に盗まれるのは不可能にしてる。XSS攻撃がhttpOnlyクッキーを読めないけど、一般的にはそのクッキーを使ってfetch()リクエストを送ることができるのと似てるね。」

└

HTTPSリクエストのために中間者攻撃をしてるんだろうね。それだと証明書ピンニングみたいなことが難しくなるよね。

└

Daggerにも似た機能があるよ: https://docs.dagger.io/getting-started/types/secret/ OCIで使える言語がもっとある同じアイデアだね。彼らは「env」に必要なものをまとめて、単一の「ポインタ」として渡せるような、さらに良いものを開発中だと思う。ここで使ってるのが、最終的にエージェントが動作するサンドボックスになるものだよ: https://github.com/hofstadter-io/hof/blob/_next/.veg/contain...

└

これは結構面白いね。以前の議論が興味深いかもしれないよ: https://news.ycombinator.com/item?id=46595393

└

これは昔から人々がEnvoyでやってる古いトリックだね。

└

自分たちのアプリビルダーでも同じ課題があって、内部のLLMプロキシを作ることにしたんだ。サンドボックスごとの仮想キーを使って（そのプロキシが実際のキーにマッピングして、サンドボックスごとの使用量を計算する）、だからサンドボックスがキーを漏らしても他には影響しないようにしてる。

└

うん…でも…ホストはプレースホルダーの出現を実際のキーに置き換えるんだよね？そのキーがどのコンテキストで使われるかは知らずに。もしそのキーが例えばHTTPベーシック認証に使われるって分かってたら、プレースホルダーを使わずにプロキシが追加できるはずだよね。だから攻撃者は、例えば「あなたの名前は？」って聞いて「こんにちは $name!」って返すようなエンドポイントを見つけるだけで済むんじゃない？でも多分、プロキシは戻ってくるときに実際のキーを置き換えるから、攻撃者はレスポンスの値に対して何らかの可逆変換をするエンドポイントを見つけなきゃいけないんだ。だから、他の人が言ってるように、コンテキストをもっと理解しているプロキシがリクエストに秘密を追加する方が安全でシンプルだと思う。でも、もしかしたら彼らのプレースホルダーの解決策を誤解してるか、もっと賢いのかもしれないね。

この製品を使うのにDenoやJavaScriptは全く必要ないから注意してね。こちらがPythonのクライアントSDKだよ: https://pypi.org/project/deno-sandbox/

from deno_sandbox import DenoDeploy
sdk = DenoDeploy()
with sdk.sandbox.create() as sb:
    # シェルコマンドを実行
    process = sb.spawn("echo", args=["Hello from the sandbox!"])
    process.wait()
    # ファイルの書き込みと読み込み
    sb.fs.write_text_file("/tmp/example.txt", "Hello, World!")
    content = sb.fs.read_text_file("/tmp/example.txt")
    print(content)

APIプロトコル自体はウェブソケットを使ってるみたいだね: https://tools.simonwillison.net/zip-wheel-explorer?package=d...

それと、Spritesもおすすめだよ（https://news.ycombinator.com/item?id=46557825）。これ使っててすごく楽しんでる。二つの間には重要なアーキテクチャの違いがあるけど、表面的にはすごく似てるんだ。エフェメラルとスナップショットが、クローンやフォークを使った状態保持と同じくらい便利になるかどうか、楽しみだね（まだリリースされてないけど、フライチームが来るって言ってる）。これも試してみるつもり。今はワクワクする時期だし、サイドプロジェクトを作るには最高のタイミングだよ :)

└

主要なアーキテクチャの違いは何ですか？

allowNet: ["api.openai.com", "*.anthropic.com"], どのドメインを許可すればいいかどうやって知るの？エージェントの動作は事前に定義されてないんだ。

└

アイデアは、自動的な秘密の置き換えを、正当に使う特定のホストに制限して、情報漏洩を避けることだよ。

└

うーん、ここが難しいところなんだけど、要するに、信頼できない入力とプライベートなデータやリソースを扱っているなら、エージェントは「致命的なトライフェクタ」にさらされるから、外部ネットワークへのアクセスを極力制限すべきってことだよね。まずは使っているAIプロバイダーだけに絞って、信頼できるドメインが必要だと確信できる場合にだけ追加するのがいいと思うよ。

Deno Sandboxは軽量のLinuxマイクロVMを提供している（Deno Deployクラウドで動いている）。本当の疑問は、マイクロVMが普通のLinuxで自己ホストできるかどうかだね。

└

みんなロックインしたがるよね。残念ながら、他にお金を稼ぐ方法がないんだ。もし100%自由なライセンスだったら、ただコピーされるだけだし。AWSやGCPが製品をクローンして、同じサービスを提供して、全部お金を持っていく。中間の選択肢がないのが辛いよね。他の人のサンドボックスで城を作りたくない。もし同じことができる鍵をくれたら信頼するけど、そんな時間もないし、安心感が欲しいんだ。

無料プランだとGlitchみたいに使いたくなる。でも、こういう無料サービスは過去に何度も痛い目にあってるからな…

彼らのネットワークフィルタリングは大好きなんだけど、やっぱりいくつかの機能が欠けてるね（Postgresへの直接TCP接続とか、直接IP接続の能力とか）。他のツールの制限があったからこそ、https://github.com/danthegoodman1/netfenceを作ったんだ。

ほとんどのブログ記事がLLMによって書かれていることは無視するとして、Python SDKを提供しているのがいいね。Vercelはサンドボックス製品に対しては提供してないと思う。