理解LLMs中的过度代理
过度代理在LLMs中是一个广泛的安全风险，其中AI系统能够做超出其应有范围的事情。这种情况发生在它们被赋予过多访问权限或权力时。主要有三种类型：
- 功能过多：LLMs可以使用它们不需要的工具
- 访问权 限过大：AI获得了不必要的后端系统权限
- 自由度过大：LLMs在没有人工检查的情况下做出决策
这与不安全的输出处理不同。它关乎LLM能做什么，而不仅仅是它说什么。
示例：一个可以读取客户信息的客服聊天机器人是可以的。但如果它还能更改或删除记录，那就是过度代理。
OWASP Top 10 针对LLM应用将其列为主要关注点。要解决这个问题，开发者需要仔细限制他们的AI能做的事情。
过度代理的原因是什么？
LLMs中的过度代理通常源于善意但实施不当的功能。当AI系统被赋予比其预期功能所需的更广泛的能力或访问权限时，就会出现这种漏洞类型。
常见示例
过度代理以几种方式出现，但有一些常见的模式。
-
过度扩展的工具：大多数LLM提供商对"工具"或函数提供一流的支持，这只是说"暴露给LLM的API"的一种花哨方式。
这些API经常包含不必要的功能。例如，文档摘要工具可能还具有编辑和删除功能，从而扩大了潜在的攻击面。
-
不安全的API：不能信任LLM访问后端系统。我们经常看到IDOR风格的漏洞，其中LLM可以进行任意数据引用。
-
数据库权限过大：LLM代理通常连接到具有比所需更多权限的数据库。
-
特权账户滥用：使用高级别凭证进行日常任务会带来不必要的暴露。支持聊天机器人不应以管理员级别的权限访问敏感的员工数据。
-
开发工件：测试或调试功能可能意外地留在生产环境中。即使它们没有在提示中明确提及，也可以被调用。
这些场景有一个共同点：赋予LLM比其核心任务所需的更多权力。
开发者在将LLMs集成到他们的系统中时，必须仔细考虑最小权限原则。通过将访问和功能限制在必要的范围内，他们可以显著降低过度代理漏洞的风险。
为什么过度代理是个问题？
LLMs中的过度代理在安全和业务领域都带来了重大风险。
安全风险
未经授权的数据访问：具有过多权限的LLMs可能会检索并暴露超出其预期范围的敏感信息。根据您的应用程序，这可能包括专有公司信息或文档（例如在RAG系统中）。
远程执行：利用过度代理的攻击者可能会潜在地运行任意函数。在LLMs具有有意义的系统访问权限的环境中，这种风险会被放大，随着公司开始探索代理系统，这种情况更有可能发生。
隐私泄露：权限过大的AI助手可能在响应中无意中披露私人用户信息。这种泄露不仅会侵蚀用户信任，还可能违反数据保护法规，如GDPR或CCPA。
业务风险
财务损失：具有直接访问业务系统的LLMs可能会被操纵。
声誉损害：行为不当或泄露机密信息的AI会严重损害公司的形象。在违规后重建信任既昂贵又耗时。
运营中断：具有过多管理员权限的LLMs可能会更改关键配置或删除重要数据。
法律责任：如果AI系统由于过度权限或不当访问控制而造成损害，公司可能会面临诉讼，特别是在受监管的行业，如医疗或金融。
过度代理的隐蔽性意味着漏洞可能在被利用之前长期存在而未被发现。这突显了定期安全审计和持续监控LLM活动的重要性。
防止过度代理
减轻过度代理需要在LLM开发和部署的所有阶段进行工作。
限制LLM能力
首先限制LLM的操作范围：
- 最小化工具暴露：只集成必要的工具并移除任何不必要功能。
- 细粒度功能设计：将宽泛、开放式的功能替换为定义狭窄、目的明确的功能。
- 定制集成：开发定制的API，而不是依赖通用接口。
考虑一个由LLM驱动的代码助手。与其授予其对整个仓库的完全访问权限，不如创建一个内部API，该API仅允许对特定文件或目录进行读取操作。
实施访问控制
实施严格的访问管理，这样即使有人破解了你的应用，他们也无法造成任何损害。
- 分段账户：为每个LLM功能使用独立的、权限受限的账户。
- 上下文权限：根据当前用户的作用域和需求实施动态访问权限。
- 细粒度的后端控制：在所有连接的系统上应用详细的访问策略。
例如，一个支持聊天机器人应使用仅允许访问与其当前协助的客户相关的数据的凭证进行操作。
添加防护措施
你还可以采取更多措施来限制因过度代理漏洞带来的下行风险。
-
人工监督：要求对高风险操作 进行手动批准。
-
限流：限制API调用频率，以减缓探索和攻击速度。
-
强大的监控：使用日志工具检测异常的LLM行为模式。
-
输入与输出净化：对输入和输出进行审核，以防止意外操作。
这些保护层作为关键的安全网，捕捉可能逃过主要防御的问题。
防止过度代理需要持续的警惕。在扩展功能或集成新系统时，始终要问：“这个LLM需要的最小访问级别是什么？”然后，仅提供这些——不多不少。
检测过度代理问题
识别过度代理问题需要主动监控和严格测试。仅靠被动防护是不够的。
测试方法
挑战系统的边界。使用旨在将AI推至其预期极限的输入对系统进行红队测试。重点关注以下关键领域：
-
未经授权的访问：意外的数据访问。
- 功能级授权失效（BFLA）
- 对象级授权失效（BOLA，类似于IDOR）
- 未经授权的数据访问或操纵
-
操纵与注入：诱使LLM执行操作的方法。
- 提示注入与提取
- 通过受信任的数据源进行间接提示注入
-
作用域与能力扩展：尝试触发超出LLM预期作用域的操作。
- 未经授权的工具或API使用
- 执行受限操作或命令
- 访问或修改超出授权范围的资源
自动化工具可以通过数千种不同的输入对系统进行压力测试，并发现人类测试者可能忽略的边缘情况。
LLM特别容易受到注入或利用应用程序级提示场景的越狱攻击。确保在测试套件中包含社会工程类型的攻击。
监控策略
记录每一次AI操作，特别是与外部系统的交互，以创建全面的审计跟踪 。
对异常模式实施警报：
- API调用的异常峰值
- 尝试进行受限操作
- 访问不常使用的数据库表或API
将监控范围扩展到LLM本身之外。仔细检查连接的系统，寻找意外的数据变化、异常的交易模式或来自未知来源的访问尝试。
标准的可观察性和安全工具，如Datadog和Sentry，通常足以应对这些需求。你可能不需要专门的AI监控工具！
下一步是什么？
在未来，过度代理的问题将变得更加困难，而不是更容易解决。这是因为生成式AI应用正朝着增加数据访问和代理的方向发展。它们也将变得更加复杂，并在我们的日常生活中更加普遍。