定義
スコープは開発者が初回サインインしたタイミングで作成されます。それ以降に登録される API キー・スキーマ・回路・ジェネレータ・ドキュメント・証明には、外部キーとしてそのスコープ ID が刻まれます。Dashboard・workers API・オンチェーンフックいずれも、データを返す前にスコープでフィルタを通します。
スコープは発行者の身元とは別の概念です。1 つの法人が production / staging / partner-x のように複数のスコープを運用することもできますし、逆に 1 つのスコープから、運用文脈に応じて複数の発行者 DID で署名することも可能です。
リソースの CRUD 分離は UI 層ではなく workers API 層で強制されます。スコープ A で認証されたリクエストは、たとえ直接 API を組み立ててもスコープ B のリソースを読み書きできません。bearer token のチェックがルートハンドラに入る前に scope_id へ解決される設計になっています。唯一の意図的な横断経路が attributes.query で、これは設計上スコープを横断して検証済み属性を読み取る読み取り専用のクエリ面です（CRUD 経路ではありません）。
Lemma での実装
スコープは D1 上のすべてのテーブルに対する join key です。x402 のサービスルート、MCP のツールアクセス、Dashboard の "my-resources" ビューはいずれも scope_id で絞り込みます。サインイン時に発行される最初のキーはスコープを保持し、キーをローテーションしてもスコープは変わりません。
スコープ単位の制御（レートリミット、課金集計）は、ワークスペースのチーム切替に近い感覚で開発者がスコープ間を移動できるよう設計されています。境界が縛るのはリソースの CRUD であり、検証済み属性のクエリは意図的な scope 横断の読み取り経路です。
マルチテナント運用において、スコープはプライバシーの単位でもあります。選択的開示 や BBS+ プレゼンテーションは、外部に出る前にスコープ内で評価されます。