云计算安全企业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确认这属于系统依设计运行的行为，并未将其视为程序漏洞，而是通过更新平台文件，强调代理探索与代理群组设置可能带来的安全风险，提醒用户需通过正确组态降低风险。
