大型语言模型（LLM）为几乎所有处理文本的应用程序提供了广泛而强大的增强功能。然而，它们也引入了新的风险，包括：

• Prompt注入，可能使攻击者控制LLM或启用LLM应用程序输出。
• 信息泄漏，用于训练或运行LLM时使用的私人数据可以被攻击者推断或提取。
• LLM的可靠性，在偶然情况下LLM会出现错误信息。

本文详细介绍了这些安全漏洞，并概述了设计或评估安全的LLM-enabled应用程序的最佳实践。

Prompt注入

Prompt注入是最常见和众所周知的LLM攻击。它使攻击者能够控制LLM的输出，从而可能影响与LLM连接的下游查询和插件的行为。这可能会对后续用户产生额外的下游影响或响应。 Prompt注入攻击可以是直接的或间接的。

直接Prompt注入

在直接Prompt注入攻击的情况下，攻击者直接与LLM交互，试图使LLM产生特定的响应。图1显示了直接Prompt注入导致远程代码执行的示例。

间接Prompt注入

间接Prompt注入依赖于LLM能够访问外部数据源，LLM在构建查询系统时会使用这些外部数据源。攻击者可以将恶意内容插入到这些外部数据源中，LLM会将其摄取并插入到提示中，以产生攻击者期望的响应。

信任边界

在直接和间接Prompt注入的情况下，一旦攻击者成功将其输入引入LLM的上下文，他们将对LLM的输出具有重大影响（即使不是完全控制）。由于LLM可能使用的外部源非常难以控制，并且LLM用户本身可能是恶意的，因此将LLM的任何响应视为潜在的不可信是非常重要的。

必须在这些响应和处理它们的任何响应之间建立信任边界。下面列出了一些执行此分离的实用步骤。

对插件进行参数化。严格限制给定插件可以执行的操作数量。例如，操作用户电子邮件的插件可能需要一个消息ID，一个特定的操作（例如“回复”或“转发”），或只接受要插入到电子邮件正文中的自由格式文本。

在使用插件之前对其进行输入清理。例如，电子邮件正文文本可能在插入之前强制删除任何HTML元素。或者转发电子邮件操作可能要求收件人在用户的通讯录中存在。

当插件操作敏感系统时，向用户请求显式授权。任何此类操作都应立即重新请求用户进行显式授权，以执行操作，并提供即将执行的操作的摘要。

当调用多个插件时，需要从用户那里请求特定授权。这种模式允许将一个插件的输出传递给另一个插件，可能迅速导致出乎意料甚至危险的行为。允许用户检查并验证调用的插件及其将采取的操作可以帮助减轻这个问题。

认真管理插件的授权。将任何服务帐户与LLM服务帐户分开。如果插件操作需要用户授权，则授权应使用安全方法（如OAuth2）委派给插件。

信息泄漏

LLM和LLM-enabled应用程序的信息泄漏会产生机密性风险。如果LLM在私人数据上进行了训练或定制，则技术娴熟的攻击者可以执行模型逆推或训练数据提取攻击以访问应用程序开发人员视为私人的数据。

在记录提示和完成时，可能会违反服务端基于角色的数据访问控制，从而意外泄漏数据。如果LLM本身可以访问信息或存储日志，则往往可以诱使其泄漏这些数据。

LLM 本身的泄漏

LLM自身也可以通过几种方式向攻击者泄漏信息。使用提示提取攻击，攻击者可以使用Prompt注入技术，诱使LLM泄漏其提示模板中包含的信息，如模型说明、模型个人信息，甚至密码等秘密。

通过模型逆推攻击，攻击者可以恢复用于训练模型的一些数据。根据攻击的详细情况，这些记录可能会随机恢复，或者攻击者可以使搜索偏向于他们认为可能存在的特定记录。例如，他们可能能够提取在训练LLM时使用的个人可识别信息（PII）的示例。

最后，训练数据成员推理攻击使攻击者能够确定他们已知的特定信息是否可能包含在模型的训练数据中。例如，他们可能能够确定他们的特定PII是否用于训练LLM。

幸运的是，这些攻击的缓解措施相对比较简单。

为了避免提示提取攻击的风险，在系统提示模板中不要共享当前LLM用户未经授权可以查看的任何信息。这可能包括从检索增强生成（RAG）架构中检索的信息。假设任何包含在提示模板中的信息都可以被足够有动机的攻击者看到。特别是，密码、访问令牌或API密钥不应放置在提示中，也不应放置在其他直接可访问LLM的位置上。严格对信息进行隔离是最好的防御。

为了减少从模型中提取敏感培训数据的风险，最好的方法是根本不要在模型上进行训练。如果LLM必须能够使用或回答关于敏感信息的问题，RAG架构可能是一种更安全的方法。

在这种架构中，LLM不会在敏感文档上进行训练，但会访问一个能够识别并返回相关敏感文档以协助生成的文档存储库，并验证当前用户对访问这些文档的授权。

虽然这样可以避免训练LLM并产生可接受的结果所需的敏感数据，但在传达授权和跟踪文档权限方面，这会给应用程序引入额外的复杂性。必须仔细处理，以防止其他机密性违规。

如果敏感数据已经训练到模型中，则通过限制查询速率、不向最终用户提供关于LLM完成的详细信息，并向应用程序添加日志记录和警报，仍然可以在一定程度上减轻风险。

将查询预算限制为与LLM启用应用程序功能一致的最低值，并不向最终用户提供任何详细的概率信息，使逆推和推理攻击变得极为困难和耗时。

与AI红队合作，评估数据泄漏可能有助于量化风险，为特定应用程序设置适当的速率限制，并识别用户会话中的查询或查询模式，可能表明有试图提取训练数据的举动，并应进行警报。

与应用程序相关的泄漏

除了LLM特定的攻击外，LLM的新颖性可能导致构建LLM启用应用程序时出现更基本的错误。记录提示和响应往往会导致服务端信息泄漏。无论是未经适当教育的用户将专有或敏感信息引入应用程序，还是LLM基于包含敏感信息的响应进行了记录，而没有适当的访问控制。

在图2中，用户向一个RAG系统发出请求，该系统代表用户请求只有用户本人有权访问的文档。不幸的是，请求和响应（包含与特权文档相关的信息）被记录在具有不同访问级别的系统中，从而泄漏信息。

如果正在使用RAG来改进LLM的响应，请与授权用户有关的追踪文档的授权，并在响应被记录的地方进行追踪。LLM只能访问当前用户有权访问的文档。这些完成（根据设计包含了某些访问受控文档中的信息）应以无法被未经授权的用户看到的方式进行记录。

因此，非常重要的是认证和授权机制在LLM的上下文之外执行。如果依赖将用户上下文作为提示的一部分传输，足够熟练的攻击者可以使用提示注入来冒充其他用户。

最后，应仔细审查任何插件的行为，以确保它们不会维护任何可能导致跨用户信息泄漏的状态。例如，如果搜索插件恰好缓存查询，则它返回信息的速度可能会使攻击者推断其他应用程序用户最常查询的主题。

LLM可靠性

尽管LLM生成的可靠性和准确性有了显著改进，但它们仍然会受到一定程度的随机错误的影响。从可能的下一个单词集中随机抽样单词会增加LLM的“创造力”，但也会增加其产生错误结果的机会。

这有可能影响用户，他们可能会根据不准确的信息采取行动，以及下游流程、插件或其他计算，这些计算可能会基于不准确的输入失败或产生其他不准确的结果（图3）。

下游流程和插件必须考虑LLM错误的可能性。与Prompt注入一样，良好的安全设计，包括插件的参数化、输入的净化、强大的错误处理和在执行敏感操作时明确请求用户授权等途径，有助于缓解与LLM相关的风险。

此外，确保任何LLM编排层可以在无效请求或LLM生成发生时提前终止并通知用户。这有助于避免在调用插件的序列中复合错误。如果标识到坏数据时采用失败关闭的标准做法。

对LLM驱动应用程序的范围、可靠性和适用性进行用户教育是重要的。用户应被提醒，LLM-enabled应用程序旨在补充而不是取代他们的技能、知识和创造力。对于任何结果的使用，无论是LLM产生的还是其他方式产生的，最终的责任属于用户。

结论

LLMs可以为用户和部署它们的组织提供重大价值。然而，与任何新技术一样，它们也带来了新的安全风险。Prompt注入技术是最广为人知的风险，任何应用程序，包括LLM在内，都应针对这一风险进行设计。

不太熟悉的安全风险包括LLMs可能引发的各种形式的信息泄露，这需要仔细追踪数据流和管理授权。LLMs的偶发性不可靠性也必须考虑，无论是从用户的可靠性角度还是从应用程序的角度来看。

使应用程序能够抵御自然和恶意错误可以增加其安全性。通过考虑本文中概述的风险，并应用所描述的缓解策略和最佳实践，您可以减少对这些风险的暴露，并确保成功部署。