Agent Trust 不是一句“请遵守规则”：一套从 L0 到 L5 的等级划分与实践指南
这段时间看了不少关于 AI agents 的讨论，我越来越强烈地觉得：
今天大多数系统真正解决的，是 capability；还没有真正解决 enforcement。
也就是说，大家很擅长回答下面这些问题：
- agent 能不能调 API？
- 能不能执行 shell？
- 能不能读写文件？
- 能不能连浏览器、连消息渠道、连外部系统？
但一旦问题变成：
- 怎么证明它只做了被允许的事？
- 怎么防止 prompt / tool metadata / page content 把它带偏？
- 出了问题怎么审计、归因、追责？
- 在 production 里，真正的 trust boundary 到底落在哪里？
很多系统就开始失语了。
这也是我越来越不喜欢把 agent 安全讨论停留在“加一段 system prompt”“写几条 behavioral rules”的原因。prompt 可以引导行为，但不能充当最终安全边界。
如果把这个问题说得更直接一点：
Agent trust，不是让模型“答应你会守规矩”，而是让 runtime “没有越界的物理路径”。
本文尝试把 agent trust 拆成一个更工程化的成熟度模型：L0 到 L5。它不是学术定义，而是一张面向实际系统设计的地图。
一、为什么 Agent Trust 是个独立问题？
传统软件的 trust 问题，往往围绕这几个方面展开：
- 身份认证（谁在调用）
- 权限控制（能访问什么）
- 审计日志（做过什么）
- 输入校验（防止恶意输入）
但 agent 系统比传统软件多了一层麻烦：
-
行为是 probabilistic 的
- 同一个任务，不同时间、不同上下文，执行路径可能不同。
-
决策严重依赖上下文
- system prompt、用户消息、tool description、网页内容、API 返回值，都会影响下一步动作。
-
模型不是边界本身
- 你可以告诉它“不要发消息”“不要删除文件”，但只要 runtime 仍然给它对应能力，它就依然可能越界。
-
Agent 连接的是现实世界 side effects
- 发消息、改数据、写代码、调生产 API，这些不是“回答错一道题”，而是会真正造成后果。
所以，agent trust 的核心问题从来不是：
模型够不够聪明？
而是：
它处在什么边界里？谁在约束边界？边界能不能执行？执行后能不能证明？
二、一个更实用的框架：Trust 的 4 个层面
在进入 L0-L5 之前，我先把 trust 拆成 4 个层面。这样你看很多系统时会更容易抓重点。
1）Intent Trust
它理解到的任务，到底是不是你真正想让它做的任务？
这里最容易出问题的地方是：
- prompt injection
- tool description injection
- webpage / retrieved content 污染
- 用户目标在多轮里被“软偏移”
也就是说，agent 的目标本身可能被带歪。
2）Capability Trust
它手里到底有哪些权限？
例如：
- shell 是否开放
- 网络是否开放
- 文件系统范围多大
- 是否能发送消息
- 是否能访问生产凭据
这是今天很多系统最容易做的一层，因为它比较像传统权限控制。
3）Execution Trust
它实际做出来的动作，是否符合 policy？
这层开始真正困难：
- 它为什么调用这个工具？
- 是否只在允许的 scope 内行动？
- 高风险动作有没有审批？
- side effects 能不能被拦下？
4）Proof / Audit Trust
一旦出事，你能不能证明发生了什么？
包括：
- 谁触发的？
- 输入上下文是什么？
- 决策链路是什么？
- 工具调用和结果是什么？
- 日志能不能被篡改？
- 执行环境能不能被证明可信？
很多团队今天最多做到“可观察（observable）”，还远没做到“可证明（provable）”。
三、Agent Trust Maturity Model：L0 到 L5
下面这套等级划分，本质上是在回答一个问题：
你的系统，到底是在“希望 agent 守规矩”，还是在“技术上确保它只能守规矩”？
L0：Demo Trust
典型特征
- 靠 system prompt / policy text / usage guideline 约束行为
- 工具开得很宽，甚至默认全开
- 高风险动作没有真正 gate
- 日志主要靠 transcript
- 出问题后很难复盘
典型话术
- “Do not do anything dangerous.”
- “Only use tools when necessary.”
- “Be careful with external systems.”
核心问题
这一级几乎没有 enforceable boundary。
如果 prompt 被污染，或者模型在复杂上下文里偏了，它仍然可能在已有权限范围内做出错误动作。你得到的，只是一个“看起来懂事”的 agent，而不是一个被工程边界约束住的 agent。
适用场景
- demo
- hackathon
- 内部试验
- 纯 read-only、无 side effect 的探索
一句话总结
L0 是“靠嘴说”，不是“靠系统管”。
L1：Basic Permission Trust
典型特征
- 开始做 tool allowlist
- 文件系统和网络权限有基础限制
- 部分高风险动作需要 approval
- 有最小权限意识，但边界仍比较粗
典型实践
- 只能访问指定 workspace
- 禁止任意外网访问
- 删除、外发、生产改动需要人工确认
- 将 agent 分为 read-only / read-write 两类
能解决什么
L1 能解决“权限完全裸奔”的问题。它把系统从完全依赖 prompt 的状态，推进到了“至少有一堵墙”。
解决不了什么
- 墙还很矮、很粗
- 一旦 agent 在允许范围内做错事，依然伤害不小
- 行为审计和复盘能力仍然薄弱
一句话总结
L1 开始有墙了，但墙还不够细。
L2：Structured Runtime Trust
典型特征
- 不只是限制权限，还开始限制“动作表达方式”
- 用 small, typed, purpose-built tools 替代宽泛能力
- 不同 agent / session / workflow 使用不同 profile
- side effects 尽量走 wrapper，而不是直接暴露底层能力
典型实践
与其给一个通用 shell，不如给：
run_test_suite(project)deploy_staging(service)send_summary_to_owner()update_ticket_status(ticket_id, status)
与其让 agent 任意拼接消息发送，不如给一个有模板、有目标范围的受限接口。
这一级为什么重要？
因为它开始正面承认一个事实：
prompt 永远不可能是最终安全边界，真正的边界要落在 runtime 提供的 capability shape 上。
换句话说，不只是“你不能做危险事”，而是“系统根本不提供那种危险的表达路径”。
适用场景
- 内部生产辅助系统
- 受控业务流程自动化
- 需要一定 side effect、但仍可承受局部失败的 agent 系统
一句话总结
L2 不是限制“你能去哪里”，而是限制“你能以什么方式行动”。
L3：Auditable Production Trust
典型特征
- 每个 action 都有结构化记录
- 有 request → decision → tool call → side effect 的链路
- 高风险动作有审批记录
- 凭据做最小化和 scope 化
- 可以做 replay、correlation、incident review
典型实践
- 所有工具调用写 structured logs
- 日志包含 session、actor、目标对象、结果、错误码
- 所有 approval 有单独 event 记录
- 关键 side effect 有结果确认
- 重要 workflow 有 trace id / run id
这一级的价值
到了 L3，系统已经不是“能跑起来就行”，而是开始为 production incident 做准备：
- 发生了什么？
- 为什么会发生？
- 哪条 policy 没拦住？
- 哪个工具暴露得太宽？
- 哪个上下文把模型带偏了？
这一级仍然主要是 auditable，不是 provable。但对很多企业来说，L3 已经是一个很关键的 baseline。
一句话总结
L3 的核心不是“更安全一点”，而是“出事时能查清楚”。
L4：Policy-Enforced Trust
典型特征
- policy 不再只是说明文档，而是 runtime 可执行规则
- 高风险动作前必须经过 machine-checkable gate
- 可根据风险动态降级能力
- 具备 deny / require-approval / redact / allow-with-scope 等能力
典型实践
- 生产环境修改必须二次审批
- 访问 secrets / 超出 workspace 的文件直接 deny
- 外发消息只能发到 allowlist channel
- 检测到 prompt injection 信号后自动切到 read-only profile
- 某些 API 调用必须带 change ticket / case id 才允许执行
这一级最关键的变化
从 L3 到 L4，是一个根本性变化：
- L3：主要解决看得见
- L4：开始解决拦得住
也就是说，系统不只是记录 agent 做了什么，而是在动作发生之前，就用 policy engine 参与裁决。
难点
- policy 设计复杂
- false positive / false negative 难平衡
- 不同业务线对风险容忍度不同
- 很容易在“太松”和“太烦”之间摇摆
一句话总结
L4 本质上是从 prompt engineering 走向 policy engineering。
L5：Verifiable / Cryptographic Trust
典型特征
- 日志具备 tamper-evident / immutable 属性
- 执行环境可以 attestation
- 关键动作具有 cryptographic provenance
- 能证明“这个 agent 确实在某个受控环境里按某个 policy 运行过”
典型实践方向
- immutable action logs
- remote attestation
- signed artifacts / signed traces
- 可信执行环境（TEE）或类似机制
- 对运行时 policy 和实际执行路径做绑定证明
适用场景
- fintech
- healthcare
- regulated enterprise
- 涉及资金、生产核心资源、合规审计的自动化系统
为什么不是所有团队都该追 L5？
因为 贵、复杂、重。
如果你只是做内部知识助手、个人自动化、普通内容工作流，那么上来就谈 attestation 很容易变成“安全感的炫耀”，而不是现实收益。
但如果你的 agent 真有能力：
- 改生产配置
- 操作客户数据
- 发起高价值交易
- 代表组织做外部行为
那 L5 迟早会从“overkill”变成“必要设施”。
一句话总结
L5 的区别不在于“看得更清楚”，而在于“能证明没有被篡改”。
四、六个等级的本质区别
如果把 L0-L5 压缩成一条线，其实可以这样理解：
- L0：靠嘴说
- L1：开始限权
- L2：开始收窄动作表达
- L3：事后能审计
- L4：事前能执法
- L5：事前能执法，事后还能证明
这条线非常重要，因为它能帮你识别很多“看起来很高级、其实 trust maturity 很低”的 agent 产品。
一个系统工具再多、模型再强、UI 再炫，如果它本质上还是：
- 宽权限
- 弱边界
- 无审批
- 无结构化审计
- 出事靠截图和聊天记录复盘
那它仍然停留在低信任等级。
五、很多团队为什么卡在 L0-L2？
原因并不复杂。
1）行业注意力被 capability 吸走了
大家更愿意投入在：
- 更多工具
- 更强模型
- 更好的 planning
- 更长 context
- 更酷的 multi-agent workflow
因为这些东西更容易展示，也更容易变成“产品亮点”。
而 trust、policy、audit、attestation 往往更像基础设施，不容易在 demo 里显得惊艳。
2）Prompt 很便宜，Runtime 很贵
加一段系统提示词，只需要几分钟。
但要把边界真正落到 runtime，需要：
- 权限设计
- 工具重构
- 审批机制
- 日志体系
- 风险分类
- 回放与取证能力
这是架构工程，不是 prompt 写作。
3）很多团队还没真正进入高风险场景
当 agent 只是做：
- summarization
- note drafting
- low-risk research
trust 问题不会特别痛。
但一旦进入：
- code execution
- file write
- prod API
- external messaging
- customer data
问题会突然从“理论上的担忧”变成“真会出事”。
六、从实践角度，怎么把系统往上推？
最现实的建议是：不要一口气追 L5。
更有效的路线是分阶段推进。
第一阶段：先把系统做成 L2 baseline
这是我认为大多数团队应该优先完成的目标。
重点动作
-
收窄工具，不要宽泛暴露能力
- 尽量少给通用 shell、任意 HTTP、任意 filesystem。
- 优先设计 purpose-built tools。
-
按任务与 agent 分 profile
- research agent、writer agent、ops agent 不该拿到同样的工具集。
-
把危险动作显式分类
- delete、send、publish、prod change、credential access 都应该单独定义。
-
把 prompt 当引导，不当边界
- 真正的安全控制一定要落在 runtime capability 上。
目标
让系统从“模型如果乖就安全”，升级成“即使模型偏了，也不容易立刻越界”。
第二阶段：把 L3 审计链补完整
如果系统已经开始在真实业务里跑，L3 应该尽快补上。
重点动作
- 结构化记录每次工具调用
- 高风险动作保留 approval record
- 统一 trace id / run id
- 记录 side effect 结果，不只记录调用意图
- 做 incident review 机制
目标
让系统具备回答这些问题的能力：
- 它为什么这么做？
- 它是在什么上下文下做的？
- 哪个工具调用造成了问题？
- 哪条 policy 应该加，哪种权限应该收窄？
第三阶段：针对高风险面推进 L4
当系统开始接触高价值资源时，只可观察已经不够了。
重点动作
- 把 policy 从文档变成可执行规则
- 高风险操作前做 machine gate
- 引入风险分级与动态降权
- 对外部发送、生产改动、跨边界访问设置强约束
目标
让 runtime 不只是“记录”，而是“拦截与裁决”。
第四阶段：只在必要处引入 L5
如果你在做的是：
- 金融代理
- 合规自动化
- 基础设施强执行
- 高敏感数据操作
那可以开始考虑：
- tamper-evident logs
- attestation
- signed provenance
- 可验证运行环境
但如果还没到这个风险等级，请先把 L2-L4 做扎实。很多团队最大的漏洞，不是没上密码学，而是连最基本的 narrow tools 和 approval gates 都没有。
七、一个简单的自测清单
如果你想快速判断自己的 agent system 处在哪一级，可以问自己 5 个问题：
1. 如果 prompt 被污染，它还能不能碰到危险资源？
- 如果答案是“能”，trust maturity 大概率还比较低。
2. 高风险动作是否必须经过技术性 gate？
- 如果只靠提示词提醒，基本还在 L0-L1。
3. 它做过什么，能不能结构化追踪？
- 如果只能靠聊天记录回忆，说明还没到 L3。
4. 出问题后，能不能重放和归因？
- 不能的话，审计能力仍然不足。
5. 执行记录和环境，能不能防篡改或被证明可信？
- 这是 L5 才会真正认真回答的问题。
这个清单很简单，但非常实用。
八、结语：Trust 的本质，不是“更聪明”，而是“更可控”
很多人一谈 agent，就很容易被“更强 reasoning”“更长 context”“更复杂 multi-agent”吸引。
这些东西当然重要，但如果系统最终要连接现实世界，真正决定它能不能进入 production 的，往往不是“聪不聪明”，而是：
- 边界够不够清晰
- 权限够不够收敛
- 动作能不能被裁决
- 问题能不能被追踪
- 结果能不能被证明
所以我现在更愿意把 agent trust 理解成一条清晰的演进路线：
从“靠提示词自律”，走向“靠 runtime 强制约束”，再走向“可验证执行”。
这条路不会一夜完成，但它大概率会决定：
谁的 agent 只能活在 demo 里，谁的 agent 能真正活进 production。
