Marico's space

最近在给团队的项目加 LLM（大型语言模型）能力，踩了几个坑之后才意识到这事比想象中复杂。LLM 应用不是简单的"传统 Web 应用加个 API 调用"那么简单——当模型直接嵌到请求处理逻辑里，攻击面完全变了。最大的坑在于：模型根本分不清"系统指令"和"攻击者输入的内容"。

这篇整理了六个风险域、共 16 项在生产环境前必须搞定的安全控制措施。

为什么威胁模型不一样

传统 Web 应用里，执行指令的是你的代码——代码不会把用户输入误当成控制流，除非你之前就埋下了注入漏洞这种雷。但到了 LLM 这里，上下文窗口里的每段文本都会被当作 token 处理。系统提示词、用户消息、检索回来的文档、工具输出——在模型眼里全都是一个样。

这就意味着不可信输入能到达原本被保护的地方。知识库里检索出的文档可能夹带了攻击者控制的内容，这些内容可以操控模型行为；用户消息可能试图覆盖系统级指令。因为模型的设计目标就是"提供帮助、听从指令"，天生就容易被这类滥用手段影响。

核心假设：模型读取的所有内容都可能是不可信的，它输出的所有内容在传递到任何地方之前都必须校验。

六大风险域和 16 项控制措施

信任边界

这三项控制措施把模型当作交易两端都不受信的组件：

• 把模型的所有输出当作不可信输入处理——无论下游是浏览器、数据库还是解释器
• 使用消息角色（system、user、assistant）从结构上把指令和用户内容隔开
• 把检索来的或第三方内容当作不可信的，哪怕你控制着检索层

输入输出校验

模型不会产生确定性输出，不能假设格式或内容始终安全：

• 在处理模型输出前，严格按 schema 校验
• 对模型能引用的动作、URL、标识符强制执行白名单
• 用 JSON 模式或结构化输出约束模型能返回的内容

数据泄露与隐私

发给模型提供商的任何内容都会离开你的基础设施。这和大多数应用面临的数据边界问题性质不同：

• 尽量减少发给提供商的敏感数据；个人信息（PII）和密钥在进入上下文前先脱敏
• 处理受监管数据前，确认提供商的数据保留和训练 opt-out 设置
• 包含个人或敏感信息的完整 prompt 和响应不要记日志

访问控制与过度授权

给模型提供工具或 API 访问权限的代理应用会引入所谓"糊涂中间人"问题：模型用应用级权限而非用户级权限行动。后果可以预见。

• 对模型检索的所有数据和能触发的所有动作强制执行用户权限校验
• 工具定义要收窄范围——模型只能做请求用户被授权做的事
• 高影响或不可逆操作执行前必须有人明确确认

滥用与成本控制

AI 接口贵得要命，而且是被滥用的好目标。"钱包拒绝服务"是真实存在的攻击——别人的 AI 预算可能变成你的责任：

• 所有面向 AI 的端点和敏感 API 一样要鉴权和限流
• 设置每个用户的 token 和输出上限，服务端强制执行，不能只靠客户端
• 加超时和熔断，防止推理成本失控引发连锁反应

监控

监控往往是团队最后才做的，但它对检测不触发校验错误的攻击必不可少：

• 在防篡改、可查询的存储里记录工具调用和高风险模型动作
• 持续监控模型行为、输出模式、支出的异常情况

容易被漏掉的盲区

系统提示词保密不是安全控制。提示词经常可以通过直接指令或间接探测恢复。永远不要把密钥、凭证或安全关键逻辑放在系统提示词里——授权必须放在你的应用代码里，不是在模型的上下文里。

提供商的数据治理取决于套餐档次。大厂企业版有数据保留控制，消费版或免费版 API 通常没有。如果你在处理个人数据或合规要求相关信息，在合同里核实数据处理条款，在构建之前，不是之后。

糊涂中间人问题会随着代理范围扩大而加剧。模型能发消息、写数据库、调外部 API 或执行其他持久化操作的应用，当访问权限按应用级而非用户级划分时，风险高得多。你给模型的工具箱里每加一个工具，都值得问一个直接的问题：如果攻击者操控模型用这个能力危害用户利益，会发生什么？

贯穿这 16 项控制措施的原则：把模型当作一个轻信的、不确定性的组件——校验它读入和输出的所有内容，在你自己的代码里强制执行授权和消费限制，永远不要给它超过它所代表用户的权限。