AIエージェント時代の権限管理が、いまアツい
こんにちは。LayerXで「Ai Workforce」というプロダクトのプロダクトマネージャーをしているinaoです。 Ai Workforceは、組織の中でAI Agentを活用するためのプラットフォームです。 getaiworkforce.com おかげさまで、我々の組織もお客様もユースケースも拡大を続けていて、AI Agentとその周辺機能を日々企画・開発しています。そのなかで、最近とくに議論が長引くテーマがあります。 権限管理です。 社内Slackで権限の話を始めると、毎回スレッドが伸びます。私もさまざまな方と意見交換するたびに新しい視点が得られ、とても面白い領域だと感じています。（そういう意味で、社内的にいまアツい、です） 視点が増え、論点が分岐し、さらにスレッドが伸びる。なぜこんなに難しいのか。そして、なぜ「いま」これを考える意味があるのか。この記事では、権限管理を 過去（これまでの前提）／現在（各社の動向と現場の論点）／未来（向かう先） の時間軸で整理してみたいと思います。 最初にお断りしておくと、Ai Workforceは「さまざまな業務を支援・遂行するためのAI Agentプラットフォーム」という位置づけです。そのため本稿も、特定の理想形に絞らず、「さまざま」を扱うための権限管理について、雑多に考えを広げています。その前提で読んでいただけると幸いです。 なぜ権限管理がエージェントの肝になるのか 個人のAIと組織のAI 組織の中にAIを配置し、安全かつ効率的に運用する。人とAIがコラボレーションする。そう考えたとき、設計の肝になるのは「どの権限を、誰に、どこまで、どうやって渡すか」です。 ここが決まらないと、エージェントは安心して仕事を任せられる同僚にはなれません。逆に縛りすぎれば、できることが少なく、柔軟性の低いものになってしまいます。 面白いのは、議論すると人によって意見が様々であることです。理由はおそらく2つあります。 想定しているユースケースは人によって違う。 個人の生産性ツールとしてAIを使う文脈と、組織の共通リソースとして業務を自動化する文脈とでは、最適な権限のかたちはまるで変わります。 個人利用のClaudeやChatGPTに求められることと、組織の中のAgentに求められることも違ってきます。 権限への立ち位置が違う。 業務を設計する人と、業務で扱うリソースを設計する人とでは、「⚪︎⚪︎権限」に対するスタンスが異なります。 しかも、いまだ世の中に存在しないもので、人間にはとてもわかりづらい権限について想像しながら話しているため、人によって思い描く理想像もずれていきます。この課題を完全に解消できるかは怪しいですが、整理することで、議論の足場くらいは作れるはずです。 過去：主に人間を中心に設計されてきた権限管理 これまでのソフトウェアの権限管理は、システム間の連携のようなアクセス制御やルールもありますが、概ね一貫して「人間」を中心に設計されてきました。代表的なものを並べてみます。 RBAC（Role-Based Access Control）：アクセスの主体は人間のユーザーで、権限をロールやグループに束ねる。 ABAC（Attribute-Based Access Control）：主体（ユーザー／システム）に加えて、対象リソースの属性とポリシーでアクセス可否を決める。 ACL（アクセスコントロールリスト）：「誰が見られる／編集できる」をフォルダ・ファイル単位で管理する（Google Drive、SharePoint、Boxなど）。 認可（OAuthなど）：アプリがユーザーの代わりに何かするとき、フローを通じて「ユーザーの許可」をもらいアクセストークンを取得する。リソース側からは、ユーザー本人の行動かアプリの行動かをほぼ区別できない。 これらの世界には、共通する暗黙の前提がありました。 行為者は人間か、または人間の意図を忠実に転送するだけのプログラムである。 ボタンを押したのは人であり、アプリはその意図を運んでいるに過ぎない。だから「誰がやったか」は実質的にユーザー本人と等しく、監査ログにユーザー情報が紐づけば十分。 つまり、意図の出どころは常に人間という点です。 現在：エージェントは「自律的な行為者」になった エージェントによって、何が変わったのでしょうか。 一言でいえば、意図を「転送」するのではなく、文脈から意図やアクションを「生成」するようになったことだと考えています。 人間が「この資料をまとめて」と頼むと、エージェントはどの情報を参照し、どう判断し、どんな成果物を作り、どのアクションを実行するかを、自分で決めていきます。たった一回のクリックの後ろで、数十の判断とアクションが連鎖する。ここで、従来の前提が静かに崩れ始めます。 課題1：主体をユーザーのままにすると、「誰がやったか」区別がつかない リソース側（内部データや外部システム）は、「ユーザー本人が操作したのか」「エージェントが自律的に動いたのか」を見分けられません。監査ログ上は同じに見えるため、事故が起きたときに「誰が」やったのかを後から辿れなくなります。 また、ユーザーの権限を継承してエージェントが情報にアクセスしてしまうと、情報セキュリティ上に外部に送ってはいけない情報が外部システムとしてのエージェントに渡されてしまったり、エージェントを通してさらに外に送信されてしまうおそれがあります。 課題2：エージェント固有の権限で動かすと、「できること」がブラックボックス化する エージェントにサービスアカウントを与えてその権限で動かすと、ユーザーの権限とエージェントの権限が乖離します。それで良い場面もありますが、ユーザー本人には許されないことを、エージェント経由で実行できてしまう、ということも起こりえます。 エージェントからアクセスできる範囲やできることがユーザーから見て分かりづらくなってしまったり、ガバナンスが適切に効かせられているかどうか分かりづらくなってしまうかもしれません。 課題3：人への依頼と、エージェントへの依頼は「責任の所在」が違う 「AさんがBさんに作業を依頼する」のと、「AさんがエージェントA′に依頼する」のは違います。Bさんには本人の判断と責任がありますが、エージェントA′が何をどこまでできるのかを、Aさんが正確に把握しているとは限りません。把握できていないことが、トラブルや業務の停滞につながりかねません。 各社のプロダクトはどう設計しているか エンタープライズ向けにAIエージェントを提供する各社も、同じ課題に向き合っているはずです。公開情報をもとにざっくり調べたところ（※すぐ触れる環境がなかったため厳密さは欠きます）、大きく2つに分かれそうでした。 実行ユーザーの権限を継承するタイプ 例：SalesforceのAgentforceのEmployee Agent。 エージェント自体に独立した権限モデルを持たず、実行ユーザーの権限をベースに動く。基本的にはユーザーに許可を求める仕組み。 エージェントを第一級のアイデンティティとして扱うタイプ 例：Google Cloudの「Agent Identity」、Microsoftの「Entra Agent ID」「Agent 365」。 エージェントそのものに身元と権限を持たせる。 どちらが良いではなく、それぞれの体験、汎用性を踏まえて設計されているように見えます。 また、各社のプロダクト以外にも、OAuthやMCPを中心に標準化の動向や議論もあるようです。（ここは話が広がりすぎるので、また別の機会に） いま現場で起きている論点 世の中の動きと同じことが、社内でも論点として立ち上がってきます。 （以下はあくまで社内で出ている論点の一例で、権限管理の一般的な論点を網羅したものではないのでご注意ください） 1. 代行か、依頼か 1つ目は、エージェントが「誰の権限で」「どこまで自分で判断して」動くかという軸です。業務の任せ方には2種類あります。 業務の代行：自分の仕事をそのまま肩代わりしてもらう。エージェントは裁量を持たず、ユーザーの権限の範囲で動く。例：「自分の提案書を仕上げてほしい」 業務の依頼：任された側にも裁量がある。エージェント自身の権限と判断で動く。例：「組織内の情報整理を定期的に行ってほしい」 例えば、「エージェントは自分の権限で動いてくれた方がアクセス範囲やできることが明確」である、という意見もありますし、一方で「誰が実行しても同じ結果が得られるようにエージェントごとに権限が管理が理想」という意見もあります。 ユースケースによってどちらも妥当そうに見えます。どちらをやるにしても一つのプロダクトの中でどう表現し、どう実現できるのか、はまだぼんやりしています。 なお、代行だからといって「ユーザーの全権限をそのままエージェントに渡してよい」わけではありません。本人なら許される操作でも、エージェント経由だと意図しない結果になることがあります（機密情報や受領資料を外部に送信してしまったら、目も当てられません）。代行であっても「どの権限を、どの操作に限って貸すか」の絞り込みは必要です。 2. そのエージェントは「誰のもの」か 2つ目は、論点1とは別の軸で、**そのエージェントが「誰に紐づくアイデンティティなのか」**という話です。 個人に紐づくエージェント：自分の業務のために使うエージェント。誰に許可を取ればよいかが明確で、説明責任もその人に集約されるため、シンプルで安心しやすい。一方で、異動や退職のたびに引き継ぎが発生します。 組織に紐づくエージェント（脱属人化）：チーム全体に向けて働く、共通リソースとしてのエージェント。特定個人がいなくなっても残せますが、「誰が責任を持ち、誰が許可を出すのか」を明確にする必要がある。 1つ目の代行・依頼と、この2つ目の誰のものか、は2軸として独立しているかもしれないと考えています。「代行か依頼か（権限の出どころ）」と「個人か組織か（アイデンティティの所在）」は、同じ話に見えますが、たとえば組織に属するエージェントが、実行時には指示者の権限を借りて代行するといった組み合わせも成り立ちます。混同せず別々の話として設計したほうが、選べる形が広がりそうです。 3. リソースをどう安全に分けて扱うか 3つ目は、エージェントが触れるリソースの範囲をどう引くかです。 エージェントを特定のプロジェクト資料やアクションに限定すると、安全性は高まりますが、その範囲でしか動けず、汎用性や、応用力は下がります。 一方で、プロジェクトを横断・俯瞰したい場面も当然あります。 目的によってエージェントが触れる範囲を限定したくなります。 リソース範囲ごとにエージェントをそれぞれ用意する形になるかもしれませんし、用途に応じたスコープを柔軟に構成できると良いのかもしれません。また、用途に応じたエージェントを実行できる主体も異なる形にする必要があるかもしれません。 これらはどれも「最終的には全部必要」という話に着地するかもしれません。 さまざまなユースケースをカバーしたい我々のようなプロダクトでは、汎用性とカスタマイズ性を両立しながら、作り手もユーザーも安心・安全に使いこなせる権限モデルを確立する必要があると考えています。 未来？：権限管理はどこへ向かうのか 足元の課題を解くのはもちろんですが、もう少し先を妄想してみたいと思います。 権限は「リソースの列挙」から「意図・条件の記述」へ 「どのファイル」「どのフォルダ」と一つずつ指定するのではなく、「機密区分が高くないもの」「この案件に関するもの」のように、条件や意味で権限を切り分ける 方向に進むかもしれません。エージェントは大量かつ多様なリソースを必要とするため、人間が一つずつACLを設定する運用はいずれ破綻してしまいそうです。クエリのようなスコープや、属性ベースのポリシーが中心になっていくのではないでしょうか。 権限は連鎖し、その連鎖は検証可能になる 人→エージェント→別のエージェント→外部API、というように多段の依頼や権限委譲が当たり前になりつつあります。各ホップでトークンが渡され、最終的に「誰の意図で、どのエージェントが、何をしたか」を正確に辿れる状態が求められます。複雑な流れであってもアカウンタビリティが保てること自体が、権限設計の要件になっていくはずです。 エージェントは「管理されるアイデンティティ」になる 人が会社に入社・退社する際、アカウント発行、PCセットアップ、アカウント削除、PCリセットといった手続きがあります。同じように、エージェントにも作成・更新・廃棄のライフサイクルが必要になりそうです。「いま組織にどんなエージェントがいて、何ができ、最後にいつ何をしたか」を把握できる状態が、ガバナンスの前提になっていくでしょう。 組織の中で働くエージェントが本当の意味で安心・安全になるには、さまざまな工夫が必要であると思います。 さいごに ここまで、権限管理を「過去／現在／未来」の時間軸で整理してきました。 いまこの論点を考える意味は、エージェントが便利な新機能ではなく、組織の中で意思決定とアクションを連続的に生み出す「新しい行為者」になりつつあるからだと思っています。だからこそ、単に強い／弱い権限を付けるのではなく、次の3つをプロダクトと運用の両面で設計していく必要があります。 誰のために動いたのか どの範囲まで委ねたのか 何をしたのかを、後から説明できるのか 完璧な解はまだ見えていません。それでも、Ai Workforceなりの、「さまざま」な業務に耐える権限モデルを探っていきたいと思います。 さいごのさいごに Ai Workforceでは、プロダクトマネージャーやエンジニアを募集しています。 ご興味のある方は、ぜひカジュアル面談からお気軽にご応募ください！ jobs.layerx.co.jp
- 生成AI
- セキュリティ
- ガバナンス
JSAI2026（第40回人工知能学会全国大会）にプラチナスポンサーとして協賛します
こんにちは、バクラク事業部で機械学習エンジニアをしている伊藤です。 LayerXは、JSAI2026（第40回人工知能学会全国大会）にプラチナスポンサーとして協賛します。LayerXがJSAIに参加するのは昨年に引き続き4回目となり、本大会でも企業ブース展示、インダストリアルセッションでの発表を予定しております。 イベント概要 当社の参加内容 インダストリアルセッション 企業展示 学生向けランチ懇親会 協賛の背景 さいごに LayerXにおけるAI・機械学習関連の記事 イベント概要 JSAI（人工知能学会全国大会）は、人工知能学会 が年に1度開催する、人工知能および関連分野の研究発表や交流の場です。全国のアカデミアや企業からAIの研究・開発に従事している人々が集い、研究発表と活発な議論がなされる場です。LayerXからはバクラク事業部・Ai Workforce事業部を含む数名のメンバーで現地会場に参加させていただきます。 項目 内容 開催期間 2026年6月8日（月）〜6月12日（金） 開催場所 Gメッセ群馬＋オンライン（ハイブリッド開催） 主催 一般社団法人 人工知能学会 公式サイト JSAI2026 当社の参加内容 インダストリアルセッション 大会初日である6月8日のインダストリアルセッション1にて、Ai Workforce事業部の平澤より「LayerXにおけるセキュリティ管理の現在地と次の一手」というタイトルで発表させていただきます。LayerXが展開するAi Workforceの事例を通じて、セキュリティ管理の現在地と、開発スピードとの両立を目指す今後のセキュリティ戦略についてお話しします。是非ともご聴講ください。 タイトル: LayerXにおけるセキュリティ管理の現在地と次の一手 発表者: 平澤 寅庄（株式会社LayerX） セッション: [1B4-IND-1] インダストリアルセッション1 日時: 2026年6月8日（月）16:40〜16:55 会場: B会場（展示ホール仮設1） プログラムリンク: 1B4-IND-1-05 | JSAI2026 登壇情報 企業展示 JSAI2026の企業展示では、ブースE77にて展示を行います。LayerXが目指す「業務の完全自動運転」や、日頃の開発・研究開発の取り組み、インターンシップなどについて紹介させていただきます。少しでも興味を持っていただけた方はぜひ気軽にお立ち寄りください！ JSAI2026 企業展示配置図 学生向けランチ懇親会 JSAI2026に現地参加されている学生の方限定で、ランチ懇親会を開催予定です。現役のLayerXメンバーと、実際のAI Agent開発やサマーインターンなど、さまざまなトピックについてカジュアルに話せる場にできればと考えております。 ご希望の方は、以下の参加フォームより申し込みをお願いします！ 参加対象: JSAI2026に参加している学生の方 開催日時: 2026年6月9日（火）12:15〜13:15 参加フォーム（connpass） 2026年6月10日（水）12:45〜13:45 参加フォーム（connpass） 2026年6月11日（木）12:15〜13:15 参加フォーム（connpass） 参加費: 無料 協賛の背景 LayerXでは、広くAI・機械学習技術を活用しつつ、"業務の完全自動運転"を実現すべく複数の事業を推進しています。バクラク事業部では、あらゆるバックオフィス業務が「気づいたら終わっている」体験を届けるため、「バクラク」で提供されるAIエージェント群を開発、運用しています。Ai Workforce事業部では、エンタープライズ企業が業務ごと・組織ごとに合わせた形で、AIエージェントを「毎日の仕事」に組み込むための汎用AIプラットフォーム「Ai Workforce」を開発、提供しています。 また、我々LayerXの掲げる行動指針である「Bet AI」や「徳」の観点から、アカデミアやOSSコントリビューターの成果から一方的に恩恵を受けるだけでなく、アカデミアや技術コミュニティへの貢献を継続して行っていきたいと考えています。 LayerX行動指針 その上で、国内でも最大級の規模でアカデミアや企業の学生、研究者、開発者など様々な背景の方が集まり、幅広いトピックについて研究発表、議論、交流がなされるJSAIへと貢献することは、同様に様々な背景のメンバーが集まって幅広い技術領域における開発を進めるLayerXにとっても、そして社会の発展にとっても大変有益なことであると考えており、今回プラチナスポンサーとしてJSAI2026に協賛させていただくこととしました。 さいごに LayerXとしてJSAIに参加するのは昨年に引き続き4度目となります。昨年のJSAI2025に参加した際にも、企業ブースや懇親会、セッション聴講を通じて非常に充実した時間を過ごさせていただきました。本大会でも、是非たくさんの方と交流できればと思っております。参加者の皆様と群馬・オンラインでお会いできるのを楽しみにしております。よろしくお願いいたします！ LayerXにおけるAI・機械学習関連の記事 bakuraku.jp speakerdeck.com speakerdeck.com speakerdeck.com
- 生成AI
- セキュリティ
Microsoft Foundry Hosted Agent と Claude Agent SDK を使ったサンドボックス検証
こんにちは、LayerX Ai Workforce事業部でSWEをしているosukeです。 Webサービスの裏側など不特定多数のユーザーが操作する環境でAIエージェントを動作させるためにまず必要になるのがサンドボックス技術です。エージェントは自律的に柔軟な挙動をする反面、それらをセキュリティ的に閉じ込める必要が出てきます。 本記事では、Azure内で閉じる構成として、Claude CodeをSubprocessとして動かせるClaude Agent SDKとMicrosoft Foundry Hosted Agentというエージェントサンドボックス基盤を軸に構成の検討をしていきます。 AI エージェントにおけるサンドボックスの重要性 不特定多数のユーザーが触る環境で AI エージェントをサンドボックスで守るために、具体的には次のような要件が同時に求められます。 各ユーザーのチャット内容や添付ファイル・実行結果が、別のユーザーから見えないこと LLM が意図せず (あるいはプロンプトインジェクション的に悪意ある形で) 触ったコマンドが、ホストや他テナントのリソースに到達しないこと ファイル書き込み・ネットワーク通信・サブプロセス起動の副作用を、用途に応じて制限できること これらの個別の攻撃パターンを一つひとつ deny ルールで塞いでいくアプローチは、新しい variation が出てくるたびに穴が開きます。アドホックな個別対応は、時間とともに漏れが生じることを前提にすべきです。セキュリティは「包括的に、構造的に、多層に」組まないと持たない、というのが AI Agent の sandbox を設計するうえでの基本的な発想となります。 Hosted Agent の sandboxing Hosted Agent は、session 単位で microVM を立て、Azure VM 同士と同じ強度の境界で隔離する仕組みです。これを実機で確認するため、2 つの session で /proc/sys/kernel/random/boot_id を比較してみると、boot_id が完全に異なる、つまり session ごとに別の microVM を立てていることが実機で確認できます。 $ cat /proc/sys/kernel/random/boot_id # session A 8b86efce-0bb0-43af-b96b-72d78dfcad60 # session B bd14205a-5eb2-4145-8d0a-ac9ed6fa932d 同じ session で 2 回呼ぶと同じ boot_id が返るので、microVM の寿命が session 単位であることも確認できます。 Built-in ツール (Read / Write / Glob 等) はこの境界で防御 Claude Agent SDK の Read / Write / Edit / Glob / Grep は Agent プロセス内で完結する処理なので、microVM の filesystem に閉じています。cwd をプロジェクトディレクトリに制限し、Agent SDK の add_dirs=[] で cwd の外側を既定で読めないように制限すれば、別 session のファイルが見えてしまうことは構造的に発生しません。 問題は Bash です。Bash を allow にした瞬間、microVM 境界だけでは塞げない経路が多く出てきます。エージェントが Bash を手にすることで本来の自律的な動きが備わる一方でセキュリティ的な考慮点が大幅に広がります。 例えば、外部サービス（Model など）にアクセスするための Token など機微情報がファイルシステム上に存在しているとそれを守る必要があります。あるいは、あらゆる手段で外に抜けようとする内部通信や外部通信を防ぐ必要があります。 Hosted Agent においては Bash 実行における脅威を保護するためにもう一つレイヤを入れる必要があります。 Bash 経由の脅威を個別対応で塞ぐことはできる、しかし 同一 microVM 内で Bash が起こせる脅威に対しては、それぞれにアドホックな対応を積み重ねていけば、原理的には個別に塞ぐことができます。具体的なイメージは以下の通りです。 機微情報抽出 (Bash から token 等を読まれて外部クラウドの権限を奪取される) → 読み出しコマンドを deny rule で塞ぐ + OS の uid 分離で file permission を活用して読み取り権限自体を落とす sibling process の env 漏洩 (/proc/<別 pid>/environ 経由で同 container 内の他プロセスの secret を吸われる) → Bash subprocess の uid を分離する + container に渡す env を最小化する。同一 micro VM 内なので脅威は限定的ではある。 persistence pivot (.bashrc / CLAUDE.md を書き換えて次回起動時の hook に悪意あるコードを仕込まれる) → 設定ファイル群を read-only マウントにする + 起動時に読み込まれる設定ファイルの読み込み自体を無効化する。同一 micro VM 内なので脅威は限定的ではある。 TLS Inspection 回避経由の exfil (allowlist 許可ドメインへの SNI 偽装や DNS exfil で secret を外に持ち出される) → Firewall allowlist を最小化 + DNS 経由で wildcard 的に到達先を広げられないよう制御する アドホック対応は漏れやすい 冒頭の通り、これを「アドホックな個別対応の積み重ね」として運用しようとすると、いくつもの構造的問題が出てきます。 1: 個々の対応の境界がそもそも狭い。たとえば前述の permissions.deny の Read rule は cat / head / tail / sed のような「読み出し専用ツール」には適用されますが、ファイルを間接的に開ける任意のサブプロセス（スクリプト言語の標準ライブラリ、テキスト処理ツール、bash builtin のリダイレクト等）には適用されません。例えば Python が同梱されていれば、 python3 -c "print(open('/run/secrets/example-token').read())" のような形で deny rule を構造的に素通りできます。回避経路はこのカテゴリ全体にわたるため、コマンド単位の deny を積み上げても閉じません。 2: 新しい脅威カテゴリが見つかるたびに穴が開く。Python 経由の file read が回避経路だと分かった時に Python 対策を足す、というイタチごっこになる。 3: 監査説明性が低い。お客様のセキュリティレビューや社内監査で「どんな攻撃から守られているか」を説明するときに、個別ルールの組み合わせよりも、「OS 層の namespace で構造的に切ってあります」と言える方が説明性も再現性も高い。 要するに、AI Agent の sandbox を本気で組むなら、個別 deny rule の積み上げではなく、構造的・包括的・多層的な防御を OS / VM 境界で組むのが筋 です。 Bash sandbox のパターン比較 それを踏まえて、LLM に Bash を渡すための実装パターンを 4 つ並べました。ここでは、Hosted Agent を基盤として、Azure 内に閉じた構成にできる技術選定に絞っています。Hosted Agent は microVM 境界を提供する基盤として有用ですが、その上で Bash を sandbox 化するレイヤがもう一つ必要になります。 パターン 隔離レイヤ 実行体 (1) Hosted Agent 上で素の Bash + 個別アドホック対応 なし (個別 deny の積み上げ) container 内の実 bash (2) just-bash (Vercel) JS interpreter 層 (Node.js プロセス内) TS 製の bash 互換 interpreter (3) Azure Container Apps Dynamic Sessions で safe-bash MCP tool 別 microVM 層 (Cloud Hypervisor) 別 microVM 内の実 bash (4) Claude Code 公式 sandbox OS 層 (Linux: bubblewrap / macOS: Seatbelt) 同 container 内の実 bash を namespace で jail (1) については前節で議論した通り「アドホック対応の積み上げは漏れる前提」なので本命からは外しています。(2) と (3) も検討候補にはなりましたが、いずれも本検証では本命から外したので、まず先に短く触れます。 (2) just-bash Vercel の just-bash は TypeScript で書かれた bash 互換 interpreter + in-memory virtual filesystem で、child_process を import すらせず実 process を spawn しないというユニークな設計です。「実 bash を渡さないことで攻撃面そのものを狭める」という思想自体は綺麗ですが、ただ 2026 年 5 月時点では README にも明記の通り Beta Software で、リリース履歴もまだ若く、信頼境界に持ち込むには実績が十分とは言えない段階と考えます。 (3) Azure Container Apps Dynamic Sessions: 強い分離・重いコスト 外部の 隔離環境 (Azure Container Apps Dynamic Sessions) に bash 実行を外注する設計で、Microsoft 公式に "designed to run untrusted code" と明言されているだけあって sandbox 強度的には適した基盤として扱えます。ただ設計を進めてみると、軽い実行でもオーバーヘッドが重い、cold start考慮、並列実行のための特殊な考慮など構造的なコストが重く、Agent 体験を最優先するワークロードには合いませんでした。 (4) Claude Code Bash Sandbox: Hosted Agent と組み合わせて構造的二層防御に Claude Code (= Claude Agent SDK の CLI 部分) の Bash sandbox 機能 は、CLI binary 内に bubblewrap (Linux) を呼び出す実装が組み込まれていて、Bash tool subprocess を OS 層で jail できます。ClaudeAgentOptions.settings 経由で設定を渡すと、 mount namespace で cwd 外を ro,bind に net namespace で外向き通信を構造的に遮断 pid namespace で sibling process 不可視 user namespace で uid 分離 filesystem deny/allow rule で JWT 等の secret を物理マスク これらを OS の namespace 機構で一括して構造的に切ってくれます。 ただ、Bash sandbox を使うためには、上記のように非特権プロセスが syscall で namespace を作れる環境である必要があります。実は、Hosted Agent はマネージドサービスでありながらこの点で相性が良く、VM 境界に信頼をおいているゆえ、namespace を切ることができるようです。 実機で sandbox 有効状態にして、各種検証したログがこちらです。 # 1. federation token の読み出し — denyRead が OS 層で mask $ cat "$EXAMPLE_TOKEN_FILE" # 機微情報を保持する環境変数 (例: federation token のパス) cat: /run/secrets/example-token: No such file or directory # 2. Python 経由で同じファイルを開いてみる — Python でも同様に存在しないことになっている $ python3 -c "open('/run/secrets/example-token').read()" Traceback (most recent call last): File "<string>", line 1, in <module> FileNotFoundError: [Errno 2] No such file or directory: '/run/secrets/example-token' # 3. sibling process の environ を覗く — pid namespace 分離で jail 内の pid しか見えない $ ls /proc | grep -E '^[0-9]+$' 1 2 4 $ cat /proc/123/environ cat: /proc/<span class="s
- 生成AI
- Azure
- セキュリティ