Skip to main content
Open on GitHub

安全策略

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

最佳实践​

在构建此类应用程序时，开发者应牢记遵循良好的安全实践：

  • 限制权限: 将权限范围具体限定在应用程序的实际需求上。授予过宽或过度的权限可能会引入严重的安全漏洞。为避免此类漏洞，可根据应用程序的实际情况考虑使用只读凭据、禁止访问敏感资源、采用沙箱技术（例如在容器中运行）、指定代理配置以控制外部请求等措施。
  • 预判潜在滥用风险：正如人类可能犯错，大型语言模型（LLM）也可能出错。应始终假设任何系统访问权限或凭据都可能被用于其分配权限所允许的任何方式。例如，如果一组数据库凭据允许删除数据，那么最安全的做法是假设任何能够使用这些凭据的 LLM 实际上都可能删除数据。
  • 纵深防御：没有任何安全技术是完美的。微调（Fine-tuning）和优秀的链设计可以减少，但无法完全消除大型语言模型（LLM）出错的可能性。最佳实践是结合多种分层的安全方法，而不是依赖单一防御层来确保安全。例如：同时使用只读权限和沙箱技术，确保 LLM 只能访问明确授权给它使用的数据。

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

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

带有缓解策略的示例场景：

  • 用户可能会要求拥有文件系统访问权限的代理删除不应被删除的文件，或读取包含敏感信息的文件内容。为缓解此风险，应将代理限制为仅使用特定目录，并仅允许其读取或写入安全的文件。此外，可考虑通过在容器中运行代理来进一步增强沙箱隔离。
  • 用户可能会要求具有外部 API 写入权限的智能体将恶意数据写入该 API，或从该 API 中删除数据。为缓解此类风险，请仅向智能体提供只读的 API 密钥，或限制其仅使用已具备抗滥用能力的端点。
  • 用户可能会要求拥有数据库访问权限的智能体删除表或修改架构。为降低风险，应将凭据的权限范围限制在智能体需要访问的特定表上，并考虑颁发只读（READ-ONLY）凭据。

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

报告 OSS 漏洞​

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

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

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

在报告漏洞之前，请先查阅：

  1. 目标范围内与目标范围外内容如下。
  2. The langchain-ai/langchain 单体仓库结构。
  3. 上述的 最佳实践 有助于理解我们如何界定安全漏洞与开发者责任。

目标范围​

以下软件包和仓库符合漏洞悬赏资格：

  • langchain-core
  • langchain（参见例外情况）
  • langchain-community（参见异常）
  • LangGraph
  • LangServe

超出范围的目标​

所有由 huntr 定义的超出范围的目标以及：

  • langchain-experimental: 此仓库用于实验性代码，不符合漏洞赏金资格（请参阅包警告），针对它的错误报告将被标记为“有趣”或“浪费时间”，并发布且不附带任何赏金。
  • 工具: langchain 或 langchain-community 中的工具不符合漏洞赏金奖励资格。这包括以下目录
    • libs/langchain/langchain/tools
    • libs/community/langchain_community/tools
    • 请查看最佳实践以获取更详细信息，但通常工具与现实世界交互。开发者应理解其代码的安全影响，并对其工具的安全性负责。
  • 代码已包含安全注意事项。这将根据具体情况决定，但很可能不符合领取奖金的条件，因为该代码已为开发者提供了应遵循的安全指南，以确保其应用程序的安全性。
  • 任何与 LangSmith 相关的存储库或 API（请参阅 报告 LangSmith 漏洞）。

报告 LangSmith 漏洞​

请通过电子邮件向 security@langchain.dev 报告与 LangSmith 相关的安全漏洞。

其他安全顾虑​

如有其他安全方面的顾虑，请通过 security@langchain.dev 联系我们。