AI Agent 敢开生产写权限吗？我用四道闸门守住安全边界

AI Agent 从“能回答问题”走向“能调用工具”，真正困难的并不是再接一个模型，而是决定：它到底可以改什么。

读数据库、生成建议，风险通常可控；创建工单、修改订单、发送消息、删除数据，则会产生真实副作用。把这些动作统统交给模型，再用一句“请谨慎操作”约束，等于把安全寄托在提示词上。

我更认可一个朴素结论：生产写权限不是开或关的二选一，而是一条必须逐级放行、能随时停下、事后还能证明发生了什么的执行链。

一、先把“写权限”拆成四个等级

第一层是只读观察。Agent 可以读取经过授权的业务数据，但不能修改任何状态。这个阶段最适合验证检索范围、身份传递和输出质量。

第二层是生成建议。Agent 可以形成结构化方案，例如建议给某张工单升级优先级，但它输出的是“建议对象”，不是直接写数据库。

第三层是短时审批。只有当前操作者对这一次动作明确确认，系统才签发一个范围受限、很快过期、只能使用一次的批准凭证。

第四层才是执行与回读。系统完成写入后，不能只相信接口返回成功，还要重新查询目标对象，核对关键字段是否真的变成预期值。

这套分层对应零信任的三个核心判断：每次访问都要显式验证；主体只获得完成当前任务所需的最小权限；系统要假定错误或入侵已经可能发生，因此必须限制影响并持续监控。

二、把模型建议和业务命令分开

不要让模型直接拼接 ORM 或 SQL。更稳妥的做法是先让它生成一个受约束的命令对象：

from dataclasses import dataclass
from typing import Literal


@dataclass(frozen=True)
class TicketProposal:
    ticket_id: int
    action: Literal["raise_priority", "assign_team"]
    reason: str
    expected_version: int

接下来由确定性代码完成四项检查：

1. 当前用户是否有权操作这张工单；
2. action 是否在业务白名单内；
3. 对象版本是否仍等于 expected_version；
4. 本次动作是否已经得到有效审批。

模型负责理解语义和给出建议，业务层负责授权、校验和落库。这样即使模型出现幻觉，它也只能生成一份无效建议，不能跳过领域规则直接产生副作用。

三、审批必须绑定“这一次、这份内容”

一个只写着 approved=true 的布尔字段远远不够。审批至少应绑定：

• 操作主体；
• 目标对象；
• 动作类型；
• 参数摘要或内容哈希；
• 过期时间；
• 单次使用状态。

@dataclass(frozen=True)
class Approval:
    actor_id: str
    target: str
    action: str
    payload_sha256: str
    expires_at: str
    nonce: str

如果正文、参数或目标对象在审批后发生变化，原批准应立即失效。否则“批准 A、执行 B”会成为最隐蔽的越权通道。

人工确认也不应该变成一个无脑点击的弹窗。确认界面至少要展示：谁将执行、改哪个对象、改前值、改后值，以及失败后的恢复方式。

四、幂等性决定写动作能不能安全重试

网络超时最容易诱发第二次事故：客户端不知道第一次是否成功，于是直接再执行一次。

对于创建、扣费、发送和发布等动作，正确顺序是：

1. 执行前记录操作意图；
2. 为当前业务动作生成稳定的幂等键；
3. 服务端保证同一个键最多产生一个最终对象；
4. 超时后先查询真实结果，再决定是否重试。

def execute_once(command, idempotency_key, repository):
    existing = repository.find_by_key(idempotency_key)
    if existing:
        return existing

    repository.record_intent(idempotency_key, command)
    result = command.execute()
    repository.record_result(idempotency_key, result.id)
    return result

如果外部系统既不支持幂等，也无法查询执行结果，自动化应该暂停并转人工，而不是赌一次“应该没成功”。

五、后验验证要验证业务事实

很多系统把 HTTP 200、按钮点击成功或页面跳转当成完成证据，但这些只说明某个技术动作被接受。

真正的验收应该回到业务事实：

• 新对象是否存在；
• 关键字段是否完全匹配；
• 是否只创建了一个对象；
• 审批是否已经消费；
• 审计记录是否能关联操作者、动作和结果。

例如“AI 已创建跟进任务”的完成条件，不是接口返回 success，而是按幂等键查询到唯一任务、负责人和截止时间正确、审批已消费，并且重新执行不会生成第二条记录。

六、哪些动作可以自动，哪些必须停下来

我会按副作用和可恢复性划分：

动作	默认策略
查询、聚合、生成摘要	自动执行
生成草案、建议、待办	自动生成，人工选择
可撤销的低风险写入	短时审批后执行
发消息、公开发布、扣费	精确审批、幂等、后验验证
删除、覆盖、无法恢复的操作	默认拒绝或人工接管

这张表不是固定答案。业务价值、数据敏感度、可撤销性和外部系统能力不同，边界也会变化。但“先读、再建议、后审批、执行后回读”是一条可靠的起点。

七、上线前的最小验收清单

• Agent 使用独立身份，不借用管理员万能凭据；
• 工具接口是业务级动作，不暴露任意 SQL 或任意脚本执行；
• 写动作有明确白名单和对象级授权；
• 批准绑定目标、参数哈希、过期时间和单次使用；
• 副作用操作有幂等键；
• 超时后先查询真实状态；
• 完成标准验证业务结果，不只验证接口成功；
• 无法判断时暂停并交给人。

参考与验证依据

本文以已锁定版本的 RuyiBookCourse“智能体安全、护栏、信任与隐私”和“Codex 长任务 Harness”相关章节为知识依据，重点复核了零信任、最小权限、幂等执行和后验验证之间的关系。示例代码用于解释架构边界，不包含真实凭据、客户数据或生产端点；落地时仍需结合具体业务的授权模型、数据敏感度和恢复能力进行威胁建模与测试。

总结

AI Agent 可以获得生产写能力，但不应该得到一把永久、宽泛、不可审计的钥匙。

更可靠的架构，是把模型放在受控执行链里：只读观察建立上下文，结构化建议隔离幻觉，短时审批约束意图，幂等键限制重复副作用，后验回读证明真实结果。

当系统能回答“谁批准了什么、执行了几次、真实结果是什么”，写权限才从一次冒险，变成了可治理的工程能力。