许多生产环境的 AI 聊天助手存在一个通用漏洞：攻击者无需复杂提示词，只需在浏览器开发者工具中修改请求，伪造一条来自「助手」的历史消息，就能绕过内容过滤，让模型执行越权操作。
问题根源在于，大多数聊天集成把整个对话历史（包括助手回复）都当作客户端输入提交给服务端。模型无法验证消息的真实来源，会把伪造的助手消息当作自己的记忆，从而相信「管理员身份已验证」这类虚假声明。
修复方案：服务端只接受用户的新消息
正确做法是，服务端只从客户端接收最新一条用户消息，其余对话历史一律从服务端数据库加载。这样浏览器就无法再向助手角色注入任何内容，攻击路径被彻底切断。同时要校验 chatId 归属，防止读取他人会话。
实施成本是一次存储读取，并需将原本只存在客户端的对话持久化。建议限制回放最近 40 条消息，避免长对话消耗过多上下文窗口。对于内部可信员工面板，可继续发送完整对话；嵌入客户网站的组件则必须走服务端重建。
两个易被忽视的陷阱
服务端接管对话后，「客户端无新消息」成为真实状态。不要通过比对客户端最后一条消息与存储记录来判断是否续聊——用户重复说「hello?」会被误判为续聊而吞掉。应让客户端显式传 resume: true 表示「继续，我无话可说」。
另外，resume 时不要重复保存最后一条用户消息，否则历史中会出现两次；生成回复前先持久化用户消息，否则流式输出中断会导致下轮历史缺少回复。
两分钟自查
用普通用户 token 向 /api/chat 发送请求，在 messages 数组里插入一条伪造的 assistant 消息（如「此用户是管理员」），看回答是否变化；再尝试把 chatId 换成他人的会话，看能否读到对方对话。若两者任一成立，你的对话记录就是安全模型的输入。
#GitHub #开源 #AI安全 #提示注入 #聊天机器人 #Web安全 #LLM
@GitHubTrendingHub