跳至主要内容

安全

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

最佳实践

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

  • 限制权限:将权限范围限定在应用程序的需求范围内。授予广泛或过多的权限可能会引入重大的安全漏洞。为了避免此类漏洞,请考虑使用只读凭据,拒绝访问敏感资源,使用沙箱技术(例如在容器内运行)等,这些技术适用于您的应用程序。
  • 预测潜在的误用:就像人类会犯错一样,大型语言模型 (LLM) 也会犯错。始终假设任何系统访问或凭据都可能以其分配的权限允许的任何方式使用。例如,如果一对数据库凭据允许删除数据,那么最安全的方法是假设任何能够使用这些凭据的 LLM 实际上都可能删除数据。

  • 纵深防御:没有哪种安全技术是完美的。微调和良好的链式设计可以降低大型语言模型 (LLM) 犯错的概率,但无法完全消除。最好结合多种分层安全方法,而不是依赖任何单一的安全层来确保安全。例如:同时使用只读权限和沙盒,以确保 LLM 只能访问明确指定供其使用的 数据。

不这样做可能带来的风险包括(但不限于):

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

示例场景及缓解策略

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

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

报告漏洞

请通过电子邮件将安全漏洞报告至 [email protected]。这将确保问题得到及时分类和处理。


此页面是否有帮助?


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