Capability Lease ケイパビリティ・リース

解決する課題 #

RBAC や ACL が前提にするのは、広い権限を長く持つ、安定したユーザーです。エージェントに必要なのは、タスクに合わせて切り出され、タスクが終われば止まる権限です。さらに悪いことに、長期の認証情報は、エージェントの手が届く場所にあることがよくあります。2026 年 4 月の事故でも、トークンは無関係なファイルの中にあり、ドメイン管理のために作られたのに、何でもできました。

仕組み #

• 鍵は誰が持つか。 長期の認証情報はオーケストレーターか所有者の手元にとどまり、実行が受け取るのは鍵ではなくリースです。モデルが長期の認証情報を目にすることはありません。
• リースはアクセストークンです。 その authorization_details（RFC 9396）が、パス、操作、ブランチを記述します。所有者かオーケストレーターが トークン交換（RFC 8693） で要求し、act クレームが委任の連鎖を記録します。NAS は、失効と予算の計上のために状態を保持します。
• 狭める方向だけ。 子リースは親の部分集合でなければならず、NAS が発行時に検査します。
• 予算。 読み書きのバイト数、リクエスト数、必要に応じて外向きのバイト数と支出の上限を、ゲートウェイで数えます。正確な課金ではなく、ブレーカー です。
• ポリシーの範囲。 所有者があらかじめ範囲を定め、その中のリースは自動で発行され、外側は Human Gate に回ります。長期のアクセスは、長期のリースではなく、この範囲で表します。
• B と C は明示的に宣言します。 リースは、読んでよい最も高い機微度と、保護ツリーへの書き込みやデータの送出を許すかどうかを明記します。これらは Trust Labels への入力になります。
• 失効。 短い TTL（既定 4 時間、最大 24 時間）に加えて即時の失効があり、子リースにも連鎖します。
• **purpose は記録するだけで、強制はしません。** 自由記述のテキストは、機械が検査できないためです。

小さく始める #

• nas lease create コマンドを作ります。ロールごとに、パスのプレフィックス、操作、TTL を持つトークンを発行して、環境変数でサンドボックスに渡し、プレフィックスと操作を NAS に強制させます。
• これだけで、この種の事故の前半は防げます。トークンは、リースの外では何もできません。
• 予算、委任の連鎖、ポリシーの範囲は、あとから足せます。

インターフェースのスケッチ #

説明用の例です。フィールド名は仕様 v0.3 までに変わる可能性があります。

{
  "lease_id": "lse_7Qk3",
  "run": "run_91ab",
  "principal": "agt_cleo",
  "on_behalf_of": "usr_wei",
  "parent": null,
  "purpose": "Draft the Q4 release notes",
  "paths": ["/shared/launch/**", "/agents/cleo/workspace/**"],
  "actions": ["read", "write", "propose"],
  "branch": "cleo/run_91ab",
  "sensitivity_max": "private",
  "egress": false,
  "requires_gate": ["merge", "delete", "share"],
  "budgets": { "bytes_read": 200000000, "bytes_written": 5000000, "requests": 5000 },
  "expires_at": "2026-11-12T16:00:00Z"
}

仕様が求めること #

• リースには期限がなければならず、最大 TTL を超えて更新してはならない。更新には、新しい発行が必要である。
• 子リースは親の部分集合でなければならず、NAS は発行時にそれを検証しなければならない。
• リースの失効は、そのすべての子リースに連鎖しなければならない。
• 長期のアクセスは、ポリシーの範囲として表さなければならず、長期のリースにしてはならない。
• リースは、機微度の上限と、外向きの送出および保護された書き込みを許すかどうかを宣言しなければならない。
• 長期の認証情報を、モデルや実行に見せてはならない。

借りたものと、新しいもの #

以下はすべて確立された部品です。新しいのは、 実行とタスクの かたち を単位にして、ブランチ、予算、Rule of Two の性質を 1 つのリースにまとめることです。トークンやケイパビリティモデルそのものは新しくありません。

• OAuth Token Exchange (RFC 8693)
• OAuth Rich Authorization Requests (RFC 9396)
• Biscuit
• UCAN
• IETF attenuating agent tokens draft

正直な限界 #

• 対象は NAS の内側の操作だけで、エージェントがほかの場所で何をするかは統制できません。
• purpose は強制できず、予算も概算です。
• リースは、正当な権限の範囲内での 誤用は防げません。それはブランチとゲートの役割です。

未解決の問い #

• purpose を、自由記述から、機械が検査できる構造化された意図へ、どう進めるか。
• フェデレーションの下で、予算をどう計上するか。

よくある質問 #

関連するコンセプト #

• Human Gate (ヒューマン・ゲート) 元に戻せない、外へ出る、権限を広げる操作の前にだけ現れ、実際の差分を見せます。
• Trust Labels (トラスト・ラベル) 2 つの小さなラベルとセッション汚染で、Rule of Two を実現します。
• Flight Recorder (フライトレコーダー) 実行ごとに、ハッシュでつながれた記録を残します。実行が何を読んだかも含みます。