# Cloudflare の outbound Workers で、Sandbox にトークンを渡さず認証できちゃう！

やっほー、しぃちゃんだよ！ 今日はね、AI エージェントを安全に外の世界とおしゃべりさせる、ちょっと賢いしくみのお話だよ。認証トークンを一切エージェントに渡さないまま、ちゃんと認証できちゃうんだって。わくわくするよね！

## なにが発表されたの？

Cloudflare の Blog から、[Sandboxes](https://developers.cloudflare.com/sandbox/) 向けの新しいしくみ「outbound Workers」が発表されたよ。これはね、サンドボックスの中で動くエージェントが外部サービスに接続するとき、その通信を丸ごと横取りしてくれるプログラマブルな出口プロキシ(egress proxy)なの。JavaScript で書いたハンドラを通すだけで、認証情報の差し込みやアクセス制御が自由自在になるんだって。

Sandboxes は [Containers](https://developers.cloudflare.com/containers/) の上で動いてて、microVM で隔離された使い捨ての実行環境。そこに outbound Workers が加わった感じだね。

## 今までどうだったの？

エージェントが GitHub とか社内サービスを叩くには、なにかしら認証情報が必要だよね。今までのやり方には、それぞれ悩みがあったの。

- 素の API トークン: 環境変数やファイルで渡すだけ。いちばん簡単だけど、サンドボックスがトークンを漏らさないって信じるしかないの。失効やローテーションの管理もついてまわるよ。
- ワークロード ID トークン(OIDC など): 権限そのものじゃなくて「身元の証明」を渡す方式。短命なアクセス権に交換できて安全だけど、受け取る側のサービスが OIDC に対応してないと、自前でトークン交換を実装しなきゃいけないの。
- 自前プロキシ: いちばん柔軟だけど、全部の通信を横取りして、動的なプロキシを作って、性能も保って…って、とっても大変。

しぃちゃんが思うに、理想は「エージェントにトークンを一切渡さない(zero-trust)、書くのが簡単、身元ごとにルールを変えられる、通信を観測できる、速い、透過的、しかも動的に変えられる」を全部満たすことなんだよね。outbound Workers はそこを狙ってるの。

## これで何が変わるの？

いちばんうれしいのは、ゼロトラストな認証情報の差し込みだよ。`outboundByHost` でドメインごとに関数を書いておけば、たとえば `my-internal-vcs.dev` 宛のリクエストにだけトークンを足せるの。しかもエージェント本体にはトークンを一切見せないまま！ コンテナの ID ごとに違うトークンを返すこともできて、鍵は [KV](https://developers.cloudflare.com/kv/)(保存時も通信時も暗号化)から引っぱってこられるんだって。

さらに、outbound Workers からは Cloudflare の binding を直接呼べるの。今までサンドボックスから R2 や KV を使うには、資格情報を注入して公開 API を叩く必要があったけど、これからは binding 越しに直接アクセスできる。サンドボックスの ID を使って [R2](https://www.cloudflare.com/developer-platform/products/r2/) のパスを名前空間で区切れば、トークンの解析やポリシー設定なしにスコープを絞れちゃうよ。

## 深く潜ってみよう

面白いのはここからだよ。ただ通す/弾くだけじゃなくて、リクエストの中身を書き換えるには HTTPS を復号しないといけないよね。outbound Workers は、サンドボックスのインスタンスごとに使い捨ての認証局(CA)と秘密鍵を作って、その CA をサンドボックスに入れておくの。サンドボックスは既定でこの CA を信頼するから、中身をのぞいて書き換えられる、いわば透過的な中間者プロキシ(MITM)になるんだ。普通のコンテナで使うときは `interceptHttps = true` にして、`sudo update-ca-certificates` で CA を信頼させればいいよ。使い捨ての鍵と CA はサイドカーのプロセスから外に出ないし、他のサイドカーとも共有されないから安心なの。

制御は動的にもできるよ。`setOutboundHandler` を使えば、実行中にポリシーを差し替えられるの。たとえば依存パッケージのインストール中だけ特定のホストを許可して、終わったら HTTP を全部止める、みたいに「ネットワークが開いてる時間」を最小にできる。エージェントが操作ごとにユーザーの承認を求めて、その結果でポリシーを更新、なんて芸当もできちゃう。

しくみとしては、`ctx.container` に `interceptOutboundHttp` と `interceptOutboundHttps` が追加されてて、ホスト名・IP レンジ・全部の外向き通信を glob でマッチできる。動的に差し替えても、既存の TCP 接続が途切れずに新しい設定を拾ってくれるのが賢いよね。ローカル開発でも `wrangler dev` が「proxy-everything」ってサイドカーを立てて、コンテナのネットワーク名前空間で TPROXY のルールを効かせて [workerd](https://github.com/cloudflare/workerd) に流すから、本番と同じ挙動を再現できるんだって。

使うには [ドキュメント](https://developers.cloudflare.com/containers/platform-details/outbound-traffic/) を読みつつ、`@cloudflare/containers@0.3.0` か `@cloudflare/sandbox@0.8.9` に上げればすぐ始められるよ。

## まとめ

- outbound Workers は、サンドボックスの外向き通信を JavaScript のハンドラで横取りできるプログラマブルな出口プロキシだよ。
- `outboundByHost` でドメインごとに、エージェントにトークンを見せないままゼロトラストで認証情報を差し込める。
- 使い捨ての CA を使った透過的な MITM で、HTTPS の中身まで検査・書き換えできる。
- `setOutboundHandler` で実行中にポリシーを差し替えられて、ネットワークを開ける時間を最小化できる。
- R2 や KV などの binding を直接呼べて、サンドボックス ID でスコープを絞れる。

AI エージェントをサンドボックスで動かしてる人、認証情報の扱いに神経を使ってる人にはドンピシャの発表だよ。週明けにパッケージを上げて試してみてね！