ServiceNow Now Assist預設代理群組設計被指放大二階提示注入風險

雲端資安業者AppOmni研究人員指出，企業要是採用ServiceNow Now Assist AI代理的預設設定，讓多個代理在平臺內自動協作，即使啟用提示防護，仍可能遭二階提示注入攻擊，讓高權限代理在不知情下幫攻擊者執行未授權操作。研究強調，風險關鍵不僅在模型本身，更在代理探索與代理群組（Team）的設計，可能放大設定不當帶來的風險。

Now Assist主打多代理協作，由後端的AiA ReAct Engine與Orchestrator負責分派任務並尋找具備相應能力的代理。當管理者選用支援代理探索的大型語言模型，例如預設的Now LLM或Azure OpenAI，並將多個代理部署在同一個LLM虛擬代理平面時，系統會自動將這些代理納入同一個代理群組，且在發布到介面時預設為可被其他代理發現。

對管理者而言，這樣的機制能簡化配置流程，但在實際營運環境中，當查詢型代理與具備高權限工具的代理被放在同一群組，便可能出現權限單純的代理在受提示影響時，將任務轉交給具更高權限的代理，進而放大設定上的風險。

研究人員用一個示範情境說明，當系統中有兩個僅供管理者使用的Now Assist代理，一個專門閱讀與摘要ITSM工單，另一個則具備在任務相關資料表上讀取、建立與更新紀錄的能力。。同時，系統內有一名低權限使用者，只能建立自己的工單，無法查看他人工單。

低權限使用者先建立一張工單，並在描述欄放入事先設計的提示，要求任何讀取該欄位的代理必須先去讀取另一張高敏感度工單的內容，再把資料複製回目前工單。依ServiceNow的存取控制，他原本無權查看那張敏感工單，而測試期間提示注入防護功能也已啟用。

問題出現在管理者後續處理這張工單時，分類代理讀取描述欄後收到隱藏指令，因自身無法跨工單存取，便在同一代理群組內尋找可協助的代理，最終由具備CRUD能力的紀錄管理代理代為讀取敏感工單並把內容寫回來。由於Now Assist代理會以啟動對話者的權限運作，整個流程等同於讓管理者在不知情的情況下，替攻擊者完成跨工單存取，突破原有控制。

研究人員在其他測試中還發現，要是提示內容進一步引導代理指派角色，可能出現替攻擊者加上Admin角色的情境，特別是在啟用SMTP時，代理甚至可能被誘導寄出含敏感資料的郵件成為外洩管道。風險上限取決於同一代理群組中代理具備哪些工具與權限，當查詢型與高權限操作混在一起時，影響範圍自然放大。

研究人員將結果回報給ServiceNow後，ServiceNow確認這屬於系統依設計運作的行為，並未將其視為程式漏洞，而是透過更新平臺文件，強調代理探索與代理群組設定可能帶來的安全風險，提醒使用者需透過正確組態降低風險。