云安全公司AppOmni的研究人员指出，企业若采用ServiceNow Now Assist AI代理的默认设置，让多个代理在平台内自动协作，即使启用了提示防护，仍可能遭受二级提示注入攻击，导致高权限代理在不知情的情况下为攻击者执行未授权操作。研究强调，风险的关键不仅在于模型本身，更在于代理的探索机制与代理组（Team）的设计，不当配置可能放大安全风险。

Now Assist主打多代理协作，由后端的AiA ReAct Engine与编排器负责任务分派并寻找具备相应能力的代理。当管理员选择支持代理探索的大型语言模型（如默认的Now LLM或Azure OpenAI），并将多个代理部署在同一LLM虚拟代理平面时，系统会自动将这些代理纳入同一个代理组，并在发布到界面时默认设置为可被其他代理发现。

对管理员而言，这种机制能简化配置流程，但在实际运营环境中，当查询型代理与具备高权限工具的代理被置于同一组内，就可能出现权限较低的代理在受到提示诱导时，将任务转交给权限更高的代理，从而放大配置不当带来的风险。

研究人员通过一个示例场景说明：系统中有两个仅限管理员使用的Now Assist代理，一个专门用于阅读和摘要ITSM工单，另一个则具备在相关数据表中读取、创建和更新记录的权限。同时，系统中有一名低权限用户，仅能创建自己的工单，无权查看他人工单。

该低权限用户先创建一张工单，并在描述栏中植入预先设计的提示指令，要求任何读取该字段的代理必须先去读取另一张高敏感度工单的内容，再将数据复制回当前工单。根据ServiceNow的访问控制，他本无权查看那张敏感工单，且测试期间提示防护功能已启用。

问题出现在管理员后续处理该工单时，分类代理读取描述栏后收到隐藏指令，由于自身无权跨工单访问，便在同一代理组内寻找可协助的代理，最终由具备CRUD能力的记录管理代理代为读取敏感工单并将内容写回。由于Now Assist代理以启动对话者的权限运行，整个流程等同于让管理员在不知情的情况下，为攻击者完成跨工单数据访问，突破原有权限控制。

研究人员在其他测试中还发现，若提示内容进一步引导代理分配角色，可能出现为攻击者添加管理员角色的场景，尤其在启用SMTP功能时，代理甚至可能被诱导发送包含敏感信息的邮件，成为数据外泄的渠道。风险上限取决于同一代理组中各代理所具备的工具与权限，当查询型代理与高权限操作代理混用时，影响范围自然扩大。

研究人员将结果反馈给ServiceNow后，ServiceNow确认该行为属于系统设计的正常逻辑，并未将其认定为程序漏洞，而是通过更新平台文档，强调代理探索与代理组配置可能带来的安全风险，提醒用户需通过正确配置降低潜在威胁。