Vault の認可

この文書では、ローカルデーモンの認可サービスと SaaS Center の認可 HTTP インターフェースを説明します。以下のローカル RPC 操作は、共有コア、CLI、および MCP の認可ツールで利用できます。 既存の memories mcp grant、memories mcp revoke、Center チケットのインポート、および Vault の監査コマンドは、更新されたコアのチェックを使用します。

ロールとスコープの上限

スコープの省略は allow_all ではなく read を意味します。これはローカルの権限付与、Center チケットの発行、静的なホスト型権限付与、およびメンバーの作成に適用されます。明示的な従来の write: true は引き続き read_write を選択し、write: false は read を選択します。 write は引き続き書き込み専用スコープです。allow_all には明示的な選択と Owner の発行者が必要です。現時点では通常のアセットのコンテンツ操作について read_write_delete と同じ範囲を対象としますが、この要件は変わりません。

発行時には、発行者の現在の Vault ロールと、Bearer による呼び出しの場合は発行元の権限付与のスコープの両方をチェックします。権限付与は別の Vault を認可したり、いずれかの上限を超えたり、親より長く有効になったりすることはできません。有効期間は 1–60 分です。より広い権限や長い有効期間を求めるリクエストは、要求されたスコープを黙って縮小するのではなく失敗します。 受領者は、選択した Vault のメンバーである必要があります。コンテンツの権限付与によってメンバーに追加のコンテンツアクセスを与えることはできますが、ロールは変更されません。広い権限付与を持つ Editor や Reader でも、委任やリクエストの承認はできません。

権限付与のレコードは、id、vault、scope、issued_by（メンバー ID）、grantee、parent（発行元の権限付与 ID、または null）、depth、および Unix 秒の expiry を公開します。権限付与 ID は Bearer トークンとは独立した、ランダムで不透明な識別子です。発行時にトークンを返すのは一度だけで、アクセス一覧や権限付与一覧には含まれません。権限付与 ID、リクエスト ID、およびプリンシパル ID は不透明な正規識別子です。クライアント向け Vault ID は通常の短縮 ID 表現を維持します。

ローカルの Admin/Owner による権限付与の発行には、ロック解除済みの Vault が必要ですが、ターミナルでの権限昇格は不要です。失効にも権限昇格は不要ですが、権限付与の発行者、またはその Vault の現在の Admin/Owner のみに許可されます。失効は子孫にも波及します。 発行者または受領者の削除、あるいは発行者のロールを発行済みのスコープ未満に引き下げる操作は、ポリシーがコミットされた時点で、影響を受ける権限付与とその子孫を無効にします。同期によってインポートされたポリシー変更や、再起動後の変更も含まれます。 権限付与は、SHA-256 Bearer ハッシュと認可メタデータのみを使用して、暗号化されたデバイスローカルの Store に永続化されます。認証ではハッシュを定数時間で比較します。失効と子孫の削除は、暗号化された状態とともにコミットされます。ロックするとメモリ内の権限付与と Store キーが破棄され、ロック解除まで全権限付与が使用できなくなります。期限内の権限付与は、ロック解除またはデーモン再起動後に再開します。絶対有効期限は永続化され、期限切れの権限付与とその子孫は、読み込み時およびデーモンの定期処理時に削除されます。権限付与は Vault の同期や復旧用バックアップにはエクスポートされません。

メンバーシップ変更とデバイス承認では、新しい Admin/Owner 要件に加えて、既存の権限昇格チェックも維持されます。招待の作成には、少なくとも 1 つのローカル Vault における Admin/Owner メンバーシップが必要になりました。Vault を持たない呼び出し元や、Editor/Reader メンバーシップしか持たない呼び出し元は、安全のため拒否されます。Admin は Admin メンバーシップを管理できますが、Owner の追加、削除、変更はできません。所有権の変更には署名付き所有権移転操作を使用し、Owner がちょうど 1 人である状態を維持します。

権限リクエスト

指定受領者と委任の深さ

デーモンとホスト型 Center は、要求するコンテンツスコープが read だけであっても、受領者のロールが発行者の実効ロールより高い場合は発行を拒否します。Center は予約済みの受領者 center-admin も拒否します。以前に永続化された、この対象を持つ権限付与も含まれます。

権限付与による呼び出し元は、実際の発行者と異なる対象で権限付与の権限を使用します（subject != issued_by）。このような呼び出し元はリクエストを作成できますが、自分のリクエストを含め、どの権限リクエストも承認、拒否、キャンセル、取得できません。デーモンは Unauthorized を返し、Center は HTTP 403 を返します。これらの呼び出し元は承認者としての資格を持ちません。自己発行の権限付与には、既存のリクエスト規則が維持されます。Center での取得には、引き続きリクエスト者の永続的なメンバー認証情報が必要です。Center の永続的なメンバー Bearer はメンバーの権限であり、委任された権限付与の権限ではありません。

デーモンは、リクエスト者の認証情報への厳密なバインドを維持します。指定受領者の Bearer で作成したリクエストは、後から別のメンバー認証情報で取得できません。取得に使用するメンバー認証情報または自己発行の認証情報で、そのリクエストを作成し直してください。一方、Center は取得をリクエスト者の永続的なメンバー Bearer にバインドします。

両実装は pub const MAX_DELEGATION_DEPTH: u32 = 2 を定義します。 メンバーが直接発行した権限付与の深さは 1 です。権限付与の権限による発行は、取得時に遅延承認の親を使用する場合も含め、深さが parent.depth + 1 になります。深さ 3 は拒否されます。depth は永続化され、権限付与の概要、発行レスポンス、アクセス表示、および発行済み権限付与一覧に含まれます。depth のない従来のレコードは親チェーンから再構成されます（親のない権限付与は深さ 1）。欠落、循環、または上限超過の祖先チェーンは安全のため拒否され、読み込み時に削除されます。Center 内部の永続的なメンバー認証情報は深さ 0 であり、委任された権限付与ではありません。

委任による発行では、指定受領者を自己発行のプリンシパルに変えるのではなく、親チェーンを通じて実際の発行者を維持します。呼び出し元の実際の発行者を判定する際には、既存の従来のチェーンもチェックされます。

指定受領者の権限付与を使用して記録された従来の遅延承認も、取得時に安全のため拒否されます。資格のあるメンバーの権限で新しい承認を取得してください。

破壊的変更：より高いロールの受領者と center-admin の受領者には、権限付与を発行できなくなりました。指定受領者の Bearer は、権限の決定、キャンセル、取得に参加できなくなりました。2 つの権限付与を超える深さのチェーンは使用できなくなりました。権限の決定と取得にはメンバー認証情報を使用し、追加の委任が上限を超える場合は新しいルート権限付与を発行してください。

現在のメンバーは誰でも、Vault 内の自分のアクセスについてリクエストを送信できます。

{
  "op": "request_create",
  "vault": "VAULT",
  "target": {"type": "scope", "scope": "read_write"},
  "reason": "Update the shared project notes",
  "duration_minutes": 15,
  "approvers": []
}

target は {"type":"scope","scope":"..."}（スコープの既定値は read）または {"type":"role","role":"editor"} です。理由、有効期間、および承認者は省略できます。スコープの承認では、有効期間を省略すると既定値は 30 分です。ロール変更は恒久的です。ロールリクエストに有効期間を指定すると拒否され、時間制限のある権限付与の呼び出し元は恒久的なロール変更を承認できません。ロールリクエストの承認には、メンバーロールの直接変更と同じ、呼び出し元にバインドされた権限昇格が必要です。Owner が Owner ロールのリクエストを承認すると、署名付き所有権移転が実行されます。

承認者リストが空の場合、その Vault の現在のすべての Admin/Owner メンバーに通知されます。それ以外では、リストにあるメンバー ID のみが決定できます。記載されたすべての ID は作成時に Admin/Owner メンバーである必要があり、決定時にも資格が再チェックされます。Reader と Editor は承認者として指定できません。リクエスト者は Admin/Owner や指名された承認者であっても、自分のリクエストを承認または拒否できません。キャンセルは引き続き可能です。スコープまたはロールの承認は、承認者のロールと Bearer スコープの範囲内である必要があり、スコープの有効期限は親の期限内である必要があります。 上限を超えた承認では、リクエストは保留のままになります。

リクエストは pending から approved、rejected、または cancelled へ、ちょうど一度だけ遷移します。保留中のリクエストをキャンセルできるのはリクエスト者だけです。スコープの承認では、Bearer を発行せずに権限付与パラメーターを記録します。リクエスト者は request_claim を一度だけ使用してトークンを発行し、受け取ります。request_list はメタデータのみを返します。作成、世代、および権限付与の有効期間は取得時に開始し、記録された親の有効期限を上限とします。承認と取得の状態はロックや再起動を越えて保持されますが、失効または期限切れの承認権限では取得を認可できません。平文トークンは、リクエスト状態や永続化された Store 状態に保持されません。取得済みの権限付与は、ハッシュとメタデータとしてロックや再起動を越えて保持されます。リクエストとトークンは Vault の同期にはエクスポートされません。

request_list は、呼び出し元自身のリクエスト（決定済みのものを含む）と、その呼び出し元に決定資格がある保留中のリクエストを返します。他のメンバーは、宛先が指定されたリクエストを閲覧できません。Vault が保存できるリクエストは最大 1,000 件で、理由は 4,096 バイトに制限されます。ローカルデーモンとホスト型 Center の両方で、同時に有効な権限付与は最大 10,000 件です。

保留中の上限：リクエスト者は Vault ごとに最大 20 件、Vault 全体では最大 200 件の保留中リクエストを保持できます。上限を超えた作成は制限エラーで失敗します（ホスト型 Center では HTTP 429）。保留中、および承認済みで未取得のリクエストは 7 日後に期限切れになります（request.expire、アクター system として監査されます）。決定済みリクエストは最後の遷移から 30 日後に削除されます。

RPC 操作とインターフェース

デーモンの JSON op 名は次のとおりです。

従来の mcp_grant と mcp_revoke は引き続きサポートされます。Bearer の呼び出し元は、自分の権限付与の Vault に対してのみこれらの認可 RPC を使用できます。これによって MCP がターミナルの権限昇格を継承したり、保存済み認証情報にアクセスしたりすることは許可されません。モバイル FFI は引き続き権限付与管理と新しい権限リクエスト操作を拒否します。ネイティブ ABI の変更は不要です。

access_list は、owner、admin、editor、reader に分類された principals に加え、有効な grants、devices（Vault ポリシーにある認可済みで未失効のデバイス：device、所有する member、name。ポリシーは作成時刻を記録しません）、pending_requests、および approved_unclaimed_requests（それぞれ id、requester、スコープまたはロールの target、approvers リストまたは "broadcast"、Unix 秒の created と expires を持つ）を返します。閲覧権限は引き続き Admin/Owner に限定されます。grant_list はプリンシパルのグループを含まない {"vault":"VAULT","grants":[...]} を返します。発行済みの各権限付与には id、parent（ルート権限付与では null）、issued_by、grantee、scope、vault、Unix 秒の expiry、generation、depth、および利用可能な場合は Unix 秒の created が含まれます。ローカルの世代は発行時にコミットされた状態の世代であり、一覧取得時の現在の世代ではありません。期限切れまたは失効した権限付与は除外されます。Admin/Owner は Vault 内の全権限付与を一覧できます。他の現在のメンバーは、自分が発行した権限付与のみ一覧でき、単に受け取った権限付与は一覧できません。Bearer の呼び出し元は引き続き自分の権限付与の Vault にバインドされます。どちらのレスポンスにも、トークン、Bearer ハッシュ、アセット本文は含まれません。デーモン RPC、MCP の grant_list、および memories grant list VAULT は、このサービスレスポンスを共有します。

CLI ラッパーは、次の正確なコマンドで実装されています（ID は不透明です）。

memories access list VAULT
memories grant issue VAULT --minutes N [--scope S] [--grantee ID]
memories grant list VAULT
memories grant revoke VAULT ID
memories request create VAULT [--scope S | --role R] [--reason T] [--duration M] [--approver ID]...
memories request list VAULT
memories request approve VAULT ID
memories request claim VAULT ID
memories request reject VAULT ID [--reason T]
memories request cancel VAULT ID
memories audit list VAULT [--verify-only]

従来の memories audit VAULT [--verify] 構文は引き続きサポートされます。スコープの既定値は read です。有効期間を指定しないローカルのスコープリクエストでは、デーモンの承認の既定値である 30 分を維持します。ロールリクエストに有効期間を含めることはできません。出力は通常の CLI エンベロープ内の JSON です。

ホスト型 Center の同等コマンドは、HTTP 認可ルートを使用します。

memories center access VAULT
memories center grant issue VAULT --minutes N [--scope S] [--grantee ID]
memories center grant list [VAULT]
memories center grant revoke ID
memories center request create VAULT [--scope S] [--reason T] [--duration M] [--approver ID]...
memories center request list [VAULT]
memories center request approve ID
memories center request claim ID
memories center request reject ID [--reason T]
memories center request cancel ID
memories center audit [--vault V] [--format json|jsonl]

これらのコマンドは --center-url を受け付けます。指定しない場合は MEMORIES_CENTER_URL または設定済みの SaaS Center を使用します。MEMORIES_CENTER_TOKEN が設定されていればそれを使用し、そうでなければ MEMORIES_CENTER_ADMIN_TOKEN を使用します。権限エラー時に別の Bearer で再試行することはありません。ホスト型リクエストはスコープをサポートし、ローカルのロール変更はサポートしません。スコープの既定値は read、リクエストの有効期間の既定値は 30 分です。JSONL 監査エクスポートは CLI エンベロープを付けず、1 行に 1 つの JSON エントリを出力します。それ以外の出力は JSON エンベロープを使用します。

デーモンの MCP ツールは access_list、grant_issue、grant_list、grant_revoke、request_create、request_list、request_approve、request_claim、request_reject、request_cancel、および audit_list です。引数は上記の RPC フィールドに従います（権限付与の発行には minutes、リクエストの作成には target と duration_minutes、監査には verify_only）。権限付与スコープまたはリクエスト対象を省略した場合の既定値は read です。すべての呼び出しは既存の MCP ケイパビリティを使用し、ターミナルの権限昇格やホスト型 Center の Bearer を使用することはありません。

SaaS Center は GET /v1/access/{vault}、POST/GET /v1/grants、DELETE /v1/grants/{id}、POST/GET /v1/requests、POST /v1/requests/{id}/approve|claim|reject|cancel、および Admin/Owner 専用の GET /v1/audit を実装します。これらのルートにはホスト型モード（--data）が必要です。 正確な HTTP 本文、クエリパラメーター、レスポンス、および永続化ファイルについては Center ガイド を参照してください。

SaaS Center の認可

ホスト型メンバーは、コンテンツ scope とは独立した、省略可能な明示的 role（reader、editor、admin、owner）を持ちます。role を省略した場合、既存のスコープ階層は Reader（read）、Editor（write/read_write）、Admin（read_write_delete）、または Owner（allow_all）に対応付けられます。オペレーター Bearer は、ホスト型 Vault 全体で center-admin Owner として動作します。静的 Bearer のプリンシパルは static:OPAQUE_ID ID と同じスコープからロールへの対応付けを使用します。メンバー ID に予約済みの center-admin 名は使用できません。コンテンツスコープは、Reader/Editor の受領者を管理ロールへ昇格させません。

POST /v1/grants では scope の既定値は read、duration_minutes の既定値は 30 です。minutes は有効期間の別名です。発行には Admin/Owner ロールが必要で、ローカルでの発行と同じロール、スコープ、Vault、有効期限の境界が適用されます。レスポンスは受領者に subject を使用し、parent、issued_by、expiry、generation、および depth を含みます。権限付与トークンは発行または取得のレスポンスにのみ含まれ、承認、一覧、監査には決して含まれません。 メンバーによる呼び出しでは、受領者の既定値は発行者です。明示的な grantee は、選択した Vault に存在するプリンシパルを識別する必要があります。オペレーターが grantee を指定せずに発行すると、権限付与 ID で識別される匿名の権限付与プリンシパルが作成され、center-admin 対象にはなりません。これはホスト型チケットの発行にも適用されます。

各ホスト型メンバーは、永続化された世代カウンターを持ちます。発行された権限付与は、発行時に発行者と受領者の世代の両方を固定します。認証によって更新されることはありません。メンバーのスコープ、ロール、Vault の変更、または削除は、そのメンバーの世代のみを増やします。削除済みメンバーのカウンターは保持されるため、ID を再作成しても世代はリセットされません。 削除または更新により、そのメンバーが発行した、または受け取った権限付与とすべての子孫が、監査レコードとともに失効します。無関係な権限付与は引き続き動作します。公開される generation フィールドは、発行時の受領者の世代です。静的プリンシパルとオペレータープリンシパルの世代は固定です。永続的なメンバー認証情報が再確立されるのは明示的なポリシー遷移時のみで、認証によって再確立されることはありません。

ホスト型で発行された権限付与は、所有者のみがアクセスできる DIR/grants.json により再起動を越えて保持されます。このファイルには SHA-256 Bearer ハッシュ、固定された世代、有効期限と親のメタデータ、および失効情報のみが含まれます。ハッシュ比較は定数時間です。期限切れの権限付与とその子孫は、読み込み時、定期的な処理、および認証や発行時に削除されます。ロックは Store キーを破棄し、権限付与を失効させずに停止します。期限内の権限付与と静的または永続的な認証情報は、ロック解除後に再開します。永続化の失敗はサービスをロックし、権限の復活を危険にさらすのではなく、オペレーターによる修復と再起動を必要とします。

POST /v1/requests は vault、省略可能な scope、reason、duration_minutes（別名 duration）、および approvers を受け付けます。空または省略された approvers は、資格のある Admin/Owner の保留中リクエスト一覧を通じて通知されます。ID を指定すると、その宛先にリクエストが送られます。GET /v1/requests は、呼び出し元が所有する、またはその承認権限内にある保留中のリクエストと、リクエスト者の承認済みで未取得のリクエストを返します。必要に応じて vault で絞り込めます。承認と拒否の両方で、選択した承認者のロール、スコープ、Vault、有効期限の権限が必要です。リクエスト者は Admin/Owner や指名された承認者であっても、自分のリクエストを承認または拒否できません。キャンセルできるのはリクエスト者だけです。1 つの決定が直列化されて永続化され、繰り返すと 409 が返ります。承認は status: approved、claimed: false、および検証済みのスコープ、有効期間、発行者の境界を含む request メタデータのみを返し、権限付与の発行やトークンの返却は行いません。その後リクエスト者は、永続的なメンバー Bearer を使用して POST /v1/requests/{id}/claim を呼び出し、request と一度限りの grant レスポンスを受け取ります。承認者、他のメンバー、および同じ対象に対する他の権限付与は、それらの認証情報で取得できません。2 回目の取得は 409 を返します。世代、作成時刻、および有効期間は取得時に開始し、有効期限は承認権限の記録済み有効期限を上限とします。失効または期限切れの承認認証情報、あるいは変更されたメンバー世代を使って取得することはできません。

デーモンは、スコープリクエストに同じ遅延発行フローを使用します。request_approve は承認の境界を保存し、request_claim は権限付与メタデータと token を一度だけ返します。ローカルの OS 認証済み呼び出し元は、引き続きリクエストしたメンバーである必要があります。MCP はリクエストを作成した正確なケイパビリティを提示する必要があり、同じ対象の別の権限付与では代用できません。一覧はトークンを返しません。ロールの承認は引き続き即時のポリシー変更であり、取得可能な権限付与はありません。暗号化された Store 状態と DIR/requests.json にはリクエストメタデータのみが含まれ、権限付与では Bearer ハッシュのみが永続化されます。起動時には Center の決定と取得を検証済み監査と照合するため、メタデータ保存の中断によって決定や取得済みリクエストが再び開かれることはありません。 成功した取得のレスポンスが失われた場合、トークンを再取得することはできません。代わりに新しい承認をリクエストしてください。

監査形式と検証

ローカル監査エントリは vault、previous、sequence、timestamp、action、object、result、署名証明書、および署名を維持します。新しい省略可能なトップレベルフィールドは actor、subject（受領者）、scope、expiry、parent、reason、issued_by、via_grant、および request_id です。アクターは操作を行うメンバーを識別し、署名者はイベントを記録するデーモンデバイスを識別します。したがって委任された操作では、アクターと署名ユーザーが異なることがあります。監査エントリにパスワード、保存済み認証情報、Bearer トークンは含まれません。

権限付与の権限によって作成されたエントリには issued_by（実際の発行者）と via_grant（呼び出し元の権限付与 ID）が含まれ、actor は引き続き権限付与の対象です。発行イベントの例外（mcp.grant / Center の grant.issue）では、委任による発行を含め、実際の発行者を actor、受領者を subject として記録します。両方の省略可能フィールドは serde の既定値を使用し、存在しない場合は省略されるため、古い署名付き監査と Center JSONL ログのシリアライズと検証を維持します。ホスト型コンテンツの監査は、共有 Store 内に同じ帰属情報を保持します。

監査は、デバイスごとの署名付きハッシュチェーンです。previous は直前のシリアライズされた署名付きエントリの SHA-256 ハッシュを指し、監査マップはそれらのハッシュをキーとします。Vault::verify は署名、ハッシュ、シーケンスの連続性、および既存の Vault 履歴の不変条件を検証します。古いレコードは新しい全フィールドを省略し、従来の署名バイトとハッシュを正確に維持します。新しいフィールドは serde の既定値を使用し、存在しない場合は省略されます。値がある詳細は署名の対象です。

イベントには、既存のメンバーシップとデバイスのイベントに加え、device.authorize、mcp.grant、mcp.grant.center、mcp.revoke、session.lock、session.unlock、および request.create|request.approve|request.claim|request.reject|request.cancel が含まれます。明示的なロックは監査の永続化エラーを伝播させますが、ロック解除状態は消去します。ライフサイクルまたはアイドルによるロックは監査を試み、永続化が失敗しても必ず状態を消去します。監査レコードを保存するために秘密をロック解除されたままにしてはいけません。ロック中の失敗では監査に署名できません。

SaaS Center は、ローカルの署名付き監査形式とは別の、追記専用でモード 0600 の DIR/audit.jsonl SHA-256 チェーンを持ちます。GET /v1/audit は Admin/Owner を必要とし、vault と format=json|jsonl を受け付け、絞り込みやエクスポートの前にチェーン全体を検証します。Vault にバインドされた管理者は別の Vault のイベントを読めません。オペレーターはグローバルなロック、ロック解除、登録イベントも閲覧できます。エントリには sequence、timestamp、prev_hash、hash、action、actor、subject、scope、vault、expiry、parent、reason、request_id、および object が含まれ、省略可能な詳細は null です。ハッシュはシリアライズされたタプル (sequence, timestamp, prev_hash, event_fields) を対象とします。prev_hash は最初のエントリでは null、それ以降は直前のエントリのハッシュです。

crates/center/src/saas/audit.rs の verify_audit_chain(path) は、ハッシュ、シーケンスの連続性、直前のハッシュ、および完全な JSONL 行をチェックします。起動時に既存ファイルを検証し、追記や読み込みでもそのヘッドを実行中プロセスが把握するヘッドと比較します。イベントには device.authorize、grant.issue、grant.revoke、member.add|member.set|member.remove、session.lock|session.unlock、および request.create|request.approve|request.claim|request.reject|request.cancel が含まれます。取得イベントはリクエスト者をアクター、発行された権限付与 ID をオブジェクトとして記録し、トークンは決して記録しません。監査の追記、またはリクエストやメンバーの永続化に失敗すると、ホスト型サービスをロックし、restart_required を設定して、オペレーターが修復して再起動するまでリモートのロック解除をブロックします。restart_required が設定されている間は、認可の変更と権限の決定も停止します。オペレーターによる読み取り専用の検査は引き続き利用できます。 これらの鍵なしチェーンは、オペレーターによるログ全体の書き換えや全ファイルのロールバックに対する証明ではありません。より強い保証には外部のヘッドアンカーが必要です。

脅威モデルと動作の変更

• ローカルの OS 認証済み呼び出し元は、ロック解除されたデバイスのメンバーとして動作します。同じユーザーの悪意あるプロセスは、引き続き既存のエンドポイントの信頼境界内にあります。
• ケイパビリティ Bearer は秘密情報です。所持者は誰でも、失効、ロック、または期限切れまで、その限定された権限を使用できます。Bearer は自分自身のスコープを拡大したり、Vault の外へ出たり、有効期限を延長したり、対象の委任ロールを迂回したりすることはできません。
• 失効は以前にコピーされた平文やキーを消去せず、オフラインのピアへ即座に到達することもできません。ポリシーと権限付与の無効化は、更新済みポリシーをコミットしたデーモンで有効になります。
• ハッシュチェーンは既知の状態に対する改変を検出しますが、データベース全体のロールバックや、侵害されたデバイスによるイベントの省略は検出しません。より強い保証には、引き続き外部アンカーと独立したセキュリティ監査が必要です。
• 破壊的変更：スコープ未指定の発行は読み取り専用です。Editor/Reader は権限付与や招待を発行できません。監査へのアクセスには権限昇格の代わりに Admin/Owner が必要です。メンバー変更は委任された権限付与を無効にします。新しい Admin/Owner による権限付与の発行と、発行者/Admin による失効では、権限昇格が不要になりました。Vault を持たない場合の招待作成は、呼び出し元を黙って管理者として扱うのではなく拒否されます。
• 破壊的変更：承認では Bearer の発行や配布を行わず、リクエスト一覧も承認済み Bearer を配布しなくなりました。リクエスト者は明示的に一度だけ取得する必要があります。遅延承認の境界が記録されていない以前の承認済みリクエストは取得できません。新しいリクエストを作成してください。既存の別途発行された権限付与は、引き続き通常の有効期限と失効の規則に従います。

制約については セキュリティ境界、チケット専用 Center とオペレーターのキーを使用するホスト型 Center のそれぞれの信頼境界については Center ガイド を参照してください。

権限リクエストの上限、有効期限、保持期間

デーモン（暗号化された Store 内のリクエスト）と Center（requests.json）の両方に適用されます。

• MAX_PENDING_PER_REQUESTER_PER_VAULT = 20 と MAX_PENDING_PER_VAULT = 200 は、保留中のリクエストのみを数えます。決定済み、キャンセル済み、期限切れ、および承認済みで未取得のリクエストは、これらの上限に数えられません。（これは、これまで作成されたすべてのリクエストを数えていた従来の全体上限 1000 件に置き換わるものです。）上限を超えると、デーモンは制限エラーを返し、Center は HTTP 429 を返します。
• PENDING_REQUEST_TTL = 7 days：これより古い保留中リクエストは expired 状態へ移行します。アクター system の request.expire として監査され、以後は承認できません。承認後 7 日以内に取得されていない承認済みスコープリクエストも同じように期限切れとなり、その後は取得できません。
• REQUEST_RETENTION = 30 days：拒否済み、キャンセル済み、期限切れ、または取得済みのリクエストは、最後の遷移（decided タイムスタンプ、またはそれがない古いレコードでは created）からこの期間が経過すると削除されます。
• 期限切れ処理と削除は遅延実行されます。デーモンはすべての認可リクエストの開始時に実行し、Center はリクエストの作成、一覧取得、決定、取得時に実行します。起動時には実行されません。
• Center の起動時照合は、削除済みリクエストの監査エントリを無視し、request.expire エントリを受け入れます。expired リクエストには、監査された期限切れが必要です。リクエスト ID は再使用されないランダムな 128 ビット値なので、削除されたリクエスト（取得済みのものも含む）は存在せず、取得できません。そのため、Center は個別の削除済み記録セットを保持しません。