LLMs-隐藏的安全风险

LLMs 隐藏的安全风险

原文：https://towardsdatascience.com/the-hidden-security-risks-of-llms/

当公司急忙将大型语言模型（LLMs）集成到客户服务代理、内部副驾驶和代码生成助手时，出现了一个盲点：安全。虽然我们关注 AI 的持续技术进步和炒作，但潜在的风险和漏洞往往被忽视。我发现许多公司在安全方面存在双重标准。OnPrem IT 设置受到严格的审查，但使用 Azure OpenAI studio 或 Google Gemini 等云 AI 服务的点击速度却很快。

我知道围绕托管 LLM API 构建包装解决方案有多容易，但这真的是企业用例的正确选择吗？如果您的 AI 代理将公司机密泄露给 OpenAI 或被巧妙措辞的提示所劫持，那不是创新，而是即将发生的违规行为。仅仅因为我们没有直接面对利用这些外部 API 时实际模型所涉及的安全选择，并不意味着我们可以忘记那些模型背后的公司为我们做出了这些选择。

在这篇文章中，我想探讨隐藏的风险，并论证一个更注重安全的路径：自托管 LLMs 和适当的风险缓解策略。

LLMs 默认并不安全

一个 LLM 听起来输出非常智能，并不意味着它们天生就安全地集成到您的系统中。一项由 Yoao 等人进行的研究探讨了 LLMs 在安全中的双重角色 [1]。虽然 LLMs 开辟了许多可能性，有时甚至有助于安全实践，但它们也引入了新的漏洞和攻击途径。标准的网络安全实践仍需要发展，以便能够跟上由 AI 解决方案创造的新攻击面。

让我们看看在处理 LLMs 时需要解决的一些重要安全风险。

数据泄露

数据泄露发生在敏感信息（如客户数据或 IP）在模型训练或推理过程中无意中被暴露、访问或误用时。到 2025 年，平均数据泄露成本达到 500 万美元 [2]，33%的员工定期与 AI 工具共享敏感数据 [3]，数据泄露构成了一个非常真实的风险，应该被认真对待。

即使那些第三方 LLM 公司承诺不会在您的数据上训练，也很难验证下游记录、缓存或存储的内容。这使得公司在 GDPR 和 HIPAA 合规性方面几乎无法控制。

提示注入

攻击者不需要对你的 AI 系统有 root 访问权限就能造成损害。一个简单的聊天界面就已经提供了足够的机会。提示注入是一种黑客通过欺骗 LLM 提供非预期输出或执行非预期命令的方法。OWASP 将提示注入列为 LLM 的第一大安全风险[4]。

一个示例场景：

一个用户使用 LLM 来总结包含隐藏指令的网页，这些指令导致 LLM 向攻击者泄露聊天信息。

你的 LLM 拥有越多权限，遭受提示注入攻击的漏洞就越大[5]。

不透明的供应链

LLM 如 GPT-4、Claude 和 Gemini 是闭源的。因此，你不会知道：

• 它们训练所使用的数据

• 上次更新时间

• 它们对零日漏洞的脆弱性

在生产中使用它们会在你的安全中引入盲点。

Slopsquatting

随着越来越多的 LLM 被用作编码助手，一种新的安全威胁已经出现：slopsquatting。你可能熟悉typesquatting这个术语，其中黑客利用代码或 URL 中的常见错误来创建攻击。在 slopsquatting 中，黑客不依赖于人类错误，而是依赖于 LLM 的虚构。

当生成代码片段时，LLM 往往会虚构不存在的包，如果这些片段在没有适当检查的情况下被使用，这为黑客提供了感染你的系统以恶意软件等的机会[6]。通常，这些虚构的包听起来与真实包非常相似，这使得人类更难发现错误。

适当的缓解策略有帮助

我知道大多数大型语言模型（LLM）看起来非常聪明，但它们并不理解正常用户交互和巧妙伪装的攻击之间的区别。依赖它们来自动检测攻击就像要求自动补全功能来设置你的防火墙规则一样。这就是为什么拥有适当的流程和工具来减轻基于 LLM 系统的风险是如此重要的原因。

第一道防线的缓解策略

在与 LLM 合作时，有方法可以降低风险：

• 输入/输出清理（如正则表达式过滤器）。就像它在前端开发中证明的重要性一样，在 AI 系统中也不应该被忽视。

• 具有严格边界的系统提示。虽然系统提示不是万能的，但它们可以帮助设定良好的边界基础。

• 使用 AI 护栏框架来防止恶意使用并强制执行你的使用策略。例如，Guardrails AI 框架使设置此类保护变得简单[7]。

最后，这些缓解策略只是第一道防线。如果你使用第三方托管的 LLM，你仍然会将数据发送到你的安全环境之外，并且你仍然依赖于这些 LLM 公司适当地处理安全漏洞。

自主托管你的 LLM 以获得更多控制

有许多强大的开源替代方案，您可以在自己的环境中，按照自己的条件运行。最近的进步甚至导致了可以在适度基础设施上运行的性能良好的语言模型 [8]！考虑开源模型不仅仅是关于成本或定制（这可以说是很好的额外奖励）。这是关于控制。

自托管为您提供：

• 完整的数据所有权，没有任何东西离开您选择的环境！

• 使用私有数据进行定制微调的可能性，这允许针对您的用例提供更好的性能。

• 严格的网络隔离和运行时沙箱

• 可审计性。您知道您正在使用哪个模型版本，以及何时进行了更改。

是的，这需要更多的努力：编排（例如 BentoML、Ray Serve）、监控、扩展。我并不是说自托管是解决所有问题的答案。然而，当我们谈论处理敏感数据的用例时，这种权衡是值得的。

将 GenAI 系统视为您攻击面的一部分

如果您的聊天机器人可以做出决策、访问文档或调用 API，那么它实际上是一个未经审查的外部顾问，可以访问您的系统。因此，从安全的角度来看，要类似对待：管理访问、仔细监控，不要将敏感工作外包给他们。将重要的 AI 系统保留在内部，置于您的控制之下。

参考文献

[1] Y. Yoao 等人，《关于大型语言模型（LLM）安全和隐私的调查：好、坏、丑（2024）》(https://www.sciencedirect.com/science/article/pii/S266729522400014X)，ScienceDirect

[2] Y. Mulayam，《数据泄露预测 2025：成本与关键网络安全风险》(https://certbar.com/leadership-insights/data-breach-forecast-2025) (2025)，Certbar

[3] S. Dobrontei 和 J. Nurse，《哦，行为！2024-2025 年度网络安全态度和行为报告 — CybSafe》(https://www.cybsafe.com/whitepapers/oh-behave-the-annual-cybersecurity-attitudes-and-behaviors-report-24-25/) (2025)，Cybsafe 和国家网络安全联盟

[4] 2025 年 LLM 和 Gen AI 应用的前 10 大风险与缓解措施 (2025)，OWASP

[5] K. Greshake 等人，《并非你所期望的：通过间接提示注入损害现实世界 LLM 集成应用》(https://dl.acm.org/doi/10.1145/3605764.3623985)(2023)，计算机制造协会

[6] J. Spracklen 等人，《我们有一套方案！通过代码生成 LLM 进行的包装幻觉的全面分析》(https://www.usenix.org/conference/usenixsecurity25/presentation/spracklen)(2025)，USENIX 2025

[7] Guardrails AI，GitHub — guardrails-ai/guardrails: 为大型语言模型添加护栏。

[8] E. Shittu，《谷歌的 Gemma 3 可在单个 TPU 或 GPU 上运行》(https://www.techtarget.com/searchenterpriseai/news/366620654/Google-Gemma-3-can-run-on-a-single-TPU-or-GPU) (2025)，TechTarget