在传统安全体系里，"合法"是一个分量很重的词。请求是否合法，账户是否合法，Credential 是否有效，角色是否拥有相应权限，API 调用是否符合访问控制规则——这些判断构成了现代信息安全最基本的秩序。身份认证确认主体，权限系统限制能力，审计系统记录过程，密码学保证凭据与通信不被伪造。几十年来我们不断强化这些机制，本质上都在确保一件事：只有合法主体，才能通过合法方式，使用被授权的能力。

这个目标没有错。值得重新思考的是，当这三个条件全部成立之后，我们是不是过早地得出了第四个结论——因此这个动作也是正确的。身份合法不等于理解正确，Credential 合法不等于意图正确，权限合法更不等于最终发生的事情正确。AI Agent 正在把这三个长期被混在一起的概念重新拆开。

合法描述的是一个动作"有没有资格进入系统"，正确描述的却是"这个动作是否应该进入现实"。

一、传统安全非常擅长判断"非法"

现代安全体系有一个鲜明特征：它特别擅长识别不合法。错误密码被拒绝，失效 Token 被拒绝，无权限的 API 请求被拒绝，证书不可信被拒绝；来源异常可以被 Zero Trust Policy 阻断，用户越出 Role 范围会被 RBAC 拦下，Service Account 索要未授予的 Scope，Authorization Server 会直接拒绝。这些机制共同形成一条清晰的边界：你不是这个人就不能进来，你没有这个权就不能做。

这套逻辑在互联网时代取得了巨大成功，因为大量攻击确实建立在"非法获得能力"之上——Credential Theft、Privilege Escalation、Account Takeover、Unauthorized Access，本质上都在突破这条边界。于是合法性逐渐成为许多系统判断安全状态的主要依据：身份没被盗用、Credential 没泄露、调用没越权，系统就认为这个请求在安全意义上正常。

但这里藏着一个关键差别：安全系统验证的是调用关系是否合法，却未必验证这个调用本身是否符合真实意图。在人的时代这一点很少暴露，因为"是否合法"由系统判断，"是否正确"通常由人补上。AI Agent 正在移除这层默认补丁。

二、身份完全正确，事情仍然可以完全做错

设想一个普通的企业 Agent：拥有公司正式分配的身份，通过 OAuth 获得合法 Token，被授予调用 CRM、邮件系统和支付 API 的权限，没有任何 Credential 泄露，也没有攻击者冒充。用户给它一个任务——处理今天需要退款的客户。它分析数据，找出一批订单，然后执行退款。身份真实，Token 有效，退款接口是正式接口，金额也没有超过权限限制。

但其中一个订单其实不该退。可能客户状态刚刚变化，可能某条数据同步延迟，可能 Agent 误解了业务规则，也可能它把"待复核"读成了"确认退款"。从访问控制的角度看，这个动作毫无问题；从业务现实看，它就是错的。

这迫使我们区分 Authorized Action 与 Desired Action。一个动作可以是被完整授权的，同时是不应该发生的——更准确地说，它是一次 Authorized but Undesirable Execution。

安全系统最难处理的，不一定是未经授权的动作，而是被完整授权、却不应该发生的动作。

三、CREDENTIAL 证明你拿到了钥匙，却无法证明你为什么开门

API Token、SSH Key、Certificate、Private Key、Session、OAuth Access Token，本质上都在证明某种调用资格，回答的是"这个主体能不能使用这个能力"。签名私钥能证明交易由合法 Key Holder 签署，OAuth Token 能证明应用拥有特定 Scope，SSH Key 能证明主体有资格登录目标服务器。这些证明都很强，却共享同一个边界：Credential 几乎永远不知道持有者为什么要执行当前动作。

私钥能证明签名是真的，不能证明这笔交易符合持有者此刻的真实意图；Token 能证明调用者拥有 payment.write，不能证明这笔付款现在应该发生；管理员证书能证明请求来自合法设备，不能证明这次配置变更不会破坏生产环境。Credential 证明的是 Authority，不是 Intent，更不是 Correctness。

密钥能够证明"谁授权了这个动作"，却不能自动证明"这个动作值得发生"。

过去这个差距由人类认知填补。当 Credential 开始直接交给 Agent 使用，缺口就暴露出来了。

四、"有权限"一直都不是"有理由"

权限模型描述的是能力边界：某个角色可读、某个角色可写、某个管理员可删、某个 Agent 可以调用某个 Tool。它非常适合回答"谁能够做什么"，但现实决策依赖的不只是能力，还有理由。CFO 拥有一百万美元的付款权限，不意味着他每天都该支付一百万；Root 可以删除整个目录，不意味着每一次删除都合理；生产管理员拥有 Restart 权限，不意味着服务此刻就该重启。同样，Agent 拥有某个 Tool Permission，也不意味着每一次 Tool Call 都符合原始 Mission。

差别在于时间尺度：Permission 是静态或半静态的，可以持续几小时、几天甚至几年；而 Reason 是高度动态的，一个动作是否合理，几秒钟之后就可能改变。同一个 API、同一个身份、同一个 Token、甚至同一组参数，放在不同任务上下文里可能意味着完全不同的事情。只看 Permission 的系统只能知道这个动作理论上可以被执行，仍然不知道它现在为什么应该执行。

五、AI AGENT 压缩了权限与行为之间的距离

权限系统能长期工作，还依赖一个常被忽略的现实条件：拥有权限不等于立即执行。一个人拿到管理员权限之后，需要看到任务、理解任务、形成判断、打开工具、输入命令、检查参数，最后才执行。这中间存在大量认知摩擦，而摩擦往往不是坏事——它给了人重新思考的时间，也给了周围系统发现异常的机会。

对 Agent 来说，获得目标、生成计划、选择 Tool、组织参数、调用 API 可能发生在同一个推理循环里。过去"有权限但没有行动"是常见状态，未来越来越可能变成：只要 Agent 认为应该行动，权限就立刻转化为执行。

真正的变化不是 Agent 获得了权限，而是权限从一种潜在能力，变成了可以被机器高速消费的现实能力。

当主体本身不完美时，任何一次判断偏差都可能直接穿过权限体系进入现实。

六、一个完全没有攻击者的系统，也可能发生安全事故

传统安全事件通常需要一个对手：攻击者进入系统、窃取 Credential、绕过或提升权限、利用漏洞，威胁模型围绕 Attacker 展开。而在不完美主体模型里，存在另一种场景——根本没有攻击者。用户给出一个模糊任务，Agent 做出合理但错误的理解，系统正常授权，Credential 正常工作，接口正常响应，Executor 正常执行，最终造成损失。

这种事故最麻烦的地方在于，没有任何组件"失效"，每个系统都按设计正常工作，传统监控甚至会全部显示绿色：Authentication Success，Authorization Allow，Credential Valid，API Response 200，Audit Log Complete，Execution Success。只有一个问题没人回答——这件事本来应该发生吗？

一个系统可以在所有技术组件都"正常"的情况下，整体做出一件错误的事。

这也是为什么不完美主体的问题不能简单归类为 Bug 或 Hallucination。它是架构问题。

七、成功执行，不等于正确执行

软件工程有一个很深的惯性：我们非常擅长验证执行是否成功。HTTP 200、Transaction Confirmed、Job Completed、Deployment Success、Exit Code 0、数据库 Commit 成功，都是执行成功的证明。但执行成功与执行正确是两件事。错误交易同样可以 Confirmed，错误 SQL 同样可以 Commit，错误配置同样可以部署成功，一封不该发出的邮件同样会返回 Delivered。对执行系统而言它完成了任务，对现实意图而言它可能制造了事故。

因此需要区分 Execution Success 与 Intent Success：前者说明系统完成了动作，后者说明动作确实符合原始目的。长期以来它们被大量系统默认成同一件事。

"执行成功"只说明现实被改变了，并不说明现实被正确地改变了。

如果一个系统只能证明 Execution Success，却无法证明执行与原始 Intent 的关系，那么它拥有的是操作证据，而不是行为正确性的证据。这也是为什么 Agent 系统里的 Evidence 不能只记录谁调用了什么，还需要回答这次调用为什么被允许发生。

八、真正需要控制的不是权限，而是权限如何变成现实

传统安全常把最高价值资源理解成 Credential，因为保护好 Credential，攻击者就无法获得能力。这一点仍然成立，但 Agent 时代需要再往前一步：真正需要保护的不只是 Capability 本身，还有 Capability 转换成 Reality 的过程。

即使 Credential 完全安全，它也可能被合法主体错误使用；即使权限配置完全正确，也可能产生错误行为；即使通信全程 TLS，也无法保证业务意图正确；即使私钥永远不离开 HSM，也无法阻止 HSM 对一个错误 Intent 进行合法签名——除非它还受额外的执行约束。

所以安全边界需要从 Protect the Credential 扩展到 Control the Execution。这不是说 Credential Security 不再重要，而是它只保护了执行链上的一个环节。真正改变现实的是最后那个 Action；如果 Action 没有独立边界，前面再强的身份与权限机制，也只能证明这个错误动作是"合法发生"的。

九、"合法但错误"为什么比"非法"更难发现

非法动作通常带着明显信号：未知 IP、异常身份、权限提升、失效 Token、未授权接口、异常登录，这些都可以被检测。合法但错误的行为则安静得多——它来自正确账户，使用正常 Credential，调用允许的接口，发生在正常网络，行为频率甚至符合历史模式。从系统视角看，它和正常业务几乎一模一样，差别只在于它偏离了真实意图，而意图偏离恰恰是传统监控最不擅长观察的东西。

这意味着安全体系可能需要一种新的判断对象：不是异常行为，而是 Execution Consistency——执行是否仍与任务、状态、对象、约束和证据保持一致。如果 Agent Security 最终只演化成更聪明的行为异常检测，可能仍然不够。

最危险的错误不一定长得像攻击，它可能长得和正常业务一模一样。

十、合法性是一道门，但不是最后一道门

把现代安全架构简化，可以看到几道重要的门：你是谁（Authentication），你有没有权限（Authorization），你的 Credential 是否真实有效（Cryptographic Verification）。这些门都很重要。但当执行主体本身不完美时，系统还需要另一道门——即使前面全部成立，这一次具体行动是否仍然应该发生？

这道门讨论的已经不是身份、长期权限或 Credential，而是 Execution。它需要理解当前的任务边界、操作对象、系统状态、调用参数、已有证据，以及这次动作是否仍满足允许条件。如果答案未知，如果信息缺失，如果状态冲突，如果 Intent 已经过期，如果执行对象发生了变化，系统就不应该只因为身份和权限合法而继续执行。这正是 Fail-Secure 的意义所在：未知不应该被自动解释成允许。

合法性可以证明你走到了门口，却不能证明门现在应该为你打开。

十一、从"主体授权"进入"行动授权"

过去我们主要授权主体：允许某个人访问系统，允许 Service Account 写数据库，允许 Agent 调用支付接口。未来还需要授权某一次具体行动，授权对象从 Subject 扩展到 Action——除了 WHO，还要看 WHAT、Object、State、Mission、Proof 与 Boundary。一个动作真正获得执行资格，必须同时满足这些条件，而不是只依赖一条长期存在的 Subject Permission。

这并不意味着所有操作都要变成人工审批，恰恰相反：成熟的执行控制应该允许边界内部的大量动作自动发生。区别在于自动化的前提不再是"这个 Agent 有权限，所以全部放行"，而是"这个动作满足已经建立的执行边界，因此可以自动发生"。两者都实现了 Automation，安全哲学却完全相反——前者相信主体，后者相信结构。

十二、从"谁是合法的"，走向"什么是允许发生的"

安全工程过去成功解决了一个问题：不要让错误的人获得正确能力。这个问题依然重要。但 AI Agent 会迫使我们同时解决另一个问题：不要让正确的人、正确的 Agent、正确的 Credential，在错误的情况下使用正确能力。

身份合法只能证明主体是真的，Credential 合法只能证明能力来源是真的，权限合法只能证明系统允许这个主体使用这种能力。这些条件全部成立之后，仍然剩下最后一个问题：这一次行动是否符合真实意图？如果没有答案，"合法"最终只是技术意义上的合法。而现实并不关心一次错误操作在日志里有多合法——钱仍然会被转走，数据仍然会被删除，生产系统仍然会停机，代码仍然会发布。现实只接受结果。

Authorization 不是执行正确性的证明，它只是执行资格链上的一个条件。

因此安全的目标不应该停在"只有合法动作能够发生"，而应该延伸到：只有当任务、状态、对象、证据和边界同时成立时，合法动作才真正获得改变现实的资格。上一篇讨论的是主体可以合法却仍然错误，这一篇再往前一步——动作可以合法，却仍然不应该发生。一旦接受这两件事，问题就变得无法回避：如果主体不能被默认正确，合法动作也不能被默认正确，那么一个安全系统最终究竟应该相信什么？答案也许从来都不是相信某一个主体，而是相信一个能够约束所有主体的结构。