在工单系统里给 Agent 分配管理员凭据，再在 system prompt 里写上“请只在必要时授权”，往往是越权隐患的起点。
我常用一个跨租户运维的沙箱场景来检验控制结构：Agent 收到一条工单，“新负责人要接管项目，按历史惯例处理”。Agent 检索知识库，找到一条结构相似的高权限审批记录，判断符合惯例，随即生成管理员凭证。但在沙箱推演中，那条参考记录来自另一个隔离租户，工单发起人也并未通过主体的有效核验。
当一个概率模型同时负责理解目标、审查合规性并直接调用 API，任何一次上下文混淆或提示注入，都会直接转化为对真实环境的破坏。
决策与授权的硬性解耦
要阻止这类失败，必须把系统切分为两个平面。模型属于决策面，负责规划步骤、选择工具并组装参数；控制面则是独立于模型运行的确定性程序，只负责评估风险与放行。
模型只负责提出动作，确定性控制面负责授权，工具网关在最后一跳执行决定。
交互应始于一个标准化的动作信封。模型不能直接向高副作用 API 发送原始指令，而是提交一份结构化的动作提议，明确包含发起主体、租户标识、目标资源、参数摘要与请求有效期。
Action Proposal
├── Tenant & Subject (租户与委托身份)
├── Resource & Verb (目标资源与操作类型)
├── Parameter Digest (参数哈希与预算上限)
└── Expiry & Nonce (单次有效票据与时效)
控制面收到提议后，对照静态策略、租户配额与审批状态，返回明确的放行、拒绝或人工介入信号。这里的控制面不需要理解自然语言语义，它只依赖规则：主体缺失则阻断，租户不匹配则丢弃，策略服务超时则默认拒绝。
授权必须与具体的参数摘要绑定。人工批准给用户增加“只读权限”，不能被模型在下一轮对话中沿用为“提升为管理员”；批准针对文档 A 的导出，不能在参数被篡改成文档 B 后继续生效。一旦参数哈希变化，旧审批立即失效。
并发扣费也是典型盲区。两个子任务同时读取到剩余额度为 60 元，各自发起 50 元调用，仅靠模型记忆会导致总额透支。额度必须由外部账本在执行前原子预留，执行成功后结算，失败时退还，未决状态则保持锁定。
执行链路的强制约束与审计
单纯在模型生成动作后做一次静态校验并不够。如果凭证长期存放在 Agent 进程内存中，任何绕过逻辑都能直接触达资源。
执行点必须下沉至工具网关。Agent 不持有敏感系统的长期密钥，所有外部写入都要穿透网关完成。网关在收到请求时核验能力票的签名、时效与幂等键，在物理调用的最后一跳实施拦截。
控制面做出的每一次放行或拒绝决定，都必须持久化留存。审计记录需完整包含请求时的参数哈希、命中的策略版本、当时显式状态的快照与时间戳。当出现未预期调用时，团队能够根据当时的真实上下文完整重放决策链路，避免用更新后的规则去倒推历史。
用第二个 LLM 充当审核员无法解决结构缺陷。审查模型与执行模型共用概率推断机制，同样会被长上下文干扰，容易在参数篡改或过期票据前失效，无非是在一扇概率门后又立了一扇概率门。
确定性防护需要配合独立的 kill switch。运维人员应当能在不依赖模型响应的前提下，按租户、工具或动作类型一键阻断流量，而不是等待 Agent 在任务循环中自行停机。
验证这套机制时，不能只统计任务成功率。应当在沙箱中主动注入跨租户相似历史、过期能力票、并发预算竞争与策略引擎超时。高完成率只能证明模型善于寻找路径，无法证明它在遇到未定义状态时不会越界。
系统自治程度越高，外部约束越要依赖语义有限、状态显式、结果可重复且边界可测试的确定性规则。
作者｜随机比特
