コンテンツにスキップ

Guide

Cookbook

Reference

Concepts

サンドボックスとパーミッション：直交する関心事

Reyn には、ワークフローができることをゲートする 2 つの独立したシステムがあります。これらは完全に直交しています——それぞれ異なる問いに答え、異なるレベルで設定されます。両者を混同することはよくある混乱の原因です。

パーミッション：ワークフローはこの能力を使えるか？

skill.permissions（skill.md フロントマターで宣言）は特定のワークフローのアクセスポリシーを記述します：

  • どのファイルパスを読み書きできるか？
  • ネットワークリクエストを発行できるか？どのホストに対して？
  • シェルコマンドや MCP ツールを呼び出せるか？

パーミッションはワークフローレベルです：各ワークフローが独自に宣言し、オペレーターまたはユーザーが承認します。ランタイムは論理積パーミッションモデルの AgentLayer を通じて強制します。

# skill.md
permissions:
  file.write:
    - path: "{{workspace}}/output"
      scope: recursive
  http.get:
    - host: "api.github.com"

設定者： ワークフロー作成者が宣言し、オペレーター / ユーザーが承認。 答える問い： 「この op はこのワークフローに許可されているか？」

サンドボックス：ワークフローはどのように閉じ込められているか？

sandbox（reyn.yaml の sandbox: 以下、または CLI フラグで設定）は agent の封じ込めモデルを記述します：

  • どのバックエンドが分離を強制するか（Seatbelt / Landlock / コンテナ / なし）？
  • どのコンテナイメージを使うか？
  • どのファイルシステムマウントやネットワーク制限を適用するか？

サンドボックスはagent レベルです：ワークフローごと・フェーズごとではなく、1 つのサンドボックス設定が agent 全体に適用されます。これはワークフロー作成者が宣言するものではなく、オペレーターのデプロイ設定の一部です。

# reyn.yaml
sandbox:
  backend: auto     # auto | seatbelt | landlock | noop

設定者： オペレーター。 答える問い： 「ワークフローを実行するプロセスはどのように閉じ込められているか？」

組み合わせ方

パーミッションとサンドボックスは独立して論理積で適用されます：

allowed = permission_check(skill, op) AND sandbox_check(backend, op)

パーミッションシステムが許可する op でも、サンドボックスが拒否することがあります——たとえば http.get: [{host: "api.github.com"}] パーミッションを持つワークフローが network: false サンドボックスポリシー下で実行される場合、サンドボックスレイヤーで拒否されます。ワークフロー作成者はオペレーターのサンドボックス設定を上書きできません。

逆に、サンドボックスがパーミッションシステムの拒否するものを許可することもあります——たとえば広いサンドボックス設定があっても、宣言していないシェル ops をワークフローに許可することにはなりません。

まとめ

軸 パーミッション サンドボックス
レベル ワークフローレベル agent レベル
宣言者 ワークフロー作成者 オペレーター
承認者 ユーザー / オペレーター オペレーター（設定 / CLI）
対象 op アクセスポリシー（このワークフローは何をできるか？） 封じ込め（プロセスはどのように分離されるか？）
定義場所 skill.md フロントマター permissions: reyn.yaml の sandbox: / CLI

参照

  • Permission model — 認可レイヤー、論理積制限モデル、保護された書き込みパス

On this page