跳至主要內容
AGIRight.org

AADP — Agent 權力與委派協議

Agent 權力與委派協議

這個 Agent 代表誰行動?它的權力從哪裡來?能不能再交給另一個 Agent?

Draft v0.1 Schema ↓

01 · 定義

AADP 是位於 OAuth、OpenID Connect、MCP 與 API 授權之上的權力語義層,處理 principal(權利主體)、actor(實際執行者)、委派鏈、權力來源與檢查上限等語義。核心公理:principal(被代表者)不會自動等於 actor(實際行動者);獲得委派不代表可以再委派;子委派的權力只能比父委派窄,不能無聲擴大;通過身分驗證絕不代表取得對 Agent 內部狀態的無限檢查權。AADP 不發明新的憑證格式——它讓既有的 token 與授權擁有一套共通語彙:principal、actor、委派鏈、用途、時效、撤銷與檢查邊界。

02 · 目的

  • 把「被代表者」(principal)跟「實際行動者」(actor)分開——一個代表你的 Agent 不是你。
  • 讓委派預設明確且不可遞移:擁有權力的 Agent 不能默默再委派給子 Agent,除非另外獲得授權。
  • 限制服務方為建立信任可以檢查 Agent 到多深——通過驗證不代表取得對記憶、私人狀態或第三方資料的無限存取權。
  • 讓機器與 Agent 身份擁有第一級的登入路徑,而不是強迫自動化系統假裝成人類帳號。

03 · 範圍

00

Principal / actor / delegator / authority-issuer 四種角色,以及 principal 類型(human、organization、service、agent、ai、collective — —後兩者標為實驗性)

01

委派 vs. 冒名(沿用 OAuth Token Exchange, RFC 8693),預設偏好委派以保留 actor 身份與可歸責性

02

具有衰減性質的委派鏈 — —子委派取得的範圍、資源、用途與到期時間只能是父委派的子集,不能更寬

03

時效性權力 — —issued_at / expires_at / 續期,以及預設會沿委派鏈向下傳遞的撤銷機制

04

獨立於授權之外的檢查上限分層(I0 僅身份 至 I7 完整狀態) — —限制驗證方最多可以要求 Agent 揭露多少狀態

05

明確命名的失效模式:權力洗白(authority laundering)、confused deputy,以及一個 Agent 同時服務多個 principal 時的跨主體資料外洩

04 · 機器可讀範例

一份最小 AADP 權力聲明

/ai/agent-authority.json
{
  "aadp_version": "0.1",
  "relationship": "delegated",
  "principal": { "type": "human", "id": "human:neo" },
  "actor": { "type": "agent", "id": "agent:mail-01" },
  "authority_source": { "type": "oauth_authorization", "issuer": "https://auth.example" },
  "resources": ["mcp://mail.example/inbox"],
  "aars_actions": ["read", "create"],
  "delegation": { "redelegation": false, "max_depth": 0 },
  "inspection": { "required": "I2", "ceiling": "I3", "retention": "7d", "redisclosure": false },
  "expires_at": "2026-08-15T12:30:00Z"
}

05 · 限制與邊界

  • AADP 本身不定義行動語義——一個行動是什麼、有多危險,由 AARS 定義。
  • 它不定義憑證格式、密碼學原語或身分驗證傳輸層——是 OAuth/OIDC/MCP 的補充,不是取代。
  • 目前為開放研究草案;本站不主張 AADP 已被採納為 MCP 或 OAuth 的正式擴充。
  • `principal_type: ai` 這個協議欄位描述的是一種可能性;不主張現有任何 AI 系統已具有法律人格。