大模型安全评估POC如果只准备几条提示注入语句，很容易得到“攻击被拒绝”的漂亮结果，却遗漏真正的企业风险。用户可以顺利获得合法登录身份访问错误知识库，Agent可能用共享工具账号执行越权查询，敏感内容也可能出现在日志、缓存或故障回退路径中。注入测试顺利获得只能证明特定输入在特定版本被处理，不能证明端到端权限和数据边界创建。

使用方式：面向采购、安全、平台和业务联合POC，强调合成数据、受控环境、证据与恢复，不提供可直接滥用的攻击载荷。

先明确POC评估的是系统，不是单个模型回答

企业AI应用由身份、网关、知识库、模型、工具、日志和基础设施共同组成。一个模型拒绝了危险指令，应用仍可能在检索阶段取回无权文档；工具代理可能已经执行动作；完整Prompt可能被运维日志保存。测试对象应是完整调用链及其责任边界。

POC前先画出主体、数据、模型、工具和输出。明确哪些控制由平台提供，哪些依赖企业IAM、知识ACL、业务审批和运维流程。厂商演示环境若使用单用户、公开数据和无工具模型，只能证明最短路径，不能代表企业集成后的表现。

测试结论也应限定版本、配置、身份和环境。模型或策略升级、知识索引重建、工具接入和路由变化后，原结论可能失效，需要回归。

POC要从单点攻击扩展为场景网格

下图以风险场景为行、控制阶段为列。阅读任务是检查每个场景是否同时有预防、检测、处置和恢复证据，而不是只记录“拦截/未拦截”。

身份越权测试验证用户、应用、租户与模型资源是否正确关联；知识跨域测试观察候选片段和生成上下文；工具滥用测试检查工作负载身份、参数范围与人工确认；敏感输出测试覆盖同步和流式响应；日志暴露测试则核对谁能查看Prompt、工具结果和调试信息。

每个场景至少要回答四件事：控制在哪里生效、异常如何被发现、影响怎样被限制、系统如何恢复到可信状态。只有第一次请求被拒绝，无法说明缓存、临时文件、工具任务和日志都已清理。

用例要写前置条件、期望结果和失败边界

安全用例不能只有一句“测试提示注入”。应写明测试身份、租户、应用、模型、知识库、工具权限、数据样本、策略版本和网络路径；期望结果包括允许、拒绝、降级、人工复核或限制输出；失败边界则说明哪些现象必须阻断POC。

例如跨租户检索可使用两个测试租户和带独特标识的合成文档。无权用户查询时，不仅最终答案不能显示内容，候选和生成上下文也不应包含无权片段。若系统在回答层隐藏，却已把片段发送给模型服务，仍应记录为高风险缺口。

工具用例使用无破坏性的测试动作。验证模型是否只能选择允许工具，参数是否受范围限制，执行系统收到哪个主体，人工确认能否阻止高影响操作。不要为了测试而触碰生产系统或真实敏感数据。

测试网格至少覆盖六类企业风险

以下清单可作为场景池，具体优先级按业务调整：

• 身份与模型越权：普通用户请求高权限模型、过期角色或错误租户；
• 知识与数据跨域：无权文档进入候选、上下文、缓存或回答；
• 工具与Agent越权：共享账号、参数放大、陆续在动作未确认；
• 输入输出泄露：敏感字段出现在同步、流式、错误或导出结果；
• 日志和运维暴露：Prompt、附件、凭据或工具结果被过度留存与查看；
• 故障与旁路：网关、策略或身份服务异常后直连、默认放行或证据丢失。

场景之间会交叉。例如一次知识越权可能由身份映射错误引起，并顺利获得日志扩大暴露。测试报告应保留根因假设与跨场景影响，不要为追求清晰把复杂问题硬拆成互不相关的分数。

“顺利获得”要建立在多次、变体和反向证据上

同一用例至少应包括允许样本、拒绝样本和边界变体。一次拦截可能来自关键词巧合、模型随机性或临时规则。重复执行、改变无关措辞、切换同步与流式模式、变更身份后复测，可以判断控制是否来自正确策略。

顺利获得证据包含请求标识、策略输入、模型与知识版本、控制结果、告警、审计和清理状态。若只能提供截图，无法说明真实执行对象和版本，应列为待补证据。对于概率性模型输出，评估口径需承认不确定性，不写固定拦截保证。

发现问题后先确认影响面，再做最小修复，随后使用原用例与相邻变体回归。修复一个关键词而不处理身份或数据边界，不能视为根因解决。

结果分级要区分阻断、限制试点和待补证据

可以把结果分为四类：关键边界顺利获得；控制有效但证据不完整；存在缺口但可顺利获得限制数据、用户或工具进入小范围试点；存在无权数据暴露、高权限工具执行或无法控制的旁路，阻断相关范围。分级要写影响对象与复验条件，而不是只给一个总分。

POC发现高风险缺口不必自动终止所有采购讨论，但不能带着未处理风险进入生产。可以收缩试点范围、关闭工具、使用合成数据、限制用户，并要求在下一阶段补齐。是否继续由采购、业务、安全和风险责任人共同决定。

平台提供技术控制，企业负责测试身份、数据分级、工具权限、审批、事件响应和最终风险接受。测试供应商自己的默认环境，不能替代企业集成后的责任验证。

不要用真实敏感数据证明系统“安全”

测试数据应保留真实结构和权限差异，但使用合成、脱敏或专门构造的标识。若必须验证受控数据，应限制环境、人员、时间和导出，并得到相应批准。把真实高敏感内容放进未验证系统，会在POC阶段制造新的风险。

测试日志同样需要治理。攻击样本、Prompt和工具参数可能具有敏感性，不应广泛共享或长期留存。报告可以用场景ID、结果摘要和受控证据链接，原始材料由授权人员访问。

在 AI基础设施分类 可继续查看模型、知识库和算力平台内容。形成测试网格与复验条件后，可结合真实业务评估 AI解决方案 ，但不应把方案采购与安全顺利获得画等号。

下一步：把现有注入用例扩成一张证据表

保留已有提示注入测试，同时增加身份越权、知识跨域、工具权限、日志暴露和故障旁路场景。为每个场景写前置条件、期望控制、实际证据、影响面、处置和恢复。先在合成数据与非生产环境执行，修复后用变体回归。最终报告明确平台能力、企业依赖、限制试点条件和阻断项，避免一个“顺利获得”掩盖未覆盖风险。

常见问题

大模型安全POC需要使用真实敏感数据吗？

通常不需要，也不应作为首选。可以用合成文档、伪造身份、独特标识和受控工具模拟权限与泄露路径，既验证检索、缓存、输出和日志，又避免把真实数据暴露给尚未验证的系统。测试样本应覆盖结构、大小、权限和业务流程，而不必保留真实内容。

若某些控制只能在真实集成环境验证，应先完成批准、范围限制和备份回退，尽量使用低敏感或已脱敏数据，限制参与人员、网络和保留期限。报告中记录数据级别和处置结果。POC的目的不是用高风险数据“证明安全”，而是建立可重复的控制证据；引入真实数据必须有明确必要性与责任人。

一次攻击被拦截能否判定测试顺利获得？

不能。一次拦截可能来自关键词、模型随机输出、临时缓存或与预期不同的控制。需要重复测试、改变无关表述、使用允许/拒绝对照样本，并核对策略输入、模型版本、实际路由和审计回执。还要观察候选、工具和日志层是否已经发生暴露，而非只看最终回答。

顺利获得结论应限定场景、版本、身份和时间，至少证明预防或限制生效、异常可检测、影响可处置、状态可恢复。对于概率性模型内容，不能承诺零绕过；更应依靠身份、数据和工具的确定性控制缩小后果。版本或架构变化后，相关用例需要回归，并由责任人确认复验记录已经归档。

POC发现高风险缺口后还能继续采购评估吗？

可以继续评估，但相关场景不能被标记为顺利获得，更不能未经处置进入生产。先判断缺口是否可顺利获得关闭工具、使用合成数据、限制用户或隔离知识域收缩试点；同时要求给出修复方案、责任方、证据和复验时间。若存在无法限制的无权数据暴露、关键工具越权或静默旁路，应阻断受影响范围。

采购决策还要考虑缺口来自平台、集成配置还是企业制度，并明确谁负责修复。继续评估不等于接受风险，停止一个场景也不等于否定全部能力。最终由业务、采购、安全与风险责任人依据证据决定，并把限制条件写入后续验收，而非依赖口头承诺。