Agent工具执行前，授权应交给谁

Agent 能调用工具，不代表它有权执行工具里的所有操作。作者用一个 CRM 场景指出了问题：用户只要求汇总客户信息，模型却决定顺手修改记录。函数存在、参数合法、API key 可用，都不能证明这次修改获得了授权。

作者的结论是：每个会产生实际影响的工具调用，都应经过可信执行层检查，但不必每次都弹窗找人批准。这篇值得读的地方，是把「模型提出行动」和「系统批准行动」拆开，并列出了一组比正常调用成功更值得测试的失败场景。

工具能用，为什么还不能直接执行

常见 Agent 流程是用户提需求，模型推理、选择工具，工具直接执行。用来演示很顺畅，作为完整的授权架构却缺了一道边界。

原文的 CRM 同时暴露 get_customer 和 update_customer。用户要求汇总账户信息，通常需要前者；模型认为记录有问题，转而调用后者，就把信息读取扩展成了数据修改。

参数校验只能回答「这个请求的格式对不对」，API key 能用只能说明连接器具备访问能力。至于当前用户能否修改这个租户下的这条记录，需要另外判断。

模型负责提出行动，可信运行时负责判断行动是否获准。

这里的可信运行时，可以理解为模型无法通过生成文本随意改写的后端执行组件。它依据已认证身份、租户上下文、资源归属和具体操作做决定，不能把模型声称的「用户同意了」当作授权证据。

检查也应落在工具执行边界，而不是每生成一个推理 token，就额外调用一次昂贵的策略模型。

三种执行结果，比统一弹窗更实用

作者给出的结果有三种：ALLOW 放行，使用限定权限的凭证执行；HOLD 暂停，展示行动预览并等待批准；DENY 拒绝，阻止执行并解释原因。决策和执行结果都应留下审计记录。

低风险读取仍需基础授权，高风险操作再增加控制。这里要区分两件事：系统有没有检查权限，以及用户是否必须亲自确认。

下面这段原文伪代码说明了检查顺序，以及哪些条件应导致拒绝或暂停：

from dataclasses import dataclass
from enum import Enum

class Outcome(Enum):
    ALLOW = "allow"
    HOLD = "hold"
    DENY = "deny"

@dataclass(frozen=True)
class Action:
    actor_id: str
    tenant_id: str
    tool: str
    operation: str
    resource_id: str
    parameters: dict
    action_id: str

def check_action(action, identity, policy, approvals, budget):
    # 默认拒绝：必需控制失败时，绝不能返回 ALLOW。
    if not identity.can_act_for(action.actor_id, action.tenant_id):
        return Outcome.DENY

    if not policy.permits_exact_action(action):
        return Outcome.DENY

    if not policy.has_sufficient_evidence(action):
        return Outcome.HOLD

    if policy.needs_approval(action):
        if not approvals.valid_for_exact_action(action):
            return Outcome.HOLD

    if not budget.can_reserve(action):
        return Outcome.DENY

    return Outcome.ALLOW

要看的是 approvals.valid_for_exact_action(action)：批准必须绑定具体行动。批准给甲发邮件，收件人换成乙后，原批准就不能继续使用。Agent 自己在参数里写入 "approved": true，也不能满足审批条件。

这只是架构示意。代码中的 budget.can_reserve(action) 没有完成真实预算预留，审批校验也没有展示原子消费。作者明确要求生产实现补上签名检查、规范化参数校验、事务性或原子性的审批消费、短期凭证、过期控制、幂等和安全日志，并在实际执行时重新授权。

否则，检查时通过的行动，执行时可能已经变了。

真正该测试的是拒绝之后会发生什么

正常路径比较容易验证：用户有权限，读取在范围内，调用成功。作者更关心团队容易推迟处理的异常路径。

跨租户访问必须拒绝；审批后替换邮件收件人，原审批必须失效；策略服务超时，应该暂停或拒绝，不能默认执行。

还有一个容易漏掉的绕行问题：用户拒绝了某次行动，Agent 换一个连接器尝试完成同一件事，也应该被拦住。限制需要约束行动，不能只封住某个工具入口。

写入超时则是另一类问题。API 可能已经收到请求甚至完成修改，只是响应没回来。此时应核对实际结果，不能盲目重复写入。预算耗尽也应停止或升级处理，避免 Agent 无限循环。

这些测试还要检查可追溯性：能查清谁批准了什么、最终发生了什么，同时不能把凭证和敏感数据明文写入日志。

我的判断

我认同把授权放进可信执行层。提示词可以告诉模型行为边界，但它无法替后端证明用户身份、资源归属或审批有效性。对于连接 CRM、邮件和内部业务系统的 Agent，这条分工很有实际价值。

相比统一人工确认，按风险决定放行、暂停或拒绝，能减少不必要的打断。不过原文没有定义风险分级标准，也没有解释「证据充分」如何判定。这些条件仍需团队结合业务规则落实。

原文还介绍了 Nuroen AI 的公开运行时设计，称其覆盖范围、置信度、策略、审批、预算和审计。但没有提供运行数据、性能开销或对照实验。这部分属于架构主张与产品介绍，不能据此认定平台已经验证了所有边界情况。

一般团队可以先利用现有后端鉴权、资源权限和审批系统，在工具执行入口接入检查。是否需要独立策略服务，原文没有给出足够证据支持统一答案。

能拿来做什么

• 给 Node Agent 的工具执行入口加一层统一检查，绑定已认证用户、租户、资源和操作，避免仅凭模型生成的参数决定权限。
• 为敏感操作设计准确的前端预览，展示收件人、目标记录和修改内容，并让审批绑定这些参数；参数变化后重新检查。
• 在现有测试中补上跨租户、审批后换参数、策略超时、拒绝后换连接器、写入结果未知和预算耗尽等场景，验证系统能否正确停止。
• 对会修改外部状态的连接器明确超时处理：先核对实际执行结果，再决定是否重试，并保留不含明文凭证的审计记录。