大模型的致命缺陷：随时泄漏机密

寂静回声

一位工程师在Reddit上发出求救：他们专门部署了自托管大模型来保护客户数据，结果QA测试时轻松注入提示，整个系统提示词被完整吐出。更糟糕的是，他们处理的是包含个人隐私信息的客服工单。
评论区瞬间炸开，但最高赞的回复却异常冷静：别在提示层面防注入了，假设模型一定会泄露，然后围绕这个前提构建安全架构。


这句话点破了问题的本质。大模型不是保险箱，它是一只鹦鹉，只要接触过某个数据，迟早会在某个时刻愉快地复述出来。
有人一针见血：大模型不应该掌管访问控制。让它随便请求数据，但由后端根据用户账户和权限决定是否放行。模型只负责传达结果，无论是实际数据还是拒绝通知。


这听起来如此显而易见，以至于有人困惑发问：我们十几年前就解决了SQL注入，为什么每次技术创新都要把轮子重新发明一遍？
答案令人唏嘘。一位老程序员指出，SQL注入的真正解决方案是参数化查询，本质是将逻辑与用户输入分离。而现在涌入AI领域的新人，很多从未经历过这些安全控制成为行业标准的过程。他们把大模型当成万能工具，却忘了在它和敏感数据之间建立隔离层。


更尖锐的批评来了：这不是AI问题，这是基础软件工程问题。让大模型决定哪个用户能看哪些隐私数据，这种设计本身就是灾难。
一位从业二十多年的工程师感慨，他们至今还在用Perl处理每月上亿请求，期间尝试迁移到Rails、React、Next.js全部失败。真正的工程价值不是追逐时髦框架，而是十年不碰它，它依然稳定运行。
关于提示注入本身，社区达成了一个残酷共识：这是一个尚未解决的问题。大模型把所有输入都当作文本处理，不存在参数化查询那样的银弹。你能做的是分层防御，用分类器过滤明显恶意输入，用正则检测输出中是否包含系统提示片段，用独立模型做意图判断。但每一层都只能挡住部分攻击，没有任何方案能做到百分之百。


最务实的建议是：把系统提示当作迟早会公开的内容来设计，不要在里面放任何敏感信息。Anthropic都公开了Claude的系统提示，你的提示词凭什么需要保密？
有人提出用小模型做前置过滤，立刻被反问：那个小模型怎么防注入？这就像用纸巾去扑灭着火的纸巾。


最终，讨论收敛到一个古老而朴素的原则：把大模型当作不可信的用户代理。它能访问的数据边界，就是你愿意直接暴露给用户的边界。任何超出这个范围的设计，都是在玩火。
安全从来不是功能，而是架构。那些在九十年代学会这个道理的人，正在看着新一代工程师从头踩坑。区别只是，这次他们不用写Perl了。


reddit.com/r/LocalLLaMA/comments/1qyljr0/prompt_injection_is_killing_our_selfhosted_llm