Agent Trust 不是一句“请遵守规则”：一套从 L0 到 L5 的等级划分与实践指南

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 个层面。这样你看很多系统时会更容易抓重点。1Intent Trust它理解到的任务到底是不是你真正想让它做的任务这里最容易出问题的地方是prompt injectiontool description injectionwebpage / retrieved content 污染用户目标在多轮里被“软偏移”也就是说agent 的目标本身可能被带歪。2Capability Trust它手里到底有哪些权限例如shell 是否开放网络是否开放文件系统范围多大是否能发送消息是否能访问生产凭据这是今天很多系统最容易做的一层因为它比较像传统权限控制。3Execution Trust它实际做出来的动作是否符合 policy这层开始真正困难它为什么调用这个工具是否只在允许的 scope 内行动高风险动作有没有审批side effects 能不能被拦下4Proof / Audit Trust一旦出事你能不能证明发生了什么包括谁触发的输入上下文是什么决策链路是什么工具调用和结果是什么日志能不能被篡改执行环境能不能被证明可信很多团队今天最多做到“可观察observable”还远没做到“可证明provable”。三、Agent Trust Maturity ModelL0 到 L5下面这套等级划分本质上是在回答一个问题你的系统到底是在“希望 agent 守规矩”还是在“技术上确保它只能守规矩”L0Demo 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。适用场景demohackathon内部试验纯 read-only、无 side effect 的探索一句话总结L0 是“靠嘴说”不是“靠系统管”。L1Basic Permission Trust典型特征开始做 tool allowlist文件系统和网络权限有基础限制部分高风险动作需要 approval有最小权限意识但边界仍比较粗典型实践只能访问指定 workspace禁止任意外网访问删除、外发、生产改动需要人工确认将 agent 分为 read-only / read-write 两类能解决什么L1 能解决“权限完全裸奔”的问题。它把系统从完全依赖 prompt 的状态推进到了“至少有一堵墙”。解决不了什么墙还很矮、很粗一旦 agent 在允许范围内做错事依然伤害不小行为审计和复盘能力仍然薄弱一句话总结L1 开始有墙了但墙还不够细。L2Structured Runtime Trust典型特征不只是限制权限还开始限制“动作表达方式”用small, typed, purpose-built tools替代宽泛能力不同 agent / session / workflow 使用不同 profileside 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 不是限制“你能去哪里”而是限制“你能以什么方式行动”。L3Auditable 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 的核心不是“更安全一点”而是“出事时能查清楚”。L4Policy-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。L5Verifiable / Cryptographic Trust典型特征日志具备 tamper-evident / immutable 属性执行环境可以 attestation关键动作具有 cryptographic provenance能证明“这个 agent 确实在某个受控环境里按某个 policy 运行过”典型实践方向immutable action logsremote attestationsigned artifacts / signed traces可信执行环境TEE或类似机制对运行时 policy 和实际执行路径做绑定证明适用场景fintechhealthcareregulated 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 里显得惊艳。2Prompt 很便宜Runtime 很贵加一段系统提示词只需要几分钟。但要把边界真正落到 runtime需要权限设计工具重构审批机制日志体系风险分类回放与取证能力这是架构工程不是 prompt 写作。3很多团队还没真正进入高风险场景当 agent 只是做summarizationnote draftinglow-risk researchtrust 问题不会特别痛。但一旦进入code executionfile writeprod APIexternal messagingcustomer data问题会突然从“理论上的担忧”变成“真会出事”。六、从实践角度怎么把系统往上推最现实的建议是不要一口气追 L5。更有效的路线是分阶段推进。第一阶段先把系统做成 L2 baseline这是我认为大多数团队应该优先完成的目标。重点动作收窄工具不要宽泛暴露能力尽量少给通用 shell、任意 HTTP、任意 filesystem。优先设计 purpose-built tools。按任务与 agent 分 profileresearch 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 logsattestationsigned 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。