安全
¥Security
LangChain 拥有一个庞大的生态系统，可以集成各种外部资源，例如本地和远程文件系统、API 和数据库。这些集成允许开发者创建多功能应用，将 LLM 的强大功能与访问、交互和操作外部资源的能力相结合。
¥LangChain has a large ecosystem of integrations with various external resources like local and remote file systems, APIs and databases. These integrations allow developers to create versatile applications that combine the power of LLMs with the ability to access, interact with and manipulate external resources.
最佳实践
¥Best Practices
在构建此类应用时，开发者应牢记遵循良好的安全实践：
¥When building such applications developers should remember to follow good security practices:
限制权限：根据应用的需求确定权限范围。授予过多或过多的权限可能会带来严重的安全漏洞。为避免此类漏洞，请考虑根据你的应用使用只读凭据、禁止访问敏感资源、使用沙盒技术（例如在容器内运行）等。
¥Limit Permissions: Scope permissions specifically to the application's need. Granting broad or excessive permissions can introduce significant security vulnerabilities. To avoid such vulnerabilities, consider using read-only credentials, disallowing access to sensitive resources, using sandboxing techniques (such as running inside a container), etc. as appropriate for your application.
预测潜在误用：正如人会犯错一样，大型语言模型 (LLM) 也会犯错。始终假设任何系统访问权限或凭证都可以以其分配的权限允许的任何方式使用。例如，如果一对数据库凭据允许删除数据，那么最安全的假设是，任何能够使用这些凭据的 LLM 实际上都可以删除数据。
¥Anticipate Potential Misuse: Just as humans can err, so can Large Language Models (LLMs). Always assume that any system access or credentials may be used in any way allowed by the permissions they are assigned. For example, if a pair of database credentials allows deleting data, it’s safest to assume that any LLM able to use those credentials may in fact delete data.
纵深防御：没有完美的安全技术。微调和良好的链设计可以降低（但不能消除）大型语言模型 (LLM) 出错的几率。最好结合多层安全方法，而不是依赖任何单一防御层来确保安全。例如：使用只读权限和沙盒来确保 LLM 只能访问明确供其使用的数据。
¥Defense in Depth: No security technique is perfect. Fine-tuning and good chain design can reduce, but not eliminate, the odds that a Large Language Model (LLM) may make a mistake. It’s best to combine multiple layered security approaches rather than relying on any single layer of defense to ensure security. For example: use both read-only permissions and sandboxing to ensure that LLMs are only able to access data that is explicitly meant for them to use.
不这样做的风险包括但不限于：
¥Risks of not doing so include, but are not limited to:
数据损坏或丢失。
¥Data corruption or loss.
未经授权访问机密信息。
¥Unauthorized access to confidential information.
关键资源的性能或可用性受损。
¥Compromised performance or availability of critical resources.
具有缓解策略的示例场景：
¥Example scenarios with mitigation strategies:
用户可以要求有权访问文件系统的代理删除不应删除的文件或读取包含敏感信息的文件的内容。为了缓解此问题，请限制代理仅使用特定目录，并且仅允许其读取或写入可以安全读取或写入的文件。考虑通过在容器中运行代理来进一步对其进行沙盒化。
¥A user may ask an agent with access to the file system to delete files that should not be deleted or read the content of files that contain sensitive information. To mitigate, limit the agent to only use a specific directory and only allow it to read or write files that are safe to read or write. Consider further sandboxing the agent by running it in a container.
用户可能会要求具有外部 API 写权限的代理将恶意数据写入 API，或从该 API 中删除数据。为了缓解此问题，请为代理提供只读 API 密钥，或将其限制为仅使用已经能够抵御此类滥用的端点。
¥A user may ask an agent with write access to an external API to write malicious data to the API, or delete data from that API. To mitigate, give the agent read-only API keys, or limit it to only use endpoints that are already resistant to such misuse.
用户可以要求有权访问数据库的代理删除表或更改模式。为了缓解此问题，请将凭据范围限制为代理需要访问的表，并考虑颁发只读凭据。
¥A user may ask an agent with access to a database to drop a table or mutate the schema. To mitigate, scope the credentials to only the tables that the agent needs to access and consider issuing READ-ONLY credentials.
如果你正在构建访问外部资源（例如文件系统、API 或数据库）的应用，请考虑与公司的安全团队沟通，以确定如何最佳地设计和保护你的应用。
¥If you're building applications that access external resources like file systems, APIs or databases, consider speaking with your company's security team to determine how to best design and secure your applications.
报告漏洞
¥Reporting a Vulnerability
请通过电子邮件向 security@langchain.dev 报告安全漏洞。这将确保问题得到及时分类并根据需要采取行动。
¥Please report security vulnerabilities by email to security@langchain.dev. This will ensure the issue is promptly triaged and acted upon as needed.