チームのガバナンスは、3つの要素が連携することで成り立ちます。誰が何をできるかをスコープする RBAC、すべての特権操作を記録する監査ログ、そしてオートメーション、シークレット、Runを組織ごとに名前空間化するテナンシーです。これらはいずれもFlowの実行方法を変えません。誰がそれを実行できるかを決め、誰が実行したかの検証可能な証跡を残します（tenet T6）。

​
RBAC — ownerとmember

ホスト型サービスのRBACは意図的に小さく作られています。組織メンバーシップは2つのロール（RoleSchema）のうち必ず1つに解決され、すべてのリクエストでサーバー側でチェックされます。Cookieからの値を信用することはありません。
ロールできること
ownermemberができるすべてに加えて、APIキーの発行/取り消し、メンバーの追加/変更/削除、スケジュールの作成/削除、オーサリングの操作（Recordingの開始、一時停止したキャプチャの再開、手順の編集、公開）
member組織全体で読み取り専用: オートメーションの表示、Runの検査、ライブビューの監視
requireRole(wrapper, "owner") はowner専用の各mutationをゲートし、requireSession の後に実行されます。ownerではないユーザーには、リソースの存在有無を漏らす404ではなく、403 forbidden が返ります。有効なセッションCookieがないリクエスト（または組織がすでに存在しないリクエスト）は、ロールチェックが実行される前に401になります。
ロールがゲートするすべてのmutationは、actor（session:<user> または api_key:<id>）とタイムスタンプとともに、下の監査ログへ書き込まれます。そのため、「誰がXを行うことを許可されているか」と「実際に誰がいつXを行ったか」の両方を、同じシステムから答えられます。

​
Last-owner protection

組織がowner不在の状態になることはありません。組織の最後のownerを member に降格する、または完全に削除する操作は、409 last_owner で拒否されます。これはUIで無効化されるだけではなく、現在のメンバーシップ数に対してサーバー側でチェックされます。 
// PATCH /api/members/:userId  { "role": "member" }  — 組織で唯一のowner
// → 409
{ "error": "last_owner" }
同じガードは DELETE /api/members/:userId にも適用されます。これにより、mutation権限を持つ全員を降格/削除してしまい、チームが自分たちの組織から締め出される事態を防ぎます。

​
キーごとのスコープ — 最小権限

ダッシュボードでキーを発行する方法は、PlaygroundとAPIキーを参照してください。このセクションではスコープモデルを扱います。
ownerはAPIキーの発行時に、任意で scopes allowlistを付けられます。これはそのキーが到達できるオートメーション名のリストであり、2つのプログラム向けサーフェスで同じように強制されます。
  • POST /v1/run/:flow — REST実行ゲートウェイ
  • POST /mcp — ホスト型MCPエンドポイント
// POST /api/keys
{ "name": "reporting bot", "mode": "live", "scopes": ["daily-price-watch"] }
scopes の省略、null、[] は、いずれも unscoped に正規化されます。そのキーは組織内のすべての公開済みオートメーションに到達できます。これは、スコープが存在する前に発行されたすべてのキーの挙動でもあります（移行なし、暗黙のロックアウトなし）。
最小権限は、意図的に2つの異なるレイヤーで強制されます。
  • /v1/run/:flow — スコープ外の呼び出しには 403 { "error": "forbidden" } が返ります。これは存在しない、またはドラフト状態のオートメーションと同じレスポンスです。そのため、スコープ付きキーは「これは実行できない」と「これは存在しない」を区別できません。
  • POST /mcp — スコープ外のオートメーションは、そもそもToolとして登録されません。スコープ付きキーの tools/list には単に含まれません。最小権限は tools/call で強制されるだけでなく、Tool discoveryにも現れます。
キーの mode は、独立した直交するゲートです。test モードのキーは、スコープに関係なく、secret型の入力を宣言する任意のオートメーションで拒否されます（403 test_key_forbidden）。詳しくはシークレットを参照してください。
シークレットの値は、ロールに関係なくRun Inspectorで公開されることはありません。最も高い権限を持つオペレーターであっても、シークレットがマスクされた入力だけを見ます。RBACは誰が操作できるかを管理します。境界の不変条件は何が表示され得るかを管理します。そして、シークレット値がFlowSpec、Journal、ログに存在しないことは、オフにできる権限設定ではありません。

​
RBACとシークレットの相互作用

daily-price-watch では、条件付きの http.post 手順が secrets capabilityを宣言し、secret.WEBHOOK_URL を参照します。プレーンの Secrets providerは、実行時にワーカー上でその値を解決し、その手順だけに注入します（シークレットを参照）。Run Inspectorは後で、その手順が実行されたこと、マスクされた入力、解決されたToolのcontract digestを表示しますが、webhook URL自体は決して表示しません。したがって、Runの読み取りアクセスを完全に持つ読者であっても、起きたことの形は見えますが、そのとき使われたシークレットは見えません。

​
監査ログ

ownerでゲートされたすべてのmutationは、append-onlyで組織スコープの監査ログに、actor（session:<user> または api_key:<id>）、timestamp、target IDとともに書き込まれます。
アクション記録される内容
key.issuedactor、時刻、新しいキーのmodeと表示用prefix、そのscopes（null = 明示的にunscoped）— ハッシュや平文は決して記録しない
key.revokedactor、時刻、取り消されたキーのmodeとprefix
automation.publishedactor、時刻、オートメーション、liveになったdigest
secret.provisionedactor、時刻、slot名 — 値は決して記録しない
schedule.created / schedule.deletedactor、時刻、スケジュールとそのオートメーション
member.added / member.role_changed / member.removedactor、時刻、対象メンバーとロール
すべての監査行の metadata には、非シークレットの手がかり（slot名、キーmode、prefix、ロール）だけが入ります。シークレット値、キーハッシュ、平文は決して入りません。これはRun Inspectorが強制するものと同じ境界の不変条件を、監査証跡に適用したものです。

​
テナンシー — ワークスペースごとの名前空間

Registry、シークレット、Runは、ワークスペースごとに名前空間化されます。ホスト型サービスでは、ワークスペースは組織です。すべてのオートメーション、APIキー、シークレット、Run ref、メンバーシップがスコープされる同じ org_id であり、RBAC（owner/member）とキーごとのスコープはいずれも組織相対です。ワークスペースが分離の単位です。
1

Registry

ワークスペースのRegistryに公開されたPackは、そのワークスペース内で表示および解決できます。Replication（browserflow registry mirror）はPackをRegistry間で明示的に移動し、到着時にdigestを検証します。そのため、ワークスペース境界を越えることは、暗黙の可視性ではなく、意図的で監査された操作です。レプリケーションを参照してください。
2

シークレット

ワークスペースのシークレットは、そのワークスペース内のRunに対してのみ仲介されます。secret.WEBHOOK_URL は、それを所有するテナント内で解決され、別のワークスペースのRunへ漏れることはありません。
3

Run

RunとそのJournalはワークスペースに属します。Run Inspectorと browserflow inspect は、Runを所有するワークスペースにスコープされた同じJournalを読みます。テナントごとに分離された、単一の信頼できる情報源です。

​
オープンコア境界

このサービスはオープンコアかつオプトインです。採用してもFlowの実行方法は決して変わりません。境界は、再現性や移植性に不可欠なものがサービスの背後に置かれないように引かれています。
ティア内容ライセンス
Engine + SDK + std packs + CLI作成、コンパイル、実行、リプレイ、pack、launch — 完全にセルフホスト可能Apache-2.0
Serviceホスト型Registry、scheduler、secrets broker、RBAC、Run Inspector、replicationオープンコア。セルフホストまたはマネージド
EnterpriseSSO、fine-grained RBAC、監査エクスポート、private browser pools、オンプレミスサポート商用
無料のエンジンで構築され、検証されたFlowは、有料サービスでも同一に実行されます。サービスが追加するのはcoordinationであり、capabilityではありません。
Engine、SDK、standard packs、CLIはApache-2.0で、完全にセルフホスト可能です。インフラなし、サービスなしで、daily-price-watch を作成、コンパイル、実行、リプレイ、pack、launchできます。再現性（FlowSpec digest、Journal、--verify によるリプレイ）は、完全にここにあります。
チームのためのcoordinationです。ホスト型Registry、scheduler、secrets broker、RBAC、Run Inspector、replicationが含まれます。このティアはセルフホストすることも、マネージドで使うこともできます。Runをスケジュールし、観測しますが、2つ目のエンジンになることはありません。実行は常にワーカー上の同じ Rider だからです。
SSO、fine-grained RBAC、監査エクスポート、private browser pools、オンプレミスサポートです。これらは、Flowの実行方法を変えずに、上で説明したガバナンスを拡張します（たとえば、content-addressedな監査証跡を外部システムへエクスポートする、ロールスコープをより厳密にするなど）。
この境界は再現性をサービスの外側に保つため、RBACと監査はcoordinationとaccountabilityのためのものであり、結果を再現する能力をゲートするためのものではありません。無料のエンジンで証明されたdigestは、サービスがデプロイ、スケジュール、監査するdigestと同じです。

​
関連

可観測性

Run InspectorはJournalを読みます。すべてのロールでシークレットはマスクされます。

シークレット

brokerが secret.WEBHOOK_URL をFlowSpec内ではなくワーカー上で解決する仕組み。

コントロールプレーン

Runをスケジュールし、観測する任意のcoordinator。設計上オプトインです。