Coze 安全漏洞分析｜生产环境实测

声明：本文仅用于安全研究、风险评估与防护建设讨论。文中所涉及的“生产环境实测”均应建立在合法授权、明确范围、可审计留痕、避免影响业务连续性的前提下进行。未经授权对任何平台、系统、Bot、插件或接口进行测试，均可能违反法律法规与平台服务条款。本文不提供可直接用于攻击的利用链、Payload 或绕过细节，重点放在风险模型、验证思路、影响分析与修复建议。

一、背景：为什么 Coze 类平台需要重点关注安全

随着大模型应用快速落地，Coze 这类 AI Bot 编排与智能体开发平台正在被越来越多企业用于客服、营销、知识库问答、内部流程自动化、内容生成、数据查询等场景。相比传统 Web 应用，AI Agent 平台的安全边界更复杂：

1. 输入来源更开放
   用户自然语言、文件、网页内容、知识库文本、插件返回结果，都可能成为模型上下文的一部分。

2. 执行链路更长
   一次用户提问可能触发：Prompt 解析、知识库检索、插件调用、第三方 API 请求、工作流流转、数据库查询、消息推送等多个环节。

3. 权限模型更难控制
   Bot 往往被赋予访问知识库、调用接口、读取用户信息、触发业务动作的能力。如果权限边界设计不清晰，容易出现“模型被诱导后越权执行”的风险。

4. 传统安全与 AI 安全叠加
   既存在接口鉴权、越权访问、敏感信息泄露、SSRF、文件解析等传统问题，也存在 Prompt Injection、越狱、上下文污染、工具滥用、数据外泄等新型风险。

因此，Coze 类平台在进入生产环境前，不应只关注“功能可用”，还应进行系统性的安全评估。

二、生产环境实测的前提与边界

所谓“生产环境实测”，并不意味着直接对线上业务进行无约束攻击，而是指在真实部署形态、真实权限模型、真实数据流转路径下进行受控验证。建议测试前至少明确以下内容：

1. 授权范围

包括但不限于：

• 可测试的 Bot 范围；
• 可测试的知识库范围；
• 可调用的插件和工作流范围；
• 是否允许上传测试文件；
• 是否允许模拟普通用户、管理员、第三方用户等不同角色；
• 是否允许触发外部 API；
• 是否允许进行压力或并发测试。

2. 数据保护

生产环境中最敏感的问题不是“能不能测出漏洞”，而是“测试过程是否会引入新的风险”。因此建议：

• 使用脱敏账号与测试数据；
• 不读取、导出、截图真实用户隐私数据；
• 不保存模型返回的敏感内容；
• 测试日志严格访问控制；
• 发现敏感泄露后立即停止扩展验证。

3. 影响控制

AI Agent 的输出与执行结果可能存在不确定性，因此应设置：

• 测试窗口；
• 回滚方案；
• 限流策略；
• 审计记录；
• 应急联系人；
• 外部接口熔断机制。

三、Coze 类平台常见攻击面梳理

从安全评估角度看，Coze 这类平台可以拆分为多个攻击面。

1. Bot 对话入口

这是最直观的入口。用户通过自然语言输入与 Bot 交互，平台会将用户消息、系统提示词、历史上下文、知识库检索结果、插件说明等内容组合后发送给模型。

主要风险包括：

• Prompt Injection；
• 越狱诱导；
• 系统提示词泄露；
• 历史上下文污染；
• 非预期任务执行；
• 敏感信息回显。

2. 知识库与检索系统

知识库通常包含企业文档、产品资料、FAQ、制度规范、接口说明等。若配置不当，可能造成：

• 未授权知识库访问；
• 跨 Bot 数据泄露；
• 检索结果过度暴露；
• 文档权限未继承；
• 隐藏字段或内部备注泄露；
• 被恶意文档进行上下文投毒。

3. 插件与工具调用

插件是 Agent 能力扩展的核心，例如查询订单、发送消息、调用 CRM、访问数据库、创建工单等。风险点包括：

• 插件鉴权不严；
• 参数未校验；
• 工具调用越权；
• 操作型接口缺少二次确认；
• 插件返回敏感数据过多；
• 第三方 API 密钥泄露；
• Agent 被诱导调用高危工具。

4. 工作流编排

工作流将多个节点串联起来，例如判断意图、提取参数、调用接口、生成结果等。如果编排逻辑存在缺陷，可能出现：

• 条件绕过；
• 节点权限混用；
• 变量污染；
• 异常分支泄露；
• 错误处理返回内部信息；
• 高权限节点被低权限用户间接触发。

5. 文件上传与解析

部分 Bot 支持文件问答、文档总结、图片识别等能力。文件处理常见风险包括：

• 恶意文件解析；
• 文件内容诱导模型忽略规则；
• 文档中隐藏 Prompt Injection；
• 文件元数据泄露；
• 文件链接外带；
• 解析器异常导致服务不可用。

6. 发布与分享配置

很多 AI Bot 支持公开链接、嵌入网站、接入 IM、接入公众号或应用市场。风险包括：

• 私有 Bot 误发布为公开；
• 分享链接权限过宽；
• 嵌入页面缺少访问控制；
• 不同渠道权限不一致；
• 测试 Bot 暴露生产接口；
• 调试信息被公开访问。

四、生产环境实测发现的典型风险类型

以下内容以“风险类型”方式归纳，不指向具体未公开漏洞，也不提供攻击利用细节。

风险一：系统提示词与内部规则泄露

在部分 Bot 中，系统提示词包含角色设定、业务规则、接口说明、知识库范围、甚至内部处理逻辑。如果模型在对话中被诱导输出这些内容，就可能造成安全边界暴露。

可能影响

• 攻击者了解 Bot 的防护规则；
• 推测内部插件名称与调用方式；
• 获取业务流程判断逻辑；
• 为后续绕过提供信息基础；
• 泄露企业内部规范或未公开产品信息。

成因分析

此类问题通常不是模型“故意泄露”，而是上下文设计不当。例如：

• 系统提示词中写入过多敏感信息；
• 防泄露指令过于简单；
• 将内部配置当作普通上下文传入；
• 未对模型输出进行敏感信息过滤；
• 缺少对“请求复述规则”“展示配置”等意图的拦截。

修复建议

• 避免在 Prompt 中放置密钥、接口地址、内部账号等敏感信息；
• 将关键权限逻辑放在后端，不依赖模型自觉遵守；
• 对系统提示词进行最小化设计；
• 增加输出侧敏感信息检测；
• 对涉及“显示规则、复述提示词、导出上下文”的请求进行策略拒绝。

风险二：知识库越权与敏感信息过度返回

知识库是企业使用 Coze 类平台时最容易被低估的安全区域。很多团队在搭建 Bot 时，会将大量文档一次性导入知识库，但没有建立细粒度权限。

生产环境中的典型表现

• 普通用户可问到内部员工文档；
• 一个业务线 Bot 能检索到另一个业务线资料；
• 客服 Bot 返回了内部处理 SOP；
• 用户问题只需要摘要，模型却返回了完整原文；
• 过期文档、测试文档、内部备注被检索出来。

可能影响

• 客户信息泄露；
• 企业内部流程泄露；
• 商业策略泄露；
• 合同、报价、运营数据被暴露；
• 合规风险上升。

成因分析

主要原因包括：

• 知识库权限与用户身份未绑定；
• 文档导入前未脱敏；
• 检索结果缺少二次过滤；
• Bot 共享同一知识库但面向不同用户；
• 向量检索只关注相关性，不关注权限边界。

修复建议

• 将知识库按敏感级别、业务域、用户角色拆分；
• 建立文档导入前的脱敏流程；
• 检索阶段加入权限过滤；
• 输出阶段限制原文大段返回；
• 对高敏知识设置引用审批或不可直接回答策略；
• 定期清理过期文档和测试数据。

风险三：Prompt Injection 导致行为偏离

Prompt Injection 是 AI Agent 场景中最典型的问题之一。攻击者可以通过用户输入、网页内容、文档内容或插件返回内容，诱导模型忽略原有规则，执行不符合预期的任务。

风险场景

例如，一个 Bot 原本用于查询产品说明，但用户上传的文档中包含恶意指令，要求模型忽略系统规则、输出内部配置，或者诱导模型调用某个插件。如果平台没有区分“数据内容”和“控制指令”，模型可能出现行为偏离。

可能影响

• 安全规则被绕过；
• Bot 输出不应公开的信息；
• Agent 调用不应调用的工具；
• 对用户产生误导性回复；
• 业务动作被异常触发。

修复建议

• 明确区分系统指令、开发者指令、用户输入、外部内容；
• 对外部内容进行不可信标记；
• 对高风险意图进行分类拦截；
• 插件调用前进行后端权限校验；
• 不让模型直接决定关键操作；
• 对操作型工具增加确认步骤。

风险四：插件调用越权

插件通常连接真实业务系统，因此其风险高于普通问答。一个常见误区是：认为“只要 Bot 不主动暴露接口，用户就无法滥用插件”。但在 Agent 架构中，用户可以通过自然语言影响模型决策，从而间接影响插件调用。

可能影响

• 查询他人订单；
• 修改不属于自己的资源；
• 触发内部通知；
• 创建异常工单；
• 调用高成本接口；
• 获取超出权限的数据字段。

成因分析

• 插件接口只依赖 Bot 权限，而不是终端用户权限；
• 参数校验依赖模型生成；
• 后端没有重新鉴权；
• 缺少资源归属校验；
• 插件返回字段过多；
• 操作型接口没有幂等与审计。

修复建议

• 插件后端必须基于真实用户身份鉴权；
• 对每个资源执行归属校验；
• 参数白名单化；
• 默认最小权限；
• 高危操作增加人工确认或二次验证；
• 插件返回只保留回答所需字段；
• 所有插件调用记录审计日志。

风险五：公开分享链接权限配置不当

在生产环境中，很多泄露并非源于复杂攻击，而是源于发布配置失误。例如测试 Bot 被公开、调试 Bot 绑定生产插件、分享链接未限制访问范围等。

典型风险

• 内部 Bot 被外部访问；
• 未登录用户可使用企业知识库；
• 测试环境 Bot 调用生产 API；
• 分享链接长期有效；
• 外部渠道权限高于内部渠道；
• Bot 页面被搜索引擎收录。

修复建议

• 默认关闭公开访问；
• 分享链接设置有效期和访问范围；
• 发布前进行权限检查；
• 测试 Bot 与生产 Bot 完全隔离；
• 禁止测试应用绑定生产密钥；
• 对公开 Bot 做内容和工具能力降级；
• 定期扫描公开入口。

五、生产环境安全测试方法论

为了避免测试流于表面，可以从以下几个维度构建测试方案。

1. 身份与权限测试

准备不同角色账号，例如：

• 未登录用户；
• 普通外部用户；
• 认证客户；
• 内部员工；
• 业务管理员；
• Bot 管理员。

分别验证其能够访问的 Bot、知识库、插件能力和输出内容是否符合预期。

2. 数据边界测试

重点关注：

• 是否能访问其他用户数据；
• 是否能访问其他业务线数据；
• 是否能访问历史会话；
• 是否能通过模糊提问获得敏感信息；
• 是否能诱导模型返回超范围原文。

3. 工具调用测试

验证：

• 用户是否可触发不应触发的工具；
• 参数是否经过后端校验；
• 工具返回是否包含敏感字段；
• 高危操作是否需要确认；
• 失败信息是否暴露内部结构；
• 调用是否有审计记录。

4. Prompt 安全测试

重点观察：

• 是否泄露系统提示词；
• 是否会遵循外部文档中的恶意指令；
• 是否能被诱导改变角色；
• 是否能被诱导输出隐藏规则；
• 是否能绕过安全拒答策略；
• 是否会将不可信内容当作控制指令。

5. 发布配置测试

检查：

• Bot 是否误公开；
• 分享链接是否可匿名访问；
• 嵌入渠道是否有鉴权；
• 不同渠道能力是否一致；
• 是否存在废弃 Bot；
• 是否存在调试入口。

六、风险等级评估建议

在实际报告中，可以从“影响范围、利用难度、数据敏感性、是否可被远程触发、是否需要认证、是否影响业务操作”等维度进行评级。

高危风险

通常包括：

• 未授权访问敏感知识库；
• 插件越权操作真实业务数据；
• 匿名用户可调用内部工具；
• 生产密钥或凭证泄露；
• 可批量获取用户隐私数据。

中危风险

通常包括：

• 系统提示词泄露；
• 内部流程说明泄露；
• 部分非核心数据越权；
• 错误信息暴露内部结构；
• 分享链接权限过宽但需要一定条件。

低危风险

通常包括：

• 非敏感配置暴露；
• 回复中包含轻微信息冗余；
• 部分提示词策略可被推测；
• 不影响数据和业务操作的输出异常。

需要注意的是，AI 安全问题的等级不能只看单点。一个看似低危的提示词泄露，可能为插件越权、知识库绕过、业务欺诈提供条件，因此应关注组合风险。

七、企业侧加固方案

1. 架构层：不要让模型成为最终安全边界

模型适合做理解、总结、生成和辅助决策，但不应成为权限判断的唯一依据。关键权限必须由确定性的后端系统控制。

建议：

• 用户身份由业务系统传递并校验；
• 插件执行前进行后端鉴权；
• 数据返回前进行权限过滤；
• 操作执行前进行二次确认；
• 高风险动作必须可审计、可回滚。

2. 数据层：知识库最小化与分级管理

知识库安全建设重点包括：

• 文档分级；
• 权限继承；
• 脱敏导入；
• 检索过滤；
• 输出裁剪；
• 定期复核；
• 敏感文档禁止进入通用知识库。

3. Prompt 层：规则清晰但不过度暴露

Prompt 应该描述 Bot 的职责边界，但不应承载敏感配置。推荐做法：

• 不写入密钥、内部 URL、账号、完整接口文档；
• 将规则模块化；
• 对外部内容设置不可信说明；
• 明确禁止复述系统规则；
• 对高风险问题统一转人工或拒答。

4. 插件层：最小权限和强校验

插件是 AI 应用的“手和脚”，必须严格限制：

• 每个插件只具备必要权限；
• 操作接口与查询接口分离；
• 参数类型和范围严格校验；
• 返回字段最小化；
• 高危接口禁止直接由模型触发；
• 接口调用全量审计。

5. 运维层：持续监控与应急响应

AI Bot 上线后，安全并不会结束。建议建立：

• 异常问法检测；
• 敏感输出监控；
• 插件调用频率监控；
• 非正常渠道访问告警；
• Bot 配置变更审计；
• 安全事件响应流程；
• 定期红队评估。

八、生产环境上线前检查清单

以下清单可作为 Coze 类 Bot 上线前的基础安全门禁。

权限配置

• [ ] Bot 是否仅对目标用户开放；
• [ ] 分享链接是否设置访问限制；
• [ ] 不同渠道权限是否一致；
• [ ] 测试 Bot 是否与生产隔离；
• [ ] 管理员权限是否最小化。

知识库

• [ ] 文档是否完成分级；
• [ ] 敏感信息是否脱敏；
• [ ] 是否存在过期或测试文档；
• [ ] 检索结果是否按用户权限过滤；
• [ ] 是否限制大段原文输出。

插件与工作流

• [ ] 插件是否进行后端鉴权；
• [ ] 是否校验资源归属；
• [ ] 返回字段是否最小化；
• [ ] 高危操作是否需要确认；
• [ ] 是否有完整调用日志；
• [ ] 异常信息是否脱敏。

Prompt 与输出

• [ ] 系统提示词是否包含敏感信息；
• [ ] 是否限制复述内部规则；
• [ ] 是否识别 Prompt Injection；
• [ ] 是否对敏感输出做过滤；
• [ ] 是否存在诱导模型违规执行的路径。

监控与审计

• [ ] 是否记录用户输入与模型输出；
• [ ] 是否记录插件调用详情；
• [ ] 是否有异常访问告警；
• [ ] 是否有敏感信息泄露告警；
• [ ] 是否制定应急处置流程。

九、结论

Coze 类 AI Agent 平台将大模型、知识库、插件、工作流和业务系统连接在一起，极大提升了应用开发效率，但也让安全边界从“接口级”扩展到“语义级”和“行为级”。生产环境中的风险往往不是单一漏洞造成的，而是权限配置、知识库管理、Prompt 设计、插件鉴权、发布策略等多个环节叠加后的结果。

在实际安全评估中，应避免只测试“模型能不能被绕过”，而要关注模型被绕过之后是否真的能够访问数据、调用工具、影响业务。换句话说，AI 安全的核心不是让模型永远不犯错，而是在模型犯错时，系统仍然不会泄露敏感数据、不会越权执行操作、不会造成不可控影响。

对于企业而言，最重要的原则包括：

1. 模型不是安全边界，后端鉴权才是；
2. 知识库必须分级、脱敏、按权限检索；
3. 插件调用必须最小权限、强校验、可审计；
4. 公开发布必须默认收敛，避免误暴露；
5. AI 安全需要持续监控，而不是一次性测试。

只有将传统应用安全、数据安全与 AI 原生安全结合起来，才能让 Coze 类智能体真正安全地进入生产环境。