过去几十年的计算机安全体系，基本围绕"主体是否合法"来建立控制：用户登录，服务认证，程序持有 Credential，访问资源要过权限判断，高风险操作再叠加 MFA、PAM、短生命周期 Token、Least Privilege、RBAC、ABAC，直到 HSM 与硬件密钥保护。这套体系已经成熟到我们不再追问一个问题——当一个主体通过认证、获得授权之后，系统实际上还默认了什么？
系统证明了一个主体"是谁"，却往往顺手假设了它"知道自己在做什么"。这两个判断从来不是一回事。
一、被安全体系藏起来的那个前提
身份认证解决"你是谁"，权限控制解决"你能做什么"，但在现实世界真正发生动作之前，还有一个问题没有被传统权限模型完整回答：你现在做的这件事，究竟是不是你真正应该做的事？
传统系统通常把这个问题留给主体自己。工程师登录生产服务器，系统确认了他的身份，也确认了他有修改配置的权限，但系统并不知道他改的这个参数是否符合今天的业务目标；财务人员拥有付款权限，支付系统能判断金额有没有超过额度，却未必理解这笔钱为什么此刻应该付给这个账户；管理员拥有 Delete Capability，平台知道他有资格删除，却无法天然理解此刻删除这个对象是不是一个正确决定。
于是安全体系形成了一种非常稳定的分工：系统判断资格，人判断现实。系统证明身份，人理解语境；系统配置权限，人理解目的；系统阻止非法访问，人判断合法访问是否仍然符合真实意图。这个分工在很长时间里都成立，却也留下了一个藏得很深的假设。
Authenticated Subject 往往被默认为 Rational Subject。
一个通过认证、获得授权的主体，会被进一步默认成能够理解当前任务、理解当前状态、并且知道自己正在做什么的主体。这个假设过去很少出问题，因为那个主体通常是人。而现在，主体正在变化。
二、AI AGENT 让这个隐含前提第一次失效
AI Agent 与传统软件的区别，不只是更自动化，也不只是能调用 Tool。真正关键的变化在于，它开始承担过去由人完成的语义判断。过去把数据库写权限交给工程师，是因为工程师不仅拥有 Credential，还被默认能够理解"为什么要改这条数据"；现在同样的权限可能被交给一个 Agent。
它持有合法 Token，获得正确 Role，通过正常 API 发起请求，Credential 没有泄露，认证没有被绕过，权限也没有被非法提升——从传统安全体系看，整条调用链完全正常。但 Agent 仍然可能误解用户的任务，可能错误解释一段自然语言，可能把网页里的外部内容当成操作指令，可能在多步骤任务中逐渐偏离原始目标，也可能在环境已经改变之后仍然按照旧计划继续执行。它甚至可能在前九十九步都正确，只在最后那个真正改变现实状态的动作上发生偏差。
这时会出现一个很有意思的安全现象：身份是真的，权限是真的，Credential 是真的，调用路径是真的，日志也是完整的，整个系统里甚至没有一个传统意义上的攻击者，但最后发生的事情仍然不是人希望发生的事情。
一个动作可以完全合法，却仍然完全错误。
传统安全非常擅长识别 Illegal Actor，而 AI Agent 开始大量制造另一类风险：Legal Actor, Wrong Action。
三、真正危险的主体，并不一定具有恶意
安全行业习惯从恶意主体的角度建模风险：攻击者窃取 Credential，内部人员滥用权限，恶意程序提升权限，身份被伪造。于是我们不断强化认证、授权、Credential Protection 和 Least Privilege，让错误的人无法获得正确的能力。这个逻辑本身没有问题，但它隐含着一个经典的威胁模型——风险主要来自"不应该拥有能力的人"获得了能力。
AI Agent 带来的问题不同。很多时候能力恰恰掌握在正确主体手里：Agent 是企业自己部署的，Token 是企业自己发的，Role 是管理员自己配的，API 是业务系统自己开放的。没有 Credential Theft，没有 Privilege Escalation，没有 Unauthorized Access，唯一的问题是这个合法主体做出了错误判断。
因此"恶意主体"已经无法覆盖全部风险，我们需要一个更基础的概念：Fallible Subject，不完美主体。它不是指能力弱，不是指不可信，更不是指有恶意。它可以同时是合法的、被授权的、没有恶意的、甚至相当聪明的，但依然可能错误理解现实。
需要进入安全模型的，不再只有"主体可能作恶"，还包括"主体可能真诚地犯错"。
AI Agent 只是让这个问题第一次以工业规模出现。事实上，人一直也是不完美主体。
四、人类其实从来都不是完美主体
把这个概念往回推，就会发现它并不专属于 AI。人会疲劳，会误解信息，会因为时间压力降低判断质量，会被 Social Engineering 诱导，会因为 Confirmation Bias 忽略异常，会在复杂审批系统里养成连续点击 Approve 的习惯，会在值班三十个小时之后敲下一条错误命令，也会非常自信地执行一个其实并不正确的操作。
传统安全一直知道这些问题存在，只是长期以来把它们归类成"人为错误""运营风险"或者"培训问题"。当人的错误频率有限、执行速度也有限时，这种处理方式还能成立。AI Agent 改变的是规模：一个人一天可能执行几十个高价值操作，一个 Agent 一分钟就能执行几百甚至更多动作；人的错误常常停留在单次操作，Agent 的错误会沿着自动化工作流连续传播；人的决策通常还有时间被别人观察，而 Agent 的判断、调用与执行之间可能只隔几十毫秒。
所以 AI 并没有创造不完美主体，它真正改变的是——不完美开始具有机器速度。当一个 Fallible Subject 同时具备高自主性、高执行速度、高权限和连续操作能力，它就不再只是运营层面的操作风险，而变成了系统架构问题。
五、传统权限系统解决的是资格，而不是判断
IAM、RBAC、ABAC、PAM、Zero Trust 都非常重要，但它们本质上主要回答一个问题：某个主体是否拥有使用某种能力的资格。某个人能不能访问数据库，某个服务能不能读取对象存储，某个 Agent 能不能调用 Payment API，某个管理员能不能删除资源——这些都可以抽象成 WHO can do WHAT，并且已经覆盖了现代数字系统中极其重要的一部分安全问题。
但当主体本身可能犯错时，WHO 加 WHAT 就不够了。真正决定现实结果的，还包括这个动作属于什么任务、操作的对象是谁、当前系统处于什么状态、原有条件是否仍然成立、参数有没有发生变化、有没有足够证据证明它仍然符合原始意图。缺少其中任何一项，一个完全合法的权限都可能产生错误结果。
于是问题从 WHO can do WHAT，变成了：WHO，在什么 Mission 下，针对什么 Object，在什么 State 中，依据什么 Proof，可以让哪一种 Action 真正发生？这已经不只是 Identity Problem，也不只是 Authorization Problem，它开始进入 Execution Problem。
权限回答的是"你有没有能力做"，执行安全回答的是"这一次到底应不应该让它发生"。
这两个问题以前经常被混在一起，AI Agent 正在迫使我们重新把它们拆开。
六、过去真正的最后一道安全边界，其实是人的判断
很多软件系统看起来并没有"执行控制层"，却依然能长期稳定运行，原因在于人类一直在承担那个角色。工程师执行rm之前会再看一眼路径，财务人员付款之前会核对收款方，DBA 执行 SQL 之前会确认 Where 条件，运维重启生产服务之前会观察业务状态，管理员批准权限之前会读一遍申请原因。这些行为没有被严格写进 IAM，也没有全部编码进 Policy，但它们构成了现实世界里一层重要的语义缓冲——人一直在权限和执行之间做最后一次判断。
这也是为什么传统软件时代"给一个主体权限"通常不会立刻变成灾难：权限并不等于自动执行，中间还隔着人。而 Agent 正在压缩掉这段距离。它接收任务、理解任务、制定计划、调用工具、然后执行，Intent、Decision 和 Execution 快速收敛到同一个主体内部。一个过去需要三个步骤、两次确认、几十秒才能发生的动作，现在可能在一次 Agent Loop 里自动完成。
因此 AI Agent 带来的架构变化，也许不在于机器获得了更多权限。
而在于判断权与执行权第一次大规模聚合在同一个不完美主体身上。
七、HUMAN-IN-THE-LOOP 为什么并没有彻底解决问题
一个自然的应对是把人重新放回来：Agent 提交动作，人负责批准。这是目前很多企业采用的路径，在大量场景中确实有效。但从不完美主体的角度继续推演，它并没有触及最底层的问题，因为人本身同样是 Fallible Subject。
一个审批者每天面对几十条请求时可以认真判断，面对几百条时开始疲劳，面对几千条机器生成的请求时，Human-in-the-Loop 很容易退化成 Human-next-to-the-Loop。人仍然坐在那里，仍然拥有 Approve 按钮，每个动作也都有人工记录，但真正的判断能力可能已经被请求规模压垮。
更根本的是，如果系统只是把 AI 的判断转交给另一个不完美主体确认，它依赖的仍然是同一个假设：最后总会有一个主体是正确的。过去我们相信工程师，后来我们相信审批人，未来也许有人希望相信更强的模型。这个逻辑始终没有离开"寻找一个足够可信的主体"。问题可能恰恰出在这里。
八、安全系统不应该寻找一个完美主体
可靠性工程早就接受了一个常识：组件会失败。磁盘会损坏，网络会中断，节点会宕机，软件会有 Bug，传感器会返回异常值。因此成熟系统不会把可靠性建立在"某个组件永远不失败"之上，而是用冗余、校验、隔离、仲裁、恢复和 Fail-Safe 机制，让组件失败之后系统仍能维持边界。
但在安全系统里，我们对"主体"的处理却往往相反：努力寻找一个可信主体，然后把最终决定权交给它——管理员、Owner、审批者、AI Agent、某个最高权限账户、某个 Root of Trust。这背后是一种主体中心主义，认为只要找到那个足够可信的人、程序或设备，系统最终就能安全。
Fallible Subject 指向另一个方向：不去证明某个主体永远不会错，而是让任何主体犯错之后都无法轻易改变现实。这意味着安全设计要从"信任主体"转向"约束行动"，从"谁说了算"转向"什么条件满足以后才允许发生"，从"找一个最终可信者"转向"构造一个不存在单点绝对权力的执行结构"。
成熟的安全，不应该建立在某个主体永远正确之上，而应该建立在任何主体都可能错误这一事实之上。
这一点对 AI Agent 尤其重要。我们未来面对的既不会是一个完美的超级智能，也不会永远停留在今天偶尔幻觉的模型。更可能的长期现实是：模型越来越强，自主性越来越高，可调用的能力越来越多，执行速度越来越快，但它依然无法拥有对现实的绝对理解。这就足以让不完美主体成为一个长期问题。
九、从可信主体，走向可信结构
如果承认主体天然不完美，下一个问题就变得更根本：安全究竟应该建立在什么之上？答案可能不再是某一个人，也不再是某一个模型，而是一种结构。
这种结构允许 Agent 做判断，但不允许它独占最终执行资格；允许人进行授权，但不意味着 Owner 拥有无限制的执行能力；允许 SaaS 参与协同，但不把最终现实控制权交给 SaaS；允许设备执行动作，但设备本身同样受独立边界约束。每个参与者都可以拥有能力，却没有任何一个参与者因为身份最高、权限最大或理论上最可信，就天然获得把任意意图直接变成现实的资格。
此时安全系统追求的不再是 Perfect Subject，而是 Reliable Structure among Fallible Subjects。真正稳定的控制从来不是"我相信你不会犯错"，而是即使你犯错，也有东西能阻止错误继续向现实传播。
十、不完美主体，是 AI 安全真正的起点
今天关于 AI 安全的讨论大量集中在 Prompt Injection、Hallucination、Jailbreak、Model Alignment、Tool Abuse 和 Agent Permission。这些问题都重要，但它们背后共同指向一个更底层的事实：我们正在把越来越多的现实能力，交给一个天然不完美的主体。如果仍然沿用过去那套逻辑——认证它、授权它，然后相信它知道自己在做什么——那么随着 Agent 能力增强，我们只是在不断把更大的现实权力交给一个无法被证明永远正确的行动者。
真正需要改变的，也许不是让 AI 成为完美主体，而是让系统不再需要任何完美主体。人可以错，AI 可以错，SaaS 可以错，Policy 可以缺失，设备可以异常，上下文可以不完整。成熟的安全结构应该在这些事情发生之后，仍然能够回答一个问题：这个错误，有没有资格真正进入现实？
传统安全花了几十年解决"这个主体是谁"。AI Agent 时代需要补上另外半句：即使它真的是它，我们为什么还应该相信它这一次知道自己在做什么。当这个问题开始成立，身份、权限、审批、信任、控制、执行与证据之间原本模糊的边界，都需要被重新理解。因为最终需要保护的从来不是谁拥有权力。
而是谁有资格让某件事情真正发生。
一个成熟系统最重要的能力，也许不是找到那个永远不会犯错的人，而是即使所有参与者都可能犯错，它依然清楚：什么事情绝不能发生。
