LLM 不应直接连接生产环境。我们在中间设置四道边界

你知道吗，我们团队在审视最近几个客户项目后发现，不少代理架构依然采用大致相同的设置：用户 → LLM → 工具调用 → 生产 API。这种设置演示时或许可行，但作为默认方案风险极高——只要涉及资金流动、客户数据修改、消息发送、代码部署或任何其他不可逆操作。模型应该被允许推理，但不应允许其自行定义身份、权限、负载或执行路径。对我们而言，效果最好的方案包含四道边界： 1. 身份边界 在请求到达 LLM 之前，我们对用户进行身份验证。像 user_id、tenant_id、role、session 和 correlation ID 这些信息由可信的应用代码添加。模型永远不会生成或覆盖它们。我们还在这一边界维护用户和租户级别的速率限制。通用的令牌限制虽然有用，但如果某个特定用户可以反复触发高成本或高风险的工具，那就没什么帮助了。 2. 意图边界 在编排层内部，代理可以对请求进行分类、检索上下文、规划几步操作并提出工具调用。但输出的仍然只是一个提案：一个带有严格模式和风险级别的命名操作，例如读取、准备、写入或不可逆。我们尽量避免在提示词中隐藏真正的权限。“除非……否则永远不要执行此操作”是一条有用的指令，但它并非访问控制机制。 3. 策略与执行边界 这可能是最重要的一道边界。我们检查：身份和租户范围、基于角色或属性的权限、输入输出模式、业务规则和操作特定限制、审批要求、幂等性和重试规则、该操作当前是否启用。这一层还管理限定范围的凭据、幂等性、重试、终止开关和断路器。一个容易被忽略的细节：审批应针对确切的负载。如果金额、接收方、环境或目标资源发生变化，之前的审批应视为无效。我们也会记录被拒绝的尝试。在实践中，当你想了解代理试图做什么时，这些记录通常比成功调用更有用。 4. 记录系统边界 应用程序或记录系统应再次验证自身的不变性、执行操作并返回持久结果。代理说“完成”并不能证明转账、部署、邮件或更新确实发生了。在授予代理写入权限之前，我们还会考虑恢复机制。事务、分阶段操作、检查点、幂等键和补偿操作都有帮助。不过，有些操作确实无法回滚。对于这些操作，我们宁愿增加单独的审批步骤，而不是假装审计日志就足够了。因此，大致的流程是：LLM 提出 → 策略决策 → 确定性代码验证 → 必要时人工审批 → 核心系统执行 → 审计日志记录结果。 *** 这是我们目前作为起点的模型。它对我们来说效果不错，但我们怀疑它并非终极答案。这里缺少哪些边界或控制措施？在实际系统中，你们最终将权限检查放在哪里？