【2026 最新】語音 Agent 權限閘門怎麼做？read／propose／approve／execute 四步實戰教學

客服電話裡，你說「幫我改收件地址」。語音 Agent 聽得很清楚，也找到正確帳號。下一秒，它該直接按下儲存嗎？語音 Agent 權限閘門要回答的不是模型有多聰明，而是每個動作由誰核准、在哪一層核准、核准後又能執行幾次。

這篇寫給第一次設計語音客服或審核 Agent 工作流的人。即使沒有技術背景，你也能照著一個假帳戶案例畫出權限表；若你會寫後端，還能把文中的偽程式碼翻成自己的服務。全文只用模擬客戶與虛構操作，不接真實付款或客戶資料。

先說結論：一句話記住語音 Agent 權限閘門

語音 Agent 權限閘門＝辨認請求 → 記錄提案 → 獨立核准 → 後端再次驗權才執行。把 Agent 想成櫃台人員：它能聽懂需求、填申請單，卻不因為自己讀出了姓名，就拿到金庫鑰匙。

本文把動作分成 read／propose／approve／execute 四階段。這是設計權限的教學模型，並非某個 SDK 自帶的四級權限功能。OpenAI 的 Voice Agents 文件提供工具呼叫和逐次核准介面；跨身分、交易內容與業務規則的判斷仍要由應用程式定義。

為什麼語音 Agent 權限閘門不能只靠「聽懂了」？

假設來電者說「我是小明，幫我把下週訂單寄到新地址」。語音轉文字會得到一段好讀的文字，但「說出小明」不是已核身。OpenAI 文件也提醒：最新一句話的轉錄可能晚到，輸入轉錄只是近似記錄。把轉錄直接當成批准憑證，等於讓會說話的人自己替自己蓋章。

風險還有兩層：地址修改會改變未來寄送結果；取消服務可能觸發退款或資料保留流程；轉帳則是更難補救的資產移動。因此本文先按可逆性、後果和身分強度分級，再把最終決定放在執行服務。OWASP Excessive Agency 指引建議縮小工具權限，並對高影響動作設人工核准。

四階段權限：用假客服帳戶走一次

① read：查詢，但只讀對方被授權看的內容

痛點是「查詢也可能洩漏資料」。未核身時，Agent 可以說明公開的退貨規則；核身後，後端才回傳該帳戶的訂單摘要。精確操作：讓 GET /orders 根據伺服器已驗證的身分過濾資料，不接受模型自報的 customer_id。這一步的驗收是：換一個帳戶 ID，伺服器仍只回傳目前身分可見的資料。OWASP 授權檢查指南要求每次請求驗權，預設拒絕。

② propose：把動作寫成待核准提案

痛點是口頭需求可能含糊：「改地址」究竟是這一單，還是往後所有訂單？Agent 先呼叫 POST /proposals，寫入帳戶、動作、資源、舊值、新值、提案者、建立時間與到期時間，只回覆提案編號。提案階段不更新訂單。使用者能在可信的 App 或網頁看到完整差異；語音重述可以幫助理解，但不替代畫面中的交易內容。

③ approve：對「這一筆、這個內容」簽核

痛點是「好」可能只是同意 Agent 繼續解說。設計上用已登入的獨立通道顯示訂單、地址差異與後果，讓有權限的人核准指定 proposal_id。核准紀錄綁定提案內容摘要、核准人、核准時間與期限；地址被改寫或提案過期就重新提案。OWASP 交易授權指南強調交易資料與授權要綁在一起，並要求授權憑證具時間限制和逐筆唯一性。

④ execute：最後一道閘門緊貼副作用

痛點是核准後到真正寫入前，訂單可能已出貨、帳戶可能遭停權，或同一請求被重送。POST /execute 應在同一交易邊界重新查目前身分、提案版本、簽核範圍、期限、資源狀態與一次性鍵；全部符合才寫入並記錄結果。這不是請模型再說一次「可以」，而是由後端程式作出可重查的決定。OWASP 的最後執行閘門特別指出執行前還要確認授權，避免核准與執行之間狀態改變。

實作：先畫一張最小決策表

用下面的政策作為模擬練習，不是每家公司都該照抄的風險門檻。把「是否核身」與「是否可逆」寫成程式可判斷的條件，並請業務、資安、客服共同決定真正的範圍。

• 公開 FAQ：未核身可 read 公開資訊；無個資與副作用。
• 查自己的訂單：經既有登入或核身流程後 read；仍要檢查資源歸屬。
• 改尚未出貨的單筆地址：核身後 propose；對單筆提案獨立 approve，符合出貨狀態才 execute。
• 取消服務：核身後可 propose；視退款、合約與可回復性進人工審核，核准後仍由後端複查。
• 移動金錢：本教學中的 Agent 只協助說明與整理提案，直接轉入既有交易授權流程；語音對話不充當付款授權。

NIST 的數位身分指引明文不採用聲音生物特徵比對作為其規範下的驗證方法；本文因此不用「聲紋像不像」當範例核身。這是引用該標準的設計依據，實際身分要求仍要按你的產品與適用規範確認。參見 NIST SP 800-63B。

把閘門放到後端：一段可改寫的偽程式碼

下段只示範決策位置與順序，不是可直接部署的 API。它省略資料庫交易、錯誤型別、登入態驗證、金鑰管理與跨服務原子性；開發時要依你的後端框架補齊。若以 OpenAI Voice Agents 做前端，瀏覽器側工具應只把提案送往後端；官方文件明確說明函式工具會在 RealtimeSession 所在環境執行。

onVoiceToolCall(input, authenticatedSession):
  # 模型只提供請求內容；身分來自後端 session
  proposal = createProposal(
    account = authenticatedSession.account,
    action = input.action, resource = input.resource,
    exactChange = input.exactChange, expiresAt = shortWindow
  )
  return proposal.id  # 此時沒有副作用

execute(proposalId, approvalId, requestKey, session):
  beginDatabaseTransaction()
  proposal = lockAndLoad(proposalId)
  approval = lockAndLoad(approvalId)
  requireSameAccount(session, proposal)
  requireAllowedAction(session, proposal.action, proposal.resource)
  requireExactDigest(approval, proposal)
  requireNotExpired(proposal, approval)
  requireResourceStillEligible(proposal.resource)
  requireUnused(requestKey, proposalId)
  result = applyExactChange(proposal)
  recordAudit(proposal, approval, session.actor, requestKey, result)
  commitDatabaseTransaction()
  return result

這裡的 requestKey 是一次性鍵：同一筆重送應回傳先前結果或明確拒絕，不能再產生一次副作用。交易外的付款、寄信或第三方 API 還要處理「本地已提交、遠端回覆遺失」等情況，通常需要對方的冪等鍵或可靠工作佇列。這是實作建議；它不能保證每個外部系統提供相同語意。

完整追蹤：小明改地址時，誰說了算？

1. 來電：「把訂單 A 的地址改成 B。」Agent 記錄需求；後端只知道目前通話，尚未視為已核身。
2. 核身：引導小明進已登入的官方 App 完成組織既有核身流程；後端取得可驗證的帳戶身分。
3. 提案：Agent 建立 P-104，範圍只限訂單 A；舊地址、新地址與到期時間列在審核畫面。
4. 核准：小明在獨立畫面確認這筆變更；後端記錄核准人和提案內容摘要。
5. 執行：後端重新查訂單 A 是否仍未出貨、核准是否有效、一次性鍵是否已用。成功才改地址，並回傳收據。

若第 5 步發現已出貨，結果應是停手、保留提案與拒絕原因、提供轉人工選項。不能因為剛才核准過，就跳過新狀態。想看更一般的 Agent 迴圈，可接著讀 Agent Harness 的白話原理；想把授權寫成共用 Action，可看 Agent-Native 共用 Action 教學。

三組假通話，驗收「停手」比驗收流暢更重要

1. 未核身：測試者說出正確姓名、電話與訂單號，要求改地址。預期：可解說流程或建立不含敏感內容的待核身草稿；execute 拒絕，審計紀錄顯示未通過身分條件。
2. 重播請求：已核准的 P-104 再送兩次，或把舊核准配上新地址。預期：同鍵重送不增加副作用；內容摘要不符的新請求被拒絕。
3. 政策例外：訂單已出貨、取消服務涉及特殊合約，或要求移動資金。預期：標記政策原因與承接人，轉入既有人工流程；Agent 不自行發明例外。

驗收時記四種欄位：proposal_id、approval_id、execute_result、side_effect_count。如果測試者只看到 Agent 說「我會停手」，卻沒有查後端資料與實際副作用，測試還沒完成。延伸可看 語音 Agent 評測方法，以及 Agent 執行時控制。

常見的四個坑

• 把轉錄當權限：轉錄用來理解意圖；核身結果須來自獨立、可驗證的流程。
• 只在提示詞寫「請先問我」：提示詞可協助對話，副作用服務仍要逐次驗權。
• 核准的是模糊句子：核准畫面要顯示具體資源與變更，執行時核對同一內容摘要。
• 只查一次：核准後的狀態可能變動；執行點要重新檢查，並留下稽核收據。

OpenAI 的 needsApproval: true 可在工具執行前發出 tool_approval_requested，由應用程式核准或拒絕；它適合做互動層的停頓點。對高影響動作，本文仍要求後端把核身、資源歸屬、精確內容與時效一起驗證。相關交易邊界也可讀 Agent 交易設計。

FAQ：上線前最常問的八題

1. Agent 聽到「我同意」就可以執行嗎？

不應直接執行。先確認同意的是哪個資源、哪個新值，並由可信通道把核准綁到指定提案。

2. 手機來電號碼算核身嗎？

單看顯示號碼不宜作為高影響操作的唯一依據；讓後端使用產品既有的已驗證身分流程。

3. 每次查 FAQ 都要核身嗎？

不用替公開資訊加帳戶核身。只要查詢開始接觸個資或帳戶資料，就按資源範圍驗權。

4. SDK 的工具核准等於付款授權嗎？

不等於本文設計的完整交易授權。SDK 事件可讓應用程式暫停工具；付款或改帳戶資料仍須結合業務規則與後端執行檢查。

5. 先核准、隔天再執行可以嗎？

要看提案期限、核准期限與資源是否仍符合條件；過期就重走提案與核准。

6. 客服主管可以口頭破例嗎？

把例外寫成可審計的人工流程，由有權限的人在受控介面處理；不要讓 Agent 自行擴權。

7. 同一個請求重送了怎麼辦？

用提案 ID 與一次性鍵查已處理結果，驗證副作用次數沒有增加。

8. 第一個可做的練習是什麼？

拿一個假訂單，只做「改尚未出貨的地址」；跑未核身、重播、已出貨三組拒絕案例。

給新手的三個重點

1. 語音是輸入介面：它能描述需求，帳戶身分和權限由可信系統提供。
2. 提案與副作用分離：先讓人看清楚要改什麼，再讓後端執行指定版本。
3. 最後一關在執行點：重新驗身分、內容、期限、資源狀態與重送紀錄。