Permission

API key に与えられるもの、そしてメンバーにしかできないこと。

API key の権限は、それが発行されたときの permission の集合とちょうど一致します。subako api-key permissions はサーバーから現在の集合を読み取ります。下の表は、それが今日持っている内容です。

Key に与えられるもの

Permission	できること
`workspace.read`	Workspace を読む。
`agent.read`	Agent とその version を読む。
`agent.publish`	新しい agent version を公開する。
`agent.delete`	Agent と、その version、その session を削除する。
`session.create`	Session を作成する。
`session.read`	Session とその event ログを読む。
`session.manage`	入力を追記し、run をキャンセルし、client を管理する。
`vault.read`	Vault を読む。
`vault.manage`	Vault を作成・更新・削除する。
`credential.read`	Credential を一覧する — ペイロードは決して見られません。
`credential.manage`	Credential を追加・削除する。
`skill.read`	Skill とその version を読む。
`skill.manage`	Skill を作成・push・rename・削除する。
`model_provider.read`	Model provider を読む。
`model_provider.manage`	Model provider を作成・更新・削除する。

Key には決して与えられないもの

これらは機械ではなく人が持つものです。key をこれらとともに発行することはできません。

Permission	なぜ
`workspace.members.read`	メンバーシップは人の問題だから。
`workspace.members.manage`	メンバーを追加できる key は、自分にチームを与えられてしまうから。
`api_key.read`	Key を列挙できる key は、全体像を把握できてしまうから。
`api_key.manage`	Key を発行できる key は、自分の権限を超えて昇格できてしまうから。
`usage.read`	請求の可視性はメンバーのものだから。

典型的なバックエンド用の key

多くのプロダクトに必要なのは 3 つです。

subako api-key mint \
  --label "support-triage backend" \
  --permission session.create \
  --permission session.read \
  --permission session.manage

これでは agent version を公開することも、vault を読むことも、skill に触れることもできません。Version を公開するデプロイパイプラインは agent.publish を持つ別の key であり、どちらももう一方を発行できません。

Organization の permission

Organization レベルの権限 — メンバー、招待、クレジット、使用量、workspace の作成 — は key ではなくメンバーシップの role が持ちます。admin が持ち、member は持ちません。

org.read              org.manage
org.members.read      org.members.manage
invitation.read       invitation.manage
org.credits.read      org.usage.read
workspace.create