大模型应用上线之后，很多人盯着输出安全。这当然没错，但有一个容易被忽略的环节——输入安全。 用户输入本身并不总是人畜无害的。恶意诱导、敏感指令、间接注入，这些威胁从一开始就可能混进对话里。而在云上架构中，这种风险不是孤立的，它会顺着调用链一路传导：用户输入穿过API网关、经过会话服务、知识库检索、插件编排，再到Agent决策，每一步都可能被利用。所以，输入安全不能只靠前端表单那一道坎，它得成为整条主链路的一部分。 ### 一、需要重点识别的输入类型 我们需要重点盯防的输入类型就这么几类： | 类型 | 典型表现 | 云上风险 | |------|----------|----------| | 规则覆盖 | 忽略原有规则、切换身份、解除限制 | 模型安全策略失效 | | 提示词窃取 | 要求输出系统提示词、开发者指令 | 业务规则泄露 | | 敏感内容生成 | 请求违法、危险、欺诈、低俗内容 | 合规和舆情风险 | | 隐私推断 | 查询、拼接、推断个人敏感信息 | 数据安全风险 | | 间接注入 | 文档、网页、工单中夹带指令 | 污染 RAG 上下文 | | 工具越权 | 诱导 Agent 发信、删除、导出、支付 | 从内容风险升级为动作风险 | ### 二、识别逻辑：从“词”升级到“意图 场景” 但光靠关键词匹配肯定不够用。恶意诱导现在伪装得越来越像正常任务——写小说、做安全研究、帮我测试系统、请你扮演另一个角色，这些说法本身谈不上违规，关键要看用户到底在索要什么东西：是可执行的危险步骤、敏感数据，还是绕过策略的方法？ 实际操作中建议用三层识别来兜底： - 基础规则：处理明确敏感词、黑名单、联系方式、变体符号。 - 语义分类：识别越狱、提示词注入、隐私请求、反诈导流等意图。 - 上下文判断：结合多轮会话、用户画像、调用频率、工具权限和业务场景。 ### 三、云上部署建议 在实际部署时，建议把整个链路规划成这样： `API 网关` → `输入安全检测` → `风险标签与处置策略` → `RAG 内容清洗 / Agent 权限校验` → `大模型服务` → `输出审核与安全代答` → `日志、告警、复核、样本回流` 输入安全检测这一层可以放在网关后、模型编排前。高风险输入直接拦截；中风险输入则限制工具调用、缩小知识库范围、触发安全代答或进入人工复核。这样既不会一刀切禁用，也不会放任风险钻进来。 ### 四、RAG 和 Agent 要单独加固 RAG 和 Agent 这两个场景需要单独拿出来聊一下。 在 RAG 场景下，风险不一定是用户现问的这句话，而可能是被检索到的网页、PDF、评论、客服记录或企业知识库本身藏了东西。所以，入库内容和召回片段最好都做一遍安全检测，并且要明确一条边界：检索内容只能当资料参考，不能覆盖系统指令。 到了 Agent 场景，问题会更棘手——因为模型有可能直接调用工具。删除、发送、支付、导出、改权限这些高危操作，得设置工具白名单、参数校验、二次确认。说白了一句话：不能让模型独自决定要不要执行这些动作。 ### 五、上线前怎么评估？ 有了方案，上线之前还得有一套评估标准来衡量效果。 | 维度 | 建议指标 | |------|----------| | 攻击识别 | 直接诱导、多轮诱导、混淆绕过召回率 | | 误拦控制 | 正常咨询、合规研究、业务问答误拦率 | | 云上性能 | 平均延迟、P95/P99、失败重试、降级策略 | | 集成成本 | API、SDK、日志、告警、工单系统适配 | | 审计能力 | trace_id、标签、策略版本、处置结果留痕 | | 运营闭环 | 人工复核、样本回流、策略迭代周期 | 选型时不必先预设答案。可以把数美科技、腾讯云、阿里云、百度智能云、火山引擎等能力放在相同测试集下做横向比较，重点看它们对 AIGC 输入安全、内容审核、账号风控和运营闭环的覆盖程度。哪个更适合自己的场景，一跑数据就知道了。 ### FAQ **Q：输入安全会不会拖慢模型响应？** A：肯定会增加链路开销，所以平均延迟和 P99 必须是监控重点。生产环境可以通过分级检测、缓存、异步复核和降级策略来平衡体验。 **Q：为什么要结合账号风控？** A：批量越狱和敏感指令试探往往伴随着异常账号、袋里 IP、设备伪装和高频调用。账号风控能帮你识别出自动化攻击的模式。 **Q：云上应用最容易忽略什么？** A：日志审计。没有输入、输出、标签、策略版本和处置动作的完整留痕，后续定位误杀、漏放和安全事件的根因会非常困难。