在采访中，诺丁汉大学副教授Michael Pound分享了他对与大型语言模型(LLM)相关的网络安全风险的见解。他讨论了CISO和安全团队在LLM使用方面存在的理解或准备上的最大差距，以及在将LLMs集成到业务运营中时保护敏感数据所需的预防措施。
你认为在LLM使用方面，CISO和安全团队在理解或准备上存在的最大差距是什么?
许多安全专业人员——相当合理地——对LLM背后的机器学习原理并不精通。对于过去的技术来说，这并不是什么大问题，但LLM表面上看起来如此强大，以至于可能会误导我们认为它们不会被欺骗。我们可能会急于构建考虑不周的系统，最终在实际应用中崩溃。或许最重要的是要记住，大多数GenAI，包括LLM，都是概率性的——它们的行为具有随机性，这意味着它们很有可能按你的意愿行事，但这个概率很少是100%。
推销AI解决方案的公司会谈论AI保障措施和一致性，以暗示他们已经以某种方式开发了这些模型，使它们不会出错，实际上，这仅仅意味着一家公司已经尝试训练LLM拒绝一系列他们自己设计的恶意提示，这降低了异常行为的可能性，但并未降至零。我们无法确定LLM是否会拒绝一个全新且未见过的提示，直到它真的发生，存在许多新奇且令人惊讶的方法来说服LLM做坏事。
企业在向LLM输入数据时最常见的错误是什么，尤其是在涉及敏感或专有信息时?
短期内，公司应确定谁在内部使用这些工具、使用哪些工具以及如何使用它们。许多最终用户并未意识到，他们输入到这些模型中的查询会被上传到云端，在某些服务上，这些查询可能会最终成为训练数据的一部分。很容易在不经意间上传机密客户或公司信息，而没有真正考虑后果。最近的模型拥有足够的参数来学习你的私人数据，并乐于将其发送给新用户。像处理电子邮件或日程安排的生产力应用，根据定义，可以访问这些信息。这些信息会流向哪里?这些工具的付费许可证通常具有更强的使用控制和协议——这些值得探索。
与历史上的SQL攻击类似，你必须非常小心不受控制的用户输入。在测试中，你可能会问LLM同一个问题100次，答案虽然不同但保持一致，然而，一旦发布，有人可能会以稍微不同的方式提问，或者更糟的是，可能会故意引导LLM进行恶意行为。对于传统代码，你可以控制这一点，可以指定“如果输入不符合这个精确格式，就拒绝它”，但对于LLM来说，很容易编写出绕过保障措施的有效提示。这个问题实际上比SQL严重得多。对于SQL注入，你可以构建输入净化、参数化查询等机制来防止滥用，但对于LLM来说，这几乎是不可能的。语言模型没有提示与它们正在使用的数据之间的概念区分，它们都是一样的。这也意味着用户上传的文档或其他文件可能是恶意提示的来源，而不仅仅是直接的文本输入。
如果LLM能够访问工具——与其他代码和API的连接，风险就会增加。如果LLM可以发起网络请求，就有可能通过markdown或其他URL泄露数据。如果LLM可以访问你的任何私人数据，那么风险就会增加。
目前，在降低LLM被对抗性输入操纵的风险方面，哪些防御或缓解措施最有效?
大多数尝试训练模型以避免恶意提示的努力，在一段时间后就会被人想出不同的策略来绕过保障措施。你的防御将取决于你希望LLM做什么。如果你希望用它来总结文档或检索数据，那么你需要仔细控制它可以读取的文档，以确保它们不包含恶意提示。
如果你的AI直接响应用户输入——例如你的客户，那么不可避免地，有人会在某个时候测试保障措施。你应该定期测试你的LLM，看看它们如何反应，你还可以使用其他功能来检测和剔除有问题的提示。在某些方面，SQL注入的原则仍然适用——最小权限原则和基于角色的访问控制。设置你的AI系统，以便即使LLM试图造成损害，也无法做到。
你推荐哪些框架或指南来安全地将LLM集成到业务工作流程中?
尽管我们似乎已经谈论LLM很长时间了，但它们实际上只有几年历史。系统是新的，流行的库经常变化。目前不错的选择包括Haystack、LangChain和Llama-Index。其中大多数都是基于运行你自己的本地模型的想法，如果你担心数据隐私，这特别有用。
最大的模型需要巨大的资源，但大多数适中的模型在标准硬件上表现出色。如果你想在本地测试模型，可以尝试Ollama。如果你想重新训练模型，这可以是一种非常有效地更精确控制输出的方式，可以看看Unsloth。像Copilot、ChatGPT和Anthropic Claude这样的商业产品也很可靠，但成本更高。
随着LLM越来越深入地集成到基础设施中，我们可以预期哪些长期或系统性的网络安全问题?
我们正处于一个将LLM嵌入越来越多系统的时代，而人们还不习惯这些模型与正常软件开发的不同之处。想象一下编写一段有时根本不起作用或输出意外结果的代码。即使是一个几乎完美的LLM，在99.999%的情况下都是正确的，从数学上讲，每1000次调用中也会失败一次。我们需要彻底重新思考如何构建软件，以确保不稳定的LLM可以在稳定的系统中使用。就像我们花了数年时间来填补SQL注入的漏洞一样，最近在2015年还发生了重大泄露事件，我们将长期听到意外提示导致LLM以灾难性方式出错的故事。
