Shufti Know Your Agent 將 AI 行動連結至經驗證的擁有人及權限

Shufti 於 10 月 28 日推出 Know Your Agent，將身份驗證延伸至 AI 代理程式，同時區分經驗證的擁有權與行動權限。Shufti Know Your Agent 的目標客戶，是接收由代表客戶或員工行事的軟件所發出的自動化請求之企業。其核心主張相當明確：識別帳戶持有人，並不代表以該人士名義採取的每項行動都已獲授權。

此公告令把代理程式連接至交易及敏感資訊的企業面對更大壓力。AI 代理程式，即會為達成目標而選擇及執行工作的軟件，需要可實際運用的授權。然而，授權範圍過寬，可能令原本合法的助手成為未經授權變更的來源。接收請求的企業必須分辨已獲批准的請求，與僅僅帶有有效憑證的行動。

Microsoft Entra Agent ID 透過管理代理程式身份、擁有權及存取權限，提供了一個有用的比較對象。Shufti 強調外部代理程式、其經驗證擁有人，以及該擁有人的授權範圍之間的聯繫，亦即委派權力的界限。這些做法由不同起點處理相互重疊的問題。關鍵問題是，當代理程式由指令走向實際交易時，授權是否仍可被有效執行。

Shufti Know Your Agent 為代理程式驗證加入擁有權及授權範圍

Shufti 的代理程式驗證發布公告介紹了一項結合代理程式身份、人類授權及權限檢查的服務。公司表示，該服務透過既有的客戶及企業驗證程序，將代理程式連結至個人或企業。擁有人可界定容許的行動、限制、到期時間及撤銷機制，亦即收回先前授予的權力。Shufti 表示，這些授權範圍適用於每一項請求。

這次公布的改變，在於將已識別的擁有人與受限行動連結起來，而不只是進行身份驗證。

這項分別相當重要，因為企業接收到的是一項請求，而非產生該請求的完整對話。客戶或會要求助手整理財務文件，但這項指示未必授權其轉移資金、更改帳戶資料，或與另一項服務分享文件。接收系統需要能夠執行的詮釋方式，了解客戶實際委派了甚麼權力。

Shufti 表示，代理程式會獲發可到期的憑證，企業亦可撤銷有關憑證。其 10 月 30 日的代理程式授權報道亦提及，系統會保存把請求、決策及已撤銷權限連結至代理程式及擁有人的紀錄。這些仍屬於已報道的產品能力。相關報道並未確立其在減少詐騙、營運可靠性或客戶採用率方面的獨立成效。

因此，這次發布改變了市場上可提供的產品主張，但未能定論其實際成效。企業可評估一項明確圍繞委派代理程式權力而設的服務，但仍需要證據證明，其決策與自身的交易規則一致。驗證結果只有在接收該結果的應用程式準確理解其容許範圍時才有用。

辨識軟件與辨識其當前權限之間，亦存在重要分別。即使助手仍是同一個可辨識的產品，它也可以為不同客戶工作。同一客戶亦可委派具不同限制的個別工作。企業不能僅憑助手的品牌、過往行為，或其已成功完成驗證的事實來推斷權限。

存取權杖，即為取得存取權而提交的憑證，如實作得當，可以攜帶受限制的權限。因此，Shufti 的論點應理解為對不足夠的授權設計提出挑戰，而非證明權杖本身必然缺乏界限。實際問題在於，憑證所代表的權限是否與特定商業行動相符。

這個框架令公告保持務實。Shufti 正提供另一種連結身份與委派權力的方法。買家應根據接收系統所執行的規則來判斷這項連結，包括當一個本來合法的代理程式要求其擁有人從未批准的事項時，系統會如何處理。

接收請求的企業承擔權限問題

即時壓力落在接受由客戶控制的代理程式所發請求的機構身上。銀行、市場平台及商業軟件供應商，必須決定哪些自動化行動可納入一般工作流程。當客戶對某項行動提出爭議時，它們亦需要作出可辯護的回應。接受自動化，擴大了既有帳戶控制措施必須處理的行動者範圍。

接受代理程式活動的企業，需要在客戶意圖與軟件自主裁量之間設立清晰界線。

假設一個購物助手獲指示更換一部辦公室裝置。客戶容許特定產品類別及送貨地點。在結帳過程中，助手發現某件商品缺貨，遂選擇替代品。商戶此時面對一項商業決定：這項替換是否仍在客戶授權範圍之內？

例如「找一件合適的產品」這樣的指示，留下了判斷空間。交易系統則需要更明確的條件。產品限制、收件人資料、購買限額及審批要求，決定該行動是否應繼續進行。若這些條件仍深藏於代理程式對話之中，商戶便無法可靠地套用它們。

這會為多個團隊帶來工作。產品經理必須界定代理程式可在不中斷下完成哪些行動。安全團隊必須確保應用程式執行這些定義。客戶支援團隊需要能以日常語言解釋所發生事情的紀錄。業務負責人則必須決定哪些例外情況需要重新批准。

開發人員亦面對相關的整合問題。應用程式介面，即用於交換請求的軟件介面，通常會分開提供不同操作。讀取紀錄、編輯紀錄、匯出紀錄及刪除紀錄，可能需要不同授權。籠統地容許「使用帳戶」，並不能說明客戶原本希望採取哪一種組合行動。

當代理程式在工作期間改變方向時，困難會更清楚。客戶可能批准研究供應商，但預期在落單前另行作出決定。著眼於完成任務的助手，可能會把落單視為理所當然的下一步。接收請求的企業需要一項能識別這個轉變的控制措施。

這項控制亦影響客戶體驗。每次無害操作都要求批准，會令委派變得不便。容許廣泛權力，則減少攔截具後果錯誤的機會。企業必須選擇在哪些情況下，中斷操作所提供的保護足以合理化其對注意力及完成時間的成本。

這正是 Shufti 的公告超越身份團隊範疇的原因。產品主張取決於能反映實際業務決定的規則。驗證可以識別涉及的各方，但機構仍須界定哪些行動需要權限。若沒有這項工作，經驗證的擁有人只會被附加到過於寬鬆的授權之上。

由此產生的壓力，既是組織層面，也是技術層面。企業需要就誰負責撰寫權限規則、誰批准變更，以及誰處理例外情況達成共識。代理程式安全產品無法獨自解決便利性、客戶控制權與營運風險之間互相衝突的期望。

競爭焦點在於授權於何處執行

Microsoft 的文件介紹了代理程式身份管理，包括擁有權、贊助、權限及活動紀錄。它讓管理員可檢視代理程式並管理其存取權。Shufti 的公告則聚焦於企業驗證代表個人或機構行事的代理程式。比較的重點在於每個系統在哪裡建立信任及套用控制。

核心分野，在於辨識合法代理程式與執行其特定任務界限之間的差異。

這些功能可以互相補足。機構可能集中管理一名員工的代理程式身份，而另一家企業則評估該代理程式的採購請求。內部系統建立機構責任；接收系統仍須決定所請求的採購是否符合所呈示的授權。

任何一方都不應假設另一方已回答所有問題。內部批准操作代理程式，並不會自動授權每一宗外部交易。外部驗證一名員工，亦不能證明該員工可以代表機構作出承諾。每個接收系統都需要與自身決定相關的證據。

這項分別避免了過於簡單化的供應商比較。以目錄為中心的產品與客戶驗證服務未必互相取代。它們的價值取決於環境、涉及的身份關係，以及已部署的控制措施。單憑產品名稱，無法確立覆蓋範圍相等。

Shufti Know Your Agent 以重視委派客戶行動的方式進入這個市場。其差異化將取決於企業能否有效地將這些授權範圍轉化為可執行的應用程式行為。若權限決定仍與執行行動脫節，所提供的保護便有限。應用程式必須確實拒絕超出已批准範圍的操作。

更廣泛的安全原則早於此公告已存在。OWASP 的過度代理能力指引指出，過度功能、權限及自主性所帶來的風險。它建議在下游系統中執行授權，而非依賴語言模型的判斷。語言模型根據已學習的模式及語境產生回應，令其輸出不適合作為唯一的權限界線。

就這個故事而言，該指引提供的是獨立基準，而非對 Shufti 的背書。相關問題是，即使代理程式一心要完成任務，獨立控制措施能否阻止未經授權的行動。即使代理程式誤解了任務，身份及政策仍須保持有效。

設想一個假設的商業助手，它可以草擬供應商訊息，但不能發送訊息。這個分別只有在訊息服務強制執行時才會成立。要求助手記住限制，會將最終決定留在同一個正在犯錯的系統內。拒絕發送的接收服務，則建立更強的界限。

這正是公告背後的競爭測試。供應商可以用不同方式描述代理程式、擁有人及審批流程。買家需要確立決定性權限檢查發生在哪裡。當有效身份提交無效請求時，最具後果的能力是對執行行動的控制。

人手檢查以不中斷的自動化換取額外控制

Shufti 說明，當請求超出授權範圍或跨越風險門檻時，會加入額外的人手驗證。據該公司稱，該流程可包括自拍活體檢測，以評估現場是否有真人在場。這為原本自動化的工作流程加入人為決策點。其實際效用取決於該人員實際被要求批准甚麼。

確認有人在場與確認知情批准，解決的是不同問題。

一個人可以完成身分驗證，卻未必理解擬議中的交易。只寫着「繼續」的批准畫面，所傳達的資訊少於清楚列出收款人、行動及後果的畫面。安全價值部分取決於介面是否令決策容易理解。單靠在場無法補足缺失的背景資訊。

這是分析上的限制，並非證明 Shufti 的實作失效。公告描述了一套升級機制，但並未獨立證實客戶如何理解其批准畫面。買家需要檢視實際體驗，並應區分成功的身分驗證與清晰傳達的授權決定。

一項假設性的付款可說明兩者差異。代理起初獲准向既有供應商付款，其後卻收到改用另一收款人的指示。額外檢查提供了制止此變更的機會。但相關人士需要看到收款人已改變，而不是只被要求再次核實身分。

批准亦必須持續與最終行動保持連結。若重要交易細節其後改變，先前的決定可能已不能反映將會發生的事。這是接收應用程式及其驗證整合的設計問題。獲批准的請求與已執行的請求需要有相符的界限。

中斷亦帶來營運上的選擇。代理可能在其擁有人不在時工作。當需要批准時，系統須有明確結果：暫停、拒絕，或保留草稿。為讓任務繼續推進而悄然擴大權限，會削弱檢查的目的。

無障礙與復原安排亦值得注意。合法客戶未必能完成預期的驗證方式。企業需要提供一個可維持所需保證程度的替代方案。否則，原本為支援已授權自動化而設的控制措施，可能會成為具有效權限客戶的障礙。

同樣的張力亦見於一般知識工作。尋找資訊、草擬答案、發送答案，以及更改共享紀錄，代表不同程度的後果。建立可搜尋知識庫的團隊，也面對類似界限：檢索資料與授權後續行動之間的界限。取得有用背景資訊本身，並不等於獲准發佈或修改內容。

因此，取捨十分具體。額外驗證可在具重要後果的時刻恢復人手控制，但亦會中斷委派流程。企業需要反映交易風險及用戶期望的門檻。把每次中斷都視為安全上的成功，會忽略當事人是否獲得足夠資訊以作出有意義的決定。

推出聲稱仍未釐清成效與問責

截至 11 月 2 日，經審閱的資料證實了這項公告及其所述設計，但未有提供對完整服務的獨立評估。當產品結合身分檢查、權限規則及交易控制時，這項區分十分重要。某個元件運作成功，並不能證明整個工作流程有效。

驗證缺口關乎完整系統能否在現實的失效情況下執行正確決定。

有用的評估應同時檢視未經授權的請求及合法活動。阻止攻擊者固然重要，但讓客戶獲准的工作完成同樣重要。若系統過於頻繁地拒絕一般工作，企業便會面對放寬規則的壓力。安全性與易用性需要一併量度。

公開公告並未證實，在相連應用程式之間，已撤銷的權限能多快停止活動。這是一個重要的實作問題。當擁有人取消許可時，代理可能已有等待執行的請求。買家需要了解，這些請求在完成前是否會再次接受檢查。

任務鏈帶來另一項未解決問題。一個助理可要求另一服務或代理執行任務的一部分。接收方企業便需要了解，原始授權是否涵蓋該項委派。若沒有明確限制，清晰的初始授權可在工作流程後段變得含糊。

行為識別亦引發另一類評估問題。軟件可在更新後改變行為，或遇上不熟悉的任務。買家應詢問，系統如何區分合法變化與可疑活動。經審閱的推出資料並未獨立證實，系統在這些情況下的量度準確度。

這些問題不應被表述為已發現的漏洞。它們指出了評估公司聲稱所需的證據。沒有經審閱的資料顯示 Shufti 的服務未能通過這些測試。同樣地，僅憑公告亦不能證明它已在生產環境中通過。

問責同樣需要審慎處理。把代理與擁有人關聯起來的紀錄，可協助調查人員重建事件順序。但這並不會自動解決擁有人是否理解某項請求、憑證是否遭入侵，或應用程式是否正確執行等問題。這些仍是各自獨立的事實問題。

當紀錄保留決策背景時，便會更有用。調查人員需要知道，請求到達時適用哪些權限，以及最終實際發生了甚麼行動。目前的帳戶設定未必能解釋過去的交易。證據應讓審查者可區分後來的設定變更與較早前存在的權限。

國家標準工作加強了這些未解決問題的重要性。9 月，NIST 的代理身分識別項目在收集持份者意見後，將軟件開發列為首個實作使用案例。這項工作為評估身分及授權提供更廣泛背景，但並不會認證 Shufti 的產品，亦不會裁定任何商業方案的成效。

對買家而言，含意很直接。應把這次推出視為包含可測試聲稱的具體產品方案，並要求與預期部署相關界限的證據。對可信代理的廣泛保證，應讓位予有關容許行動、拒絕條件及事件重建的具體答案。

關注整合證據、獨立測試及權限可攜性

下一批有用訊號，應顯示這項主張如何超越推出資料而實際運作。未來數月，應依次留意整合證據、獨立測試及權限可攜性。權限可攜性是指在不同服務之間保留可理解的授權界限。每項訊號都測試已公布方案的不同部分。

進展應以對代理行動的可觀察控制來判斷，而非以已公布功能的數量來衡量。

首先，留意有記錄的部署案例，說明接收應用程式如何執行授權範圍。有用的說明會列出容許任務、禁止的轉變，以及代理跨越該界限時的回應。只有客戶名稱而缺乏營運細節，所能證明的較少。具體的整合證據可加強實際採用的論據。

這類證據應包括例外情況，而不只成功交易。若部署案例說明在取消、驗證失敗或擁有人無法聯絡時會發生甚麼，便更具參考價值。這些情況揭示工作流程在壓力下是否仍可維持其權限模型。只描述成功完成的內容，會令這些問題仍未有答案。

其次，留意完整授權流程的獨立測試。最有用的結果會檢視冒充、遭入侵的憑證、已變更的交易細節及已撤銷的權限。測試亦應包括系統錯誤中斷的合法活動。涵蓋兩類情況的證據，會令成效更容易評估。

若獨立測試顯示控制措施可跨越現實的應用程式界限持續有效，便可加強信心。範圍狹窄的示範只支持較狹窄的結論。結果應說明測試了甚麼，以及哪些內容仍不在範圍內。買家應避免把身分檢查的證據延伸為對每項下游交易均欠缺支持的聲稱。

第三，留意 Shufti 及其他身分供應商如何處理跨組織界限的權限。擁有人的授權需要具備接收方企業可以解讀的意義。若每項整合都需要各不相關的定義，採用便會更難維持。權限之間的清晰對應，可支援更一致的執行。

可攜性同樣需要限制。獲商戶接受的許可，不應悄然變成對無關業務系統的權限。當互通性連同身分一併保留限制時，才具價值。若有證據顯示權限在交接之間仍受界限約束，便可加強公告的核心主張。

Shufti Know Your Agent 為買家提供一項具體主張以供評估：連結代理、其擁有人及其獲准行動。下一項決定是，這種連結能否在現實工作流程中維持。要求以你們機構實際委派的任務作示範，包括一項超出許可的請求，以及執行期間的取消。檢視應用程式阻擋了甚麼、相關人士看到了甚麼，以及紀錄事後說明了甚麼。評估應緊扣具體業務界限，例如草擬與發送之間，或研究與採購之間。在擴大代理存取權前，你的團隊能否確切指出該界限在哪裏執行，並證明任務改變時它仍然有效？