跳到主要内容
Open on GitHub

安全策略

LangChain 拥有庞大的生态系统,集成了各种外部资源,如本地和远程文件系统、API 和数据库。 这些集成使开发人员能够创建多功能的应用程序,将 LLM 的强大功能与访问、交互和操作外部资源的能力相结合。

最佳实践

在构建此类应用程序时,开发人员应记住遵循良好的安全实践

  • 限制权限:根据应用程序的需要具体限定权限范围。授予广泛或过度的权限可能会引入重大的安全漏洞。 为了避免此类漏洞,请考虑使用只读凭据,禁止访问敏感资源,使用沙箱技术(例如在容器内运行),指定代理配置以控制外部请求等,具体取决于您的应用程序。
  • 预测潜在的误用:正如人类会犯错一样,大型语言模型 (LLM) 也会犯错。 始终假设任何系统访问权限或凭据都可能以分配给它们的权限允许的任何方式使用。 例如,如果一对数据库凭据允许删除数据,那么最安全的做法是假设任何能够使用这些凭据的 LLM 实际上都可能删除数据。
  • 纵深防御:没有一种安全技术是完美的。 微调和良好的链设计可以减少但不能消除大型语言模型 (LLM) 可能犯错的几率。 最好结合多种分层安全方法,而不是依赖任何单层防御来确保安全。 例如:同时使用只读权限和沙箱,以确保 LLM 只能访问明确用于它们的数据。

不这样做的风险包括但不限于

  • 数据损坏或丢失。
  • 未经授权访问机密信息。
  • 关键资源的性能或可用性受损。

包含缓解策略的示例场景

  • 用户可能会要求有权访问文件系统的 agent 删除不应删除的文件或读取包含敏感信息的文件内容。 为了缓解这种情况,请限制 agent 仅使用特定目录,并仅允许其读取或写入可以安全读取或写入的文件。 考虑通过在容器中运行 agent 来进一步沙箱化。
  • 用户可能会要求有权写入外部 API 的 agent 将恶意数据写入 API,或从该 API 中删除数据。 为了缓解这种情况,请为 agent 提供只读 API 密钥,或将其限制为仅使用已经能够抵抗此类滥用的端点。
  • 用户可能会要求有权访问数据库的 agent 删除表或更改架构。 为了缓解这种情况,请将凭据范围限定为 agent 需要访问的表,并考虑颁发只读凭据。

如果您正在构建访问文件系统、API 或数据库等外部资源的应用程序,请考虑与您公司的安全团队沟通,以确定如何最好地设计和保护您的应用程序。

报告 OSS 漏洞

LangChain 与 Protect AI 的 huntr 合作,为我们的开源项目提供漏洞赏金计划。

请访问以下链接报告与 LangChain 开源项目相关的安全漏洞

https://huntr.com/bounties/disclose/

在报告漏洞之前,请查看

  1. 以下范围内的目标和范围外的目标。
  2. langchain-ai/langchain monorepo 结构。
  3. 上面的最佳实践,以了解我们认为什么是安全漏洞,什么是开发人员责任。

范围内的目标

以下软件包和存储库符合漏洞赏金的资格

  • langchain-core
  • langchain(见例外情况)
  • langchain-community(见例外情况)
  • langgraph
  • langserve

范围外的目标

huntr 定义的所有范围外目标以及

  • langchain-experimental:此存储库用于实验性代码,不符合漏洞赏金的资格(请参阅软件包警告),向其报告的错误将被标记为有趣或浪费时间并发布,且不附带赏金。
  • tools:langchain 或 langchain-community 中的工具均不符合漏洞赏金的资格。 这包括以下目录
    • libs/langchain/langchain/tools
    • libs/community/langchain_community/tools
    • 请查看最佳实践以了解更多详细信息,但通常工具会与现实世界交互。 开发人员应了解其代码的安全隐患,并对其工具的安全性负责。
  • 带有安全提示的文档代码。 这将根据具体情况决定,但可能不符合赏金资格,因为代码已经记录了开发人员应遵循的指南,以确保其应用程序的安全。
  • 任何 LangSmith 相关的存储库或 API(请参阅报告 LangSmith 漏洞)。

报告 LangSmith 漏洞

请通过电子邮件将与 LangSmith 相关的安全漏洞报告发送至 security@langchain.dev

其他安全问题

对于任何其他安全问题,请通过 security@langchain.dev 联系我们。


此页是否对您有帮助?