译自7 LLM Risks and API Management Strategies to Keep Data Safe，作者 Ash Osborne。
尽管围绕大型语言模型 (LLM)的热情激增，但任何新的基于云的软件解决方案都可能产生或暴露新的漏洞。让我们探讨 Open Web Application Security (OWASP) 项目发布的七种 LLM 漏洞，以及如何通过应用 API 管理安全来缓解这些风险。每节将详细介绍一个特定的漏洞，例如提示注入或不安全的输出处理，解释网络犯罪分子如何利用这些弱点，并提供实用的API 管理技术来防止这些威胁。
1. 提示注入
提示注入是指黑客能够通过伪装成合法提示的恶意提示，诱使 GenAI 模型做出意想不到的输出。在这种攻击中，如果我们不限制可以传递给 LLM 的提示，攻击者可以精心设计一个请求，导致意外结果。例如，一个聊天机器人，而不是帮助用户，开始侮辱他们。
为了缓解这种类型的攻击，开发人员应该实施传统的身份验证和访问控制，以确保只有授权用户可以与 LLM 交互。然后，在将请求发送到模型之前，应该执行提示检查 - 或者通过使用预处理器和后处理器来限制 LLM 可以做什么，或者通过使用模板来限制实际请求成为参数化形式。另一种选择是使用自训练的 LLM 或第三方服务来检查 LLM 请求和响应的内容安全。
2. 不安全的输出处理
通过盲目信任从 LLM 返回的响应，后端系统可能会无意中暴露，这可能导致跨站点脚本、跨站点请求伪造、服务器端请求伪造、权限提升或远程代码执行等问题。
对抗这种漏洞的第一步是实施提示范围，这将提示的范围限制在 LLM。响应也应该在返回给请求者之前进行审查，这可以像应用正则表达式模式一样简单，也可以像使用 LLM 本身来扫描内容以查找有害响应一样高级。
3. 模型拒绝服务
用请求过载 LLM 会导致服务质量下降或资源成本增加，这对任何组织来说都是最糟糕的结果。然而，在模型拒绝服务中，这就是风险所在。当攻击者对 LLM 造成资源密集型操作时，就会发生这种情况。这可能看起来像比正常情况更高的任务生成或重复的长输入，仅举几例。
身份验证和授权可用于防止未经授权的用户与 LLM 交互。每个用户的令牌数量的速率限制也应该用于阻止用户消耗组织的积分，导致高成本和使用大量计算导致延迟注入。
4. 敏感信息泄露
合规团队对敏感信息泄露的担忧可能是限制 LLM 采用的最严重漏洞之一。当模型无意中可以返回敏感信息时，就会发生这种情况，导致未经授权的数据访问、隐私侵犯和安全漏洞。
开发人员可以实施的一种技术是使用专门训练的 LLM 服务来识别并删除或混淆敏感数据。这也可以用于非 LLM 基于的用例。此外，可以指示 LLM不返回某些类型的数据，限制它们将如何响应。
5. 不安全的插件设计
如果访问控制不足且输入不安全，您将面临不安全的插件设计。当扩展在用户交互期间由模型自动调用时，就会发生这种情况。扩展由模型本身驱动，应用程序对执行没有控制权。通过利用这一点，攻击者可以构建一个恶意请求，导致各种不希望的行为。
为了缓解这种风险，通过授权和身份验证来限制谁以及什么可以访问底层 LLM。这通过限制对敏感操作的访问来降低被利用的风险。还应将清理和控制应用于提示请求，以限制在操作调用中可以执行的操作。
6. 过度代理
当授予过多的功能、权限或自主权时，LLM 系统可能会采取导致意外后果的行动。这是一个威胁，应通过可观察性和流量检查持续监控，以了解哪些内容与 LLM 交互以及如何使用它。还应使用授权和身份验证来实施严格的访问控制，以限制谁可以访问和与系统交互。对于更敏感的操作，需要更高的授权级别。
7. 过度依赖
过度依赖是另一个与授予使用 LLM 的用户或系统自主权有关的担忧。如果没有监督，由于模型生成的内容，可能会出现错误信息、误传甚至法律/安全问题。
解决方案：同样，应通过授权和身份验证实施访问控制，并对更敏感的操作进行限制。与过度代理监控类似，应实施对流经系统的流量的可观察性，使组织能够了解正在发生的交互。还应使用提示控制来限制与 LLM 的交互方式。
最终，LLM 是通过 API 调用访问的，应以与管理传统 API 流量相同的方式进行管理。生态系统中的纵深防御和可观察性是了解流量如何流经系统的关键。所有这些都可以通过具有专门集成以管理 AI API 流量细微差别的 AI 网关来实现。
