代理金鑰需要風險預算
Shuriken 的 shuriken-skills 儲存庫將 Claude Code、Codex CLI、GitHub Copilot CLI、Gemini CLI、Cursor、OpenCode,以及相容 AGENTS.md 的代理所需指令打包在一起。1該儲存庫也會把這些代理導向一個平台;只要使用者授權,代理金鑰就能讀取市場資料、檢查錢包、請求報價,並執行交易。2
重點不在交易。重點在於這個模式:代理現在需要工具憑證,而這些工具能對外部世界造成真實影響。代理金鑰不應該像一般 API 金鑰那樣運作,而應該像一份風險預算。
代理金鑰是一個受限的權限物件。它應該明確說明代理能做什麼、不能做什麼、最多能造成多少風險、操作人員如何檢視其行動,以及有人能多快暫停、輪替或撤銷它。提示詞指令有幫助,但真正劃定邊界的是伺服器端限制。
TL;DR
MCP 和可攜式技能讓代理更容易連接外部系統。34這種可攜性也提高了憑證的風險。Shuriken 文件描述了危險工具應有的控制形態:建立代理金鑰,只授予必要權限,在伺服器端強制限制,記錄活動,並在整合不再需要時撤銷金鑰。256近期關於最小權限的研究也指向同一方向:技能可能執行超出特定任務最小範圍的動作,因此權限必須能感知任務,而不是只以套件為單位授權。9
這個教訓不只適用於金融領域。任何會匯款、發布內容、變更基礎架構、傳訊給客戶,或接觸私人資料的代理工具,都需要帶有風險預算的範圍化金鑰。這份預算應該位於模型之下,也位於技能檔案之下。即使代理自信滿滿地提出請求,伺服器仍應拒絕未授權的動作。
主要重點
- 給代理工具建置者:請將憑證設計成能力預算,而不是萬用的持有人權杖。
- 給安全團隊:將讀取範圍與寫入或執行範圍分開,並在執行端加上花費、頻率與物件限制。
- 給產品團隊:把活動紀錄與撤銷控制放在主要 UI,而不是藏在設定頁深處。
- 給 MCP 建置者:將工具散布與憑證權限視為不同層面。技能可以教學,金鑰必須約束。
- 給操作人員:從唯讀開始,先證明整合路徑可行,再在具備回應計畫後加入寫入權限。
技能散布指令。金鑰散布權限。
shuriken-skills 儲存庫展示了新的散布模式。單一原始碼樹包含技能 Markdown、Claude 與 Codex 的外掛清單檔、Cursor 外掛清單檔、Gemini 擴充功能檔案、OpenCode 外掛、Rust crate,以及 AGENTS.md 備援路徑。17
這種打包方式很重要,因為代理指令現在會跨用戶端流動。供應商可以教 Codex、Claude Code、Cursor、Gemini 與其他工具如何和同一個 API 整合。MCP 文件將代理技能描述為可攜式指令集,可為程式碼助理提供領域知識,包含部署模型、驗證流程與工具模式的設計決策。4我在代理技能需要套件管理器談過散布面;安全面則從這些套件要求真實權限時開始。
可攜式指令解決了一個問題,也創造了另一個問題。它能幫助代理學會正確的整合路徑,卻不能保證後續行動安全。技能可以告訴模型使用最小權限。提示詞可以說「小心」。README 可以說明建議範圍。但模型決定送出已驗證的請求後,這些控制都無法攔下它。
這種拉扯也呼應了MCP 伺服器是新的攻擊面一文中更大的 MCP 問題:工具存取擴張行動面,其速度遠快於舊式批准習慣能跟上的速度。代理技能讓指令路徑可攜。金鑰系統則必須讓權限路徑保持狹窄。
這就是為什麼憑證需要自己的設計。技能檔案位於指令層。代理金鑰位於權限層。混在一起會形成脆弱的系統:同一段文字既要教代理做什麼,又試圖阻止代理做太多。
邊界應該放在伺服器上。
Shuriken 模式是一份風險預算
Shuriken 的 Agent Kit 文件將代理金鑰描述為控制 AI 工具能做什麼的物件,範圍從讀取 token 價格到執行交易;在代理開始行動前,限制會由伺服器端強制執行。5權限頁面列出 6 類權限,並說明超出授權範圍的呼叫會因授權錯誤而失敗。6
這種框架也避開了公開代理展示常見的錯誤:把開放原始碼、可見指令,或可讀的外掛清單檔當成邊界。開放有助於審查,但開放原始碼不是安全邊界。真正的邊界存在於未授權動作會失敗的地方。
這個模式有 5 個部分:
| 控制 | 為什麼重要 |
|---|---|
| 範圍化權限 | 唯讀金鑰可以檢查。交易金鑰可以行動。這個差異會改變影響範圍。 |
| 物件限制 | 錢包存取可以維持狹窄,不必涵蓋所有連接資產。 |
| 花費限制 | 買進、賣出、每日、每小時、滑價、gas 與並行交易上限,能把權限轉為可衡量的預算。 |
| 活動紀錄 | 操作人員能檢視工具呼叫、報價、時間戳與狀態,而不是只相信最後答案。 |
| 撤銷 | 金鑰可以失效,而不會結束使用者的主要會話或其他所有整合。 |
這才是高風險代理工具應有的形態。設計不仰賴模型變得明智,而是假設模型可能錯誤、過度自信、遭輸入攻擊,或只是收到不良指令。伺服器仍會強制執行金鑰限制。
我會複製這個控制模式,而不是複製其領域。部署金鑰、發布金鑰、客戶訊息金鑰、Stripe 退款金鑰與交易金鑰,都需要回答同一個問題:在人類注意到以前,這把金鑰最多能造成多大傷害?
伺服器端限制勝過提示詞承諾
OpenAI Agents SDK 文件將防護規則描述為可在代理周圍執行的檢查,包含帶有觸發條件的輸入與輸出防護。8防護規則有幫助,因為它們能在模型執行前後捕捉風險。但它們仍和憑證權限位於不同層。
輸出防護可以標記不良的擬議動作。伺服器端金鑰限制則能在防護漏掉時仍拒絕動作。當動作不再只是文字時,這個差異至關重要。
想像一個工具可以發布文章、寄送電子郵件、變更 DNS 紀錄、合併 pull request,或執行交易。提示詞規則可以說「先詢問」。防護規則可以尋找高風險文字。伺服器端金鑰則能強制執行真正的限制:
| 高風險動作 | 提示詞層級規則 | 金鑰層級邊界 |
|---|---|---|
| 寄送電子郵件 | 「未獲批准不得寄送」 | 金鑰只能草擬,不能寄送 |
| 發布內容 | 「先檢查引用」 | 金鑰只能寫入預備環境,不能寫入正式環境 |
| 變更基礎架構 | 「避免破壞性動作」 | 金鑰可以讀取設定,不能變更資源 |
| 執行交易 | 「保持保守」 | 金鑰限制花費、頻率、滑價與錢包存取 |
| 傳訊給客戶 | 「使用核准文案」 | 金鑰在升級前只能觸及測試受眾 |
提示詞規則可能無聲失效。金鑰層級邊界會產生可觀察的拒絕。這個拒絕就是證據。代理嘗試超出範圍,伺服器拒絕。操作人員可以檢查失敗請求,並判斷整合是否需要新金鑰、更狹窄的工作流程,或人工批准步驟。
這也是證據關口背後的同一套邏輯:信任應來自可觀察的證明,而不是信心。最後答案說「我待在限制內」的價值,低於伺服器紀錄顯示是哪一項限制被觸發。
它也讓最後答案更接近審查封包。審查封包是新的最後答案主張,嚴肅的代理工作需要證據產物。憑證拒絕、活動紀錄與範圍化金鑰變更,就是這類產物在安全面上的版本。
代理憑證的最低形態
任何會影響外部世界的代理憑證,都應具備 6 項屬性。
| 屬性 | 最低要求 |
|---|---|
| 目的 | 每個整合或工作一把金鑰,不要一把金鑰到處重複使用 |
| 範圍 | 明確授予讀取、寫入、執行、通知與管理權限 |
| 預算 | 在領域允許時設定花費、頻率、數量、物件、受眾與時間限制 |
| 可見性 | 活動紀錄包含請求類型、目標物件、時間戳、狀態與失敗原因 |
| 生命週期 | 可輪替、暫停與撤銷,不會破壞無關整合 |
| 升級路徑 | 從唯讀開始,經過本機測試、預備環境證明與操作人員審查後才擴大 |
Shuriken 技能也用整合語言表達同一件核心事:每個整合建立一把金鑰、授予最小範圍、保密金鑰、疑似外洩後輪替,並撤銷退役整合。7它的範圍界定技能也把讀取範圍與交易範圍分開,並警告不要為了「以防萬一」而建立過寬的金鑰。7
研究語彙正在追上產品模式。SkillScope 論文把過度授權描述為受任務條件影響:同一個技能動作,對某個使用者請求可能有效,對另一個請求卻可能過度。9作者回報了 7,039 個具驗證過度授權行為的技能,並在其評估中透過框架約束權限,使觸發的過度授權動作實例減少 88.56%。9您不必照搬那套機制,也能接受其中的產品教訓:代理憑證應反映當前工作,而不是工具能想像的最大工作。
這項指引應成為一般代理產品設計的常態。當後端服務掌握的是狹窄程式碼路徑時,寬泛的 API 金鑰說得通。代理不像單一狹窄程式碼路徑。它們會規劃、重試、組合工具、摘要失敗、呼叫輔助指令碼,並回應外部輸入。憑證應假設其行為變異比一般服務權杖更大。
這種變異也是為什麼代理程式碼搜尋有 token 預算問題即使在憑證文章中也重要。代理常在部分脈絡下做決定。狹窄金鑰能在脈絡視窗漏掉危險細節時,讓系統多一次補救機會。
不該複製什麼
不要複製行銷式樂觀。
Shuriken 公開文件使用了強烈語氣,描述代理在使用者離開時行動並捕捉機會。2這種說法也許適合它們的產品,但不該成為會對外產生影響的代理工具的預設安全姿態。
對高風險動作而言,「在您離開時」需要更狹窄的操作定義:
- 代理可以在使用者離開時蒐集資訊;
- 代理可以在使用者離開時準備草擬動作;
- 代理只能在小型、明確、伺服器強制執行的預算內執行;
- 操作人員事後可以檢查每個動作;
- 操作人員能立即暫停或撤銷金鑰。
這就是自主與卸責的差別。使用者可以委派行動。系統不能委派責任。
同樣的謹慎也適用於技能與外掛清單檔。儲存庫可以支援每個代理用戶端,同時仍然值得採用保守預設。我檢查的 .codex-plugin/plugin.json 在介面中繼資料中列出讀取能力,而文件則說明交易需要明確啟用權限與限制。7這是正確方向:散布可以很廣,權限必須從狹窄開始。
決策規則
當新的代理整合要求憑證時,先分類金鑰,再發出。
| 整合類型 | 起始金鑰 | 升級要求 |
|---|---|---|
| 搜尋、讀取、摘要 | 唯讀 | 除非私人資料範圍擴大,否則不需要 |
| 草擬內容或程式碼 | 僅寫入預備環境 | 人工審查與發布關口 |
| 通知或傳訊 | 僅測試受眾 | 投遞紀錄與退出路徑 |
| 變更正式環境設定 | 先唯讀 | 變更計畫、批准、復原與稽核紀錄 |
| 移動金錢或資產 | 一開始不給執行存取 | 小型伺服器強制預算、活動審查與撤銷演練 |
| 管理其他金鑰 | 預設避免 | 具人工批准的獨立管理流程 |
這張表給代理一條可用路徑,卻不假裝模型本身掌握邊界。工作流程仍然可以改善。金鑰防止改善變成無界權限。代理執行追蹤是執行環境契約從稽核面提出同樣觀點:如果系統無法顯示發生了什麼,就無法證明代理是在預期契約內行動。
我在代理沙箱安全只是一項建議也談過同樣的分野:模型可以完全在已授予權限內運作,仍然造成不安全結果。代理金鑰需要風險預算,因為權限不等於安全。
FAQ
代理金鑰只是換了名字的 API 金鑰嗎?
不是。一般 API 金鑰通常授予某項服務的廣泛存取。代理金鑰應該為單一整合授予受限的能力集合,具備伺服器端限制、活動紀錄,以及不影響使用者主要會話的撤銷機制。
為什麼伺服器端強制執行很重要?
伺服器看得到最終請求。模型指令、技能檔案或防護規則可能漏掉不良動作。當金鑰缺少必要範圍或超出設定限制時,伺服器端權限檢查可以拒絕請求。6
每個代理都應該從唯讀開始嗎?
是的,前提是工具有實質外部影響。先從唯讀存取開始,驗證整合路徑,再在團隊知道有哪些紀錄、限制、批准與復原步驟後,才加入寫入或執行權限。
MCP 會讓代理憑證風險更高嗎?
MCP 讓外部工具更容易跨用戶端連接。3這種便利性提高了憑證設計的重要性。可攜式工具存取應搭配狹窄金鑰,而不是更寬泛的信任。
團隊應該從 Shuriken 複製什麼?
複製指令散布與伺服器端權限的分離:可攜式技能可以教整合方式,而範圍化金鑰、限制、紀錄與撤銷會約束行動。除非產品、法律與營運控制足以支撐,否則不要複製特定領域的交易行為。
參考資料
-
ShurikenTrade,
shuriken-skillsGitHub 儲存庫,以及 2026年5月18日本次會話中的複製檢查。該儲存庫包含.claude-plugin/plugin.json、.codex-plugin/plugin.json、.cursor-plugin/plugin.json、gemini-extension.json、.opencode/plugins/shuriken-skills.js、skills/*/SKILL.md、GEMINI.md,以及版本0.2.0的套件中繼資料。 ↩↩ -
Shuriken,“AI Agent Kit,” Shuriken 文件。本次會話驗證發現狀態碼 200,以及 Agent Kit、MCP、伺服器端強制執行、private-key claims 與執行限制等標記。 ↩↩↩
-
Model Context Protocol,“What is the Model Context Protocol?” MCP 文件。來源說明 MCP 是開放標準,可將 AI 應用程式連接至資料來源、工具與工作流程,包含能代表使用者採取行動的系統。 ↩↩
-
Model Context Protocol,“Build with Agent Skills,” MCP 文件。來源說明代理技能是可攜式指令集,能編碼設計決策、驗證流程、工具設計模式與行動面探索。 ↩↩
-
Shuriken,“Create an Agent Key,” Shuriken 文件。代理金鑰、唯讀與交易範本、伺服器端限制、一次性金鑰複製、活動紀錄、暫停/撤銷控制與交易限制設定的來源。 ↩↩
-
Shuriken,“Permissions & Safety,” Shuriken 文件。6 類權限、伺服器端強制執行、交易限制、建議設定與安全最佳實務的來源。 ↩↩↩
-
2026年5月18日,本次會話從
https://github.com/ShurikenTrade/shuriken-skills.git進行 shallow clone 後,檢查skills/agent-keys/SKILL.md、skills/scoping/SKILL.md、.codex-plugin/plugin.json、.claude-plugin/plugin.json與package.json。每個整合一把金鑰、最小範圍、輪替/撤銷順序、讀取與交易範圍分類,以及 Codex 外掛中繼資料的來源。 ↩↩↩↩ -
OpenAI Agents SDK,“Guardrails,” OpenAI 文件。輸入/輸出防護框架、觸發條件,以及防護規則圍繞代理執行運作的來源。 ↩
-
Jiangrong Wu, Yuhong Nan, Yixi Lin, Huaijin Wang, Yuming Xiao, Shuai Wang, and Zibin Zheng,“SkillScope: Toward Fine-Grained Least-Privilege Enforcement for Agent Skills,” arXiv,2026年5月7日提交。代理技能中受任務條件影響的過度授權、7,039 個經驗證的過度授權技能,以及其評估中觸發的過度授權動作實例減少 88.56% 的來源。 ↩↩↩