3 篇博文 含有标签「llm-security」

我最近接触的一个安全团队发现，他们的 prompt（提示词）和 response（响应）字段被完整地发送到了一个第三方 SaaS 日志后端，而他们从未与该厂商签署过《数据处理协议》（DPA）。这些字段包含客户的医疗摘要、支持人员误粘贴的 Stripe 私钥，以及某人要求内部助手总结的机密收购备忘录全文。Payload 中没有任何内容经过加密，也没有进行任何脱敏处理。数据保留期长达 400 天。这一集成是由一位初衷良好的工程师在黑客松期间通过 pip install 厂商的 SDK、填入 API 密钥后直接上线的。

这就是 AI 观测性泄露。每个 LLM 应用团队最终都会需要追踪（tracing）——没有它，你无法调试提示词回归或非确定性的智能体（agent）循环——因此 LangSmith、Langfuse、Helicone、Phoenix、Braintrust 或厂商提供的 AI 插件最终都会进入技术栈。默认设置会捕获整个请求和响应。对于大多数生产工作负载来说，这种默认设置就是一个等待被发现的合规性违规隐患。

一位创业公司的 CTO 某天早晨检查 OpenAI 后台，发现了一张 67,000 美元的账单。他们往常的月账单是 400 美元。产品层面没有任何变化 —— 没有爆火的发布，没有新功能，也没有营销活动。变化的是，攻击者识别了他们的端点指纹，从构建产物中获取了泄露的密钥，并将推理服务以低于零售价 40-60% 的价格转卖给那些支付加密货币的买家。创业公司付了账单，而攻击者赚取了差价。

这不是 SaaS 创始人互相传颂的典型免费层滥用故事。典型故事是：少数重度用户滥用了慷慨的试用，流失率飙升，你收紧限制，单位经济效益在一个季度内恢复。这套剧本在 AI 产品上已经过时了。当你针对匿名请求的单位成本不再实际上为零，且你的慷慨一旦可以被变现，这种数学模型就崩塌了。

提示注入是 OWASP LLM 应用十大漏洞之首，工程师对它的运作方式和攻击者实际利用方式的理解之间存在越来越大的鸿沟。2024 年的一项研究测试了 36 个生产环境中集成了 LLM 的应用程序，发现其中 31 个易受攻击。2025 年的一次红队测试发现，如果攻击者尝试的次数足够多，100% 已发布的提示防御措施都可以被绕过。

残酷的真相是：大多数团队首先采取的简单防御措施——仅靠系统提示警告、关键词过滤、输出净化——在面对尝试多种方法的攻击者时都会失效。有效的方法是架构性的：分离权限、隔离不受信任的数据，并根据 LLM 看到的内容来限制它实际能做的事情。

这篇文章是为构建生产系统的工程师准备的实战指南。没有 CTF 风格的玩具示例——只有导致真实事件的攻击模式和能显著降低风险的防御模式。