跳至主要内容

安全

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

最佳实践

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

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

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

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

带有缓解策略的示例场景

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

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

报告漏洞

请通过电子邮件向 [email protected]. 报告安全漏洞。这将确保及时对问题进行分类并根据需要采取措施。


此页面是否有帮助?


您也可以在 GitHub 上留下详细的反馈 在 GitHub 上.