不要使用 LLM 来决定 AI agent 的行为
不要再使用 LLM 来决定你的 AI agent 被允许做什么了。
我属于一个名为 AARM 的组织。我们研究如何保障 AI agent 的安全。我们达成了一个共识：控制权必须位于执行点。你需要在工具调用运行前对其进行检查。agent 不能绕过这项检查。告诉 agent“请不要这样做”并不是一种安全模型。
许多人使用第二个 LLM 作为裁判。当 agent 想要执行操作时，你将该操作发送给第二个模型，询问该操作是否安全。模型回答“是”或“否”。这就是“用模型监督模型”。这种方法有两个主要缺陷。
首先，裁判与 agent 具有相同的弱点。agent 可能会被提示词注入（prompt injection）或巧妙的用户请求所欺骗。如果你能欺骗 agent，很可能也能欺骗裁判。你实际上是在第一个系统面前放置了第二个同样会受到压力影响的系统。
其次，LLM 不是确定性的。你可以对同一个模型问两次同样的问题，却得到不同的答案。这是由于采样（sampling）造成的。对于大多数任务来说，这没问题；但对于安全而言，这是一种隐患。
一个 agent 可能在周二被允许删除数据库，但在周三却被拦截了。这其中没有任何逻辑可以解释原因，仅仅是因为“掷骰子”的结果不同。你无法向审计员解释这一点，在凌晨两点发生故障时，你也无法依赖这种机制。
规则则不同。规则会说“禁止在生产环境中执行删除操作”。这每次都会生效。你可以对其进行测试，可以审计日志，可以为这一决策提供依据。
模型对安全很有用，但不应作为最终的关卡。将模型用于“软性工作”：
- 发现异常模式。
- 标记敏感文本。
- 评估风险等级。
- 识别异常情况。
让模型标记问题，但不要让它开启大门。最终决策必须由一个每次都能给出相同答案的系统来做出。
你的 agent 越接近资金、生产数据或客户信息，这一点就越重要。如果 agent 写了一段糟糕的文字，那不是危机；但如果 agent 删除了一个数据库，那就是灾难。
最终决策应该是“枯燥”的。它应该是一条 agent 无法通过“言语诱导”来逾越的硬性底线。
Source: https://dev.to/brianrhall/dont-use-an-llm-to-decide-what-your-ai-agent-is-allowed-to-do-1dkn
Optional learning community: https://t.me/GyaanSetuAi