Silverfort 為 Microsoft Copilot Studio 智能代理注入運行時身份安全

這種做法與依賴靜態角色或邊界防禦的傳統安全模型有根本差異。Silverfort 將身份安全定位為一套運行時控制平面，而非 AI 的外圍包覆層，用以治理代理嘗試執行的每一個動作 。

強制機制實際如何運作

這項整合主要仰賴三個實務機制：

• 即時存取評估：在 Copilot 代理嘗試行動的瞬間，平台即分析請求並內嵌式地執行存取政策。未經授權的存取在執行前就會被封鎖，而非事後才留下記錄 。
• 身份鏈感知：政策引擎會追溯每個行動背後的完整身份——包含發起工作階段的使用者、涉及的任何機器身份，以及正在存取的資源敏感度——藉此區分合法操作與越權行為 。
• 最小權限強制執行：僅授予代理真正需要的特定資料與服務權限。開發過程中為了「讓它動起來」而常常鬆散授予的過度權限憑證，會受到標記並在運行時被阻擋 。

Silverfort 安全長 Ron Rasin 對此哲學總結得直白：「若缺乏深層的身份脈絡，根本無法在即時做出『代理的行動是合法還是越權』的明智判斷。這就是為何代理式安全在本質上是一個身份問題。」

問題所在：代理現在會執行行動，而非僅對話

企業對代理式 AI 的採用速度，已遠遠超過多數身份與存取管理（IAM）系統所能負荷。微軟報告指出，超過 80% 的《財星》500 大企業已在部署以低程式碼工具建置的活躍代理，同時有 29% 的員工已在工作中使用未經授權的 AI 代理 。這些數字說明了攻擊面的擴張速度遠快於治理能力的跟進。

核心風險已經轉移。早期對 AI 的憂慮集中在內容安全——幻覺、偏見、有害輸出。但代理式 AI 帶來一個更棘手的問題：存取控制。這些代理會自我驗證、擷取企業資料、觸發業務工作流程，並與跨雲端及地端環境的系統互動 。一個設定錯誤且擁有廣泛權限的代理，可能直接成為資料外洩或權限提升的管道。

這個問題更被 Silverfort 所謂的「開發者困境」所加劇。在 Copilot Studio 中建置代理的業務團隊，為了快速讓功能上線，常在開發階段授予廣泛的管理員權限。這些過度授權的憑證存續到正式環境，形成傳統 IAM 工具無法治理的持久性、未受管理的存取路徑 。

傳統身份系統——密碼、多因素驗證、靜態角色型存取控制——是為人類在可預測的工作階段中登入與登出而設計。它們無法應對 AI 代理那種動態、程式化、鏈式驗證的模式，這些代理會呼叫 API、承接機器身份，並代表多位使用者快速連續行動 。

這在更廣闊的版圖中定位在哪裡

Silverfort 與 Copilot Studio 的整合，是業界更廣泛地將身份作為代理式 AI 控制平面的一環。該公司也正與 Google Cloud 的 Agent Gateway 進行類似的整合，重點在於提升代理與 API 及外部工具溝通時的可視性與強制力 。微軟本身也已為 Copilot Studio 推出互補的安全強化功能，包括消除持續性機密的聯邦身份憑證（Federated Identity Credentials），以及讓 IT 人員封鎖風險自訂代理的管理控制 。不過，Silverfort 的做法與眾不同之處，在於它將運行時決策直接嵌入代理本身的執行流程，而非從外部管理安全。

對於評估這項整合的安全團隊而言，實務問題相當直接：平台能否在每次代理採取行動之前，基於「誰真正在背後發起這個行動」的完整圖像，檢查並治理每一項行動？Silverfort 相信，在運行時、在存取權限授予之前、在損害造成之前，就即時回答這個問題，是唯一能跟上代理式 AI 部署速度的模式。